search

MerosCrypto / Meros

An instant and feeless cryptocurrency for the future, secured by the Merit Caching Consensus Mechanism.
https://meroscrypto.io
Other
82 stars 19 forks source link

Nodes can't sync new chains due to believing received BlockHeaders are invalid. #243

Closed kayabaNerve closed 4 years ago

kayabaNerve commented 4 years ago

Because we use a variable RandomX key, we can't verify the hashes of Blocks in advance. This has two effects; not only can we not check BlockHeader integrity as we sync, at least with the current protocol, but we also need to wait to perform the RandomX hash on received BlockHeaders.

kayabaNerve commented 4 years ago

Closely related to https://github.com/MerosCrypto/Meros/issues/166.

kayabaNerve commented 4 years ago

Misclicked the assignment button; we don't really use that functionality.

The above comment has a lot of commentary on this issue. It's no where near ready to be merged.

kayabaNerve commented 4 years ago

Updated tags to reflect current status.

kayabaNerve commented 4 years ago

When I said closely related to #166, I meant identical. Closing #166 as this issue has taken its importance, despite being a duplicate. The only thing I can think of which may have been in the first, but not this issue, is about when Meros tries to perform the RandomX hash of a far off block when doing its first sync. It can't verify the PoW, and will likely fail. Reorganize, in the above patch. handles this case, but the main block loop doesn't IIRC.

kayabaNerve commented 4 years ago

The dt5.1-experimental branch will be solely purposed used for this issue, despite originally having a different intent. Thankfully this does work when syncing a new chain. Now the trick is verifying the reorg behavior and cleaning up the code.

kayabaNerve commented 4 years ago

I'm happy with the state of Nim code, except for two aspects.

The first isn't too big of an issue. It's just that we likely want to make the time/memory tradeoff so we don't need to regenerate the existing cache after generating one temporarily.

The other aspect to note is the check if a block exists. If a Block with a different RandomX key is set, Meros will generate the old cache and perform the check. This is not counted as a reason for disconnection due to network propagation/nodes just syncing up which don't realize they're syncing, which is how it should be defined. We NEED to check existence using the Blake hash due to the costs in generating a RandomX cache and performing the hash.

kayabaNerve commented 4 years ago

dt5.1-experimental will be merged to close this issue after two more tests are added related to attempted chain reorgs which fails, making sure the original chain can sync back up, despite the key changes in play