Bitcoin Network Disruption

#1

Hey everyone,

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.

4 Likes
#2

Great explanation @jude. The probability of a chain split is looking fairly low at this point but it’s good to inform the community about any potential steps they might need to take.

The periodic backups feature is coming in really handy here! Makes reindexing/resyncing fast and easy.

#3

If the chain split occurs as the result of a hard fork (as the Bitcoin Cash software intends to do), then by definition there cannot be a re-org because the new blocks violate the rules set by legacy nodes. The only way a reorg could happen under this scenario is if users do not upgrade to support the hard fork, and later change their minds and upgrade their software, at which point the blockchain followed by their software would automatically reorganize itself around the hard fork rules.

It’s worth asking now for clarity’s sake, even if this question might have been answered implicitly before: if Bitcoin Cash starts off with less hash rate than Bitcoin Core, but later overtakes Bitcoin Core in hash rate, will Blockstack modify the software to follow Bitcoin Cash, thus triggering this re-org process? If so, will the method described here:

protect users from losing names or fetching out-of-date zone files?

#4

It’s worth asking now for clarity’s sake, even if this question might have been answered implicitly before: if Bitcoin Cash starts off with less hash rate than Bitcoin Core, but later overtakes Bitcoin Core in hash rate, will Blockstack modify the software to follow Bitcoin Cash, thus triggering this re-org process?

This sounds more like a chain migration scenario, akin to switching from Namecoin to Bitcoin. If a migration to Bitcoin Cash did happen, we’d want to implement a voting system first so the community could decide when to execute it (time permitting, of course; a catastrophic failure of Bitcoin would necessitate greater haste).

If so, will the method described here: … protect users from losing names or fetching out-of-date zone files?

These commands recover from deep reorgs that started before $BLOCK_HEIGHT. However, detecting deep reorgs is still a manual process. It wouldn’t help in the case where the user switched from Bitcoin to Bitcoin Cash; that’s not something we support at this time.