BitShares Forum
Main => General Discussion => Topic started by: emski on September 01, 2014, 07:24:10 pm
-
368403
1d57020bf8042649d56d0f91ca08f451b13b1888 init53 0 166 2014-09-01T02:24:10 0 YES YES
7481ca8e6954140421a8c2a0d51e620d2db2510b init53 0 166 2014-09-01T02:24:10 0 N/A NO
-
The bug of double producing causing falling into a fork seems be resolved?
-
The bug of double producing causing falling into a fork seems be resolved?
Yes it is! However they were pretty strict about that rule and I couldn't stop myself of posting this. Of course there were others that I messaged privately about similar issues.
Actually it was better to just PM DACSunlimited...
Sorry if I've offended someone.
-
The bug of double producing causing falling into a fork seems be resolved?
Yes it is! However they were pretty strict about that rule and I couldn't stop myself of posting this. Of course there were others that I messaged privately about similar issues.
Actually it was better to just PM DACSunlimited...
Sorry if I've offended someone.
I would take the same attitude as you, init53 should be vote out, no matter what's the story behind it.
-
Well it shouldn't be that strict as it was only once (my opinion ). However there are other delegates consistently
mining signing blocks on 2 chains.
-
I think allowing delegates to double produce blocks with impunity makes the blockchain less secure, and makes it harder for us to argue that nothing at stake doesn't apply to DPOS.
-
368403
1d57020bf8042649d56d0f91ca08f451b13b1888 init53 0 166 2014-09-01T02:24:10 0 YES YES
7481ca8e6954140421a8c2a0d51e620d2db2510b init53 0 166 2014-09-01T02:24:10 0 N/A NO
Would you please tell me how did you find this information? Thanks!
-
368403
1d57020bf8042649d56d0f91ca08f451b13b1888 init53 0 166 2014-09-01T02:24:10 0 YES YES
7481ca8e6954140421a8c2a0d51e620d2db2510b init53 0 166 2014-09-01T02:24:10 0 N/A NO
Would you please tell me how did you find this information? Thanks!
blockchain_list_forks
However it had to be issued on the seed node as some other clients didn't have that information.
One of the delegates had it also.
Newly synchronized clients do not have this.
-
blockchain_list_forks
However it had to be issued on the seed node as some other clients didn't have that information.
One of the delegates had it also.
Newly synchronized clients do not have this.
I guess identified forks are not broadcasted to the network when syncing .. you can only see forks if you catch them live :-)
does make sense to spread invalid fork blocks, does it?
//edit: typo fixed
-
does make sense to spreach invalid fork blocks, does it?
This is open for debate...
-
are those forks due to latency?
-
are those forks due to latency?
That particular above is a fork that resulted from 1 delegates producing two DIFFERENT blocks at the same time .. seems like they ran it on two machines and skews sth. up
-
are those forks due to latency?
That particular above is a fork that resulted from 1 delegates producing two DIFFERENT blocks at the same time .. seems like they ran it on two machines and skews sth. up
ok. makes sense.