As most of you may have seen, bitcoin.org had a recent announcement of a possible upcoming network disruption as soon as July 31. One of the possible outcomes of this disruption is that the Bitcoin blockchain may split into two competing forks. It is unknown if this will come to pass, but it currently appears unlikely.
Nevertheless, we have a plan:
- If no chain split happens, then all Blockstack software will continue to work without modification.
- If a chain split does occur, then we will upgrade the software and patch our infrastructure to follow the fork with the most proof-of-work.
At Blockstack, our engineering philosophy is to operate on top of the most secure blockchain. This was a hard lesson learned when we migrated to Bitcoin from Namecoin, and one that we have not forgotten. This lesson also applies to selecting which Bitcoin fork to use.
Surviving Deep Reorgs
There are two ways a chain split can happen. The first way is to change the block headers in one fork to make it incompatible with the other fork. This is the safer of the two outcomes, since it prevents replay attacks.
The second way is for a coalition of miners to create a separate compatible fork, and try to have it overtake the other in terms of PoW. This scenario is the biggest risk to Blockstack. This could lead to a “deep” chain reorganization, where many recent blocks get replaced by the blocks in the other fork.
Blockstack’s virtualchain depends on the transaction order in the underlying blockchain to remain stable after a certain number of confirmations. This is a reasonable assumption in practice, since the orphan rate in Bitcoin is quite low. However, a deep chain reorganization invalidates this assumption.
If a deep chain reorganization happens, then a full node’s name database will get out-of-sync with the blockchain. The node will need to recover from a backed-up name database, and re-index the reorganized blockchain to calculate the correct name state.
Under its default settings, a full Blockstack node will make daily back-ups of its name database, and keep them around for seven days. Should a deep reorganization happen, you can recover with the following commands:
$ blockstack-core stop $ blockstack-core restore $BLOCK_HEIGHT $ blockstack-core start
You can see the set of backups in your
~/.blockstack-server/backups/ directory. The value for
$BLOCK_HEIGHT should be one of the block heights listed in the backups directory.
We have a Github issue open to make it possible for Blockstack nodes to automatically detect and recover from deep reorganizations in future releases.