The idea is to reverse the flow of time.
If we can prove that both cores computing in reverse reach the same state (ie arbitrary split network can be reversibly unified) we proved that there exists blocks that can split network.
Let's hunt for consensus bugs using this method!
We start with a network of two split Bitcoin Core nodes (two different versions) and a three miners (so that no one has 51% when chainspilt is trivial).
GOAL: calculate in reverse what happens until we reach some unified network block (a block in set "a" in picrure below)
X Y
\ /
b c
\ /
|
a
|
The miner schedule is generated, each miner takes 30min on average. it is a sequence of timestamps when blocks were "mined". The segment b cointains only blocks (actually timestamps) from miner #1, the segment c contains only timestamps from miner no. #2 and miner #3 blocks. The segment "a" contains blocks (timestamps) from all three miners.
To every copy of block, a boolean attribute is also added whether the block is other node relayed or miner relayed.
Next lets focus on the oldest block (chaintip) which must be unvalidated and unmined.
If it's miner relayed, it is unvalidated and sent back to miner. Miner serves as a sink and saves blocks it recieves to disk.
If it's node relayed it is either on one node, or on both nodes.
If it's on one node the other node must have rejected it. This rejection is simulated in reverse, meaning the node who does not have it internally simulates the reason for rejection, then sends it to node who has it. The node who has it then unvalidates it and sends it to miner for storage.
If it's node relayed and on both nodes the unvalidation by late node, sending to early node, receiving (unsending) by early node, unvalidating by early node, and sending to miner is performed.
Blocks are also popped from blockchains.
Actually node X is the minority node so it is rejecting all blocks from set c.
Topic: chainsplit proofs in reverse analysis (Read 202 times)
Jump to: