Timeline

Hash reference

Address reference

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

1. Why Volodymyr's masternodes rejected block 57750(A)? The obvious explanation would be that they didn't have the final budget, but they actually gave votes for Final Budget A! (todo: confirm with solid evidence)

• Because of the failsafe payment code. Due to sloppy use of integer arithmetics in function CBudgetManager::IsTransactionValid superblock payment validity checks won't work properly when there are less then 20 masternodes in the network. Specificly, any budget payments in superblock that are not devfund payments will be considered invalid.

2. What caused issuing of block 57750(B) the next day? Which node mined it? Probably, it won't help us understanding the problem, but it's just a strange unexplained event
3. Why the failsafe even worked? Based on code analysis done independently both by Volodymyr and Ashot the failsafe relies on impossible combination of events to work. In fact this was one of the reasons to eradicate it. We must have missed something

• Apparently, the "impossible" combination of events includes includes having less then 20 masternodes (see the answer to Q1). I suppose, this is exactly how it worked when it was tested in testnet

4. The last block on chain A is 58772 (01/20/2018 @ 11:54pm UTC), however Volodymyr's wallet received up to 57756 on Jan 22 and up to 58228 on Jan 23. Why? Probably it's due to the network being split, but it would be nice to have a more detailed explanation
5. What mining pool has been doing since issuing block 58772? No new blocks have been issued, but the pool is still working (Jan 23, morning)
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

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