Invalid block relays

[brianlenz]

It looks like the issue that happened with block 2000190 has happened again:

http://monitor.cityofzion.io/

Over half of the nodes are stuck on block 2022689.

I had originally created CityOfZion/neo-python#302 for this, but it seems like this issue would be better addressed at the system level to prevent invalid blocks from being transmitted in the first place.

It looks like this is the invalid block hash for block 2022689: 1164457854190e4c20c0b805e0bad3f3f9c0fe50bd59308751e8c3541c38ca70

The proper block hash is: 8d23af0e0e30fffdb48bd25ea1a0049add3a48f0d2134de86adf0ce06b650488.

[shivam2901]

What's solutions for this? Any where I can get that bootstrap?

[erikzhang]

http://static.neo.org/client/chain.acc.zip

[ghost]

From my basic analysis, it appears that the block is being transmitted to the network prior to the leveldb commit finalizing. So when the consensus nodes start up again, they don't have the block.

I have not been able to trace it to a file or line number.

[jsolman]

FYI if @coranos comment was correct, this is probably fixed by my pull request here: #237

[jsolman]

Possibly a timing issue on a consensus node could also cause this issue. Should probably create a scenario that reproduces it on a private net.

[dicarlo2]

Consensus nodes probably need to listen for blocks from the network for some duration before rejoining consensus, otherwise they may miss a block they've broadcasted but failed to persist.

[ghost]

Dicarlo2 is correct. They should listen for at least one consensus before rejoining consensus (or wait for 2x the consensus timeout, in case all consensus nodes are down)

Here's how to reproduce the scenario:

1. Send a new block to the network.
2. Immediately die, not persisting the block (as you only persist blocks you get from the network).
3. on restart, try to form a new consensus based on your last block height, which is now stale.

Most networks have uncle block rollback, NEO does not.

[Leondelcrypto]

neotracker does not track all the Nep 5 tokens !

[f27d]

@Leondelcrypto this is not a relevant comment on this issue please raise a new issue with the neotracker GitHub repo pls

Thanks

[jsolman]

It's possible this scenario would not cause nearly as many problems for nodes that include this change:
#489

[vncoelho]

This has been probably solved by avoiding the expose of CN signatures when crashing or after network delays that could cause view to change.

Commit f88c427 probably solved that. Fell free to open it again for further investigation or discussion.