After the full publication of CVE-2018-17144, several occasions of hits on derived blockchains came to attention. Following that, we did a test setup:
Hardware: 1 pc. bare metal (DELL R730) 3 pc. Antminer S9 (via Slush's Stratum protocol)
Procedure:
- take git 0296b9c85e942686df7ef40333e07e9b1802b892 (0.16.2)
- mod testnet params to run a confined chain in regressive time scale (all in chainparams.cpp, no other change)
- run a bunch of nodes, one of them mining (1 ASIC)
- in order to have more fun, consolidate some tcoins so we have a transaction other than coinbase
- create a raw transaction Italian flavour, copy-pasta inputs and it's being mined as described in the publication.
- let the node mine further for a while, in the test case 500+ blocks, nvm the exact number
- assume we have virtually discovered the attack and stop the mining node
- apply the patch to the mining node (all others left untouched)
- start mining node by -reindex
- the updated node recognises the invalid block and finally bans the others
- patch a second one because we need a peer
- attach the remaining 2 ASICS together with the first one and go on from the first invalid block (speed things up while simulating real life)
Expected result:
- the non-updated nodes should follow the (work wise) longest chain
Test result:
- the "crowd" nodes are stuck at their latest block information
The confirmation and reproduction of this behaviour is the current point of our research, would like to read reactions before we extend the setup for running both chains in parallel.
Update:
Noticed while matching nbits, the new and now valid block's hash resulted in an overall lower number than the culprit containing multi-inputs
non-updated nodes can be brought back to life by reindexing
