19.01.18 Testnet Fork Report
Timeline
| Time |
Events |
| 19.01 08:35 |
Proposal test8 for 42 tCRW starting block 57750 is submitted by Volodymyr |
| 19.01 08:35 |
Block 57664 is mined. It includes 25 tCRW fee for test8 submission |
| 19.01 08:44 |
Proposal test8 receives 2 votes |
| 19.01 09:39 |
Final budget A is submitted by one of vshamray's nodes. The only proposal it includes is test8
|
| 19.01 09:39 |
Block 57721 is mined. It includes 25 tCRW as final budget submission fee |
| 19.01 09:55 |
Final budget A receives 3 votes from masternodes |
|
|
| 19.01 10:25 |
Block 57749 is mined. Mining stops until late in the evening |
|
|
| 19.01 19:23 |
Block 57750(A) is mined. It contains 42 tCRW payment by proposal test8 (final budget A) |
| 19.01 19:24 |
Block 57750(A) reaches Volodymyr's masternodes. Both nodes reject it as it doesn't contain payment to DevFund Address
|
| 19.01 19:27 |
Masternodes keep rejecting the block, so does (apparently) testnet explorer |
|
|
| 20.01 10:24 |
Block 57750(B) is mined (how? by which node?). It contains 50 tCRW payment to DevFund (failsafe) and does not contain payment by test8 proposal |
|
|
| 22.01 |
Both Volodymyr's masternodes have full information about test8 and its votes. The consensus on budget seems to be at final budget A, yet the blockchain is on chain B
|
Hash reference
| Object |
Hash |
| block 57664 |
00000000055297a028ed7f74f05de37e49d6f5e3b56a1f5744a1daaec7828737 |
| block 57721 |
000000001453978d77294ebadf1cbb1d4fc7174059e9407072a671e7e9684bdc |
| block 57749 |
00000000112defd05ff138031ff5bff7a4967118c6acdb1d03541d356ef58804 |
| block 57750(A) |
00000000ff4cc3d7506c5b48ab3aca7aea2da0e1876494187dd99b6f9090f8ef |
| block 57750(B) |
000000002856e18e100e7c56d5486fcbd537a4a87da2e5b393409d046393c9c0 |
| test8 |
560297e695d6615ca5f1c861d1c91b0b04be9c76fa9404300fa6689037eb692b |
| Final Budget A |
1f2995bdd6597a4fc5ba9f5a4813d14174733c512369c4adf0d2821a215a8526 |
Address reference
| Label |
Address |
| DevFund Address |
mr59c3aniaN3qHXej5L8UBsssRZbiUUMnz |
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.
So far, this is the only logical explanation, however there are few questions to be answered
Further research directions
- 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.
-
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
-
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
- 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
-
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)
-
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
-
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
Volodymyr Shamray