Quote from: xeroc on September 02, 2014, 12:29:36 PM

Quote from: delulo on September 02, 2014, 11:59:56 AM
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.

Quote from: delulo on September 02, 2014, 11:59:56 AM
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?

Quote from: xeroc on September 02, 2014, 09:12:50 AM
does make sense to spreach invalid fork blocks, does it?

This is open for debate...

Quote from: emski on September 02, 2014, 03:09:35 AM
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

Quote from: ripplexiaoshan on September 02, 2014, 03:00:53 AM

Quote from: emski on September 01, 2014, 07:24:10 PM

Code Select Expand

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.

Quote from: emski on September 01, 2014, 07:24:10 PM

Code Select Expand

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!

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.

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.

Quote from: emski on September 01, 2014, 09:24:44 PM

Quote from: HackFisher on September 01, 2014, 09:09:30 PM
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.

Quote from: HackFisher on September 01, 2014, 09:09:30 PM
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?

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