| ... | ... | @@ -37,6 +37,8 @@ |
|
|
|
# Interpretation
|
|
|
|
Current hypothesis is that the fork happened because of budget being inconsistent across the network: block 57750(A) that contained budget payment was rejected by several nodes in the network; later those nodes accepted block 57750(B) that contained failsafe payment.
|
|
|
|
|
|
|
|
Due to sloppy use of integer arithmetics in function CBudgetManager::IsTransactionValid superblock payment validity checks of all nodes that were online and synced at the moment (except for Volodymyr's wallet which was patched) rejected block 57750(A) by error. Mining pool node, however, produced the block before it had time to sync, so it still payed the budget that it had saved, but didn't run any masternode or budget related checks. Later, all the nodes that received block 57750(A) before they finished syncing ended up on chain A, others ended up on chain B.
|
|
|
|
|
|
|
|
So far, this is the only logical explanation, however there are few questions to be answered
|
|
|
|
|
|
|
|
### Further research directions
|
| ... | ... | @@ -50,4 +52,13 @@ So far, this is the only logical explanation, however there are few questions to |
|
|
|
6. **Is it a bug? If yes - how severe it is?** The testnet setup (little amount of nodes, unstable mining) obviously contributed in the fork, so it would be nice to know: to what extent?
|
|
|
|
* If I'm right about Q1 - **yes, it is**, and it's rather urgent, because it limits our capabilities of testing governance in the testnet
|
|
|
|
7. **How likely is it to reproduce in mainnet?** Hopefully, having answers for questions 1 - 6, it would be easy to answer this one.
|
|
|
|
* If I'm right about Q1 - **very unlikely** |
|
|
\ No newline at end of file |
|
|
|
* If I'm right about Q1 - **very unlikely**
|
|
|
|
|
|
|
|
# Next Actions
|
|
|
|
|
|
|
|
Following steps aim to test the hypothesis and fix the problem:
|
|
|
|
1. In the next couple of days Volodymyr will create an update that will fix incorrect superblock processing with small amount of masternodes.
|
|
|
|
2. This update will pass code review and will be merged into master
|
|
|
|
3. Mining pool node, testnet explorer and Volodymyr's masternodes will be updated to this version and restarted
|
|
|
|
4. If those nodes switch to chain A, the hypothesis is comfirmed. If no, we will need further investigation
|
|
|
|
5. We might need to test superblock payment several times and we will try to reproduce the situation before the fork as accurately as possible. If updated nodes are on the correct chain - hypothesis is confirmed, problem is fixed |
