The Consensus Path To A Bitcoin Hard Fork: Part 3

Part 1 discussed the technical ingredients we might see in a future consensus hard fork. Part 2 discussed how we might measure consensus once we think we have it. Now let’s talk about how we’d roll a hard fork out.

Deployment Strategies

If we’re going to hard fork, I want the best possible team doing it, and as many eyeballs as possible. That means the same people who have been shepherding the development and massive improvement of bitcoin core and the bitcoin protocols over the last few years. Yep, they’re extremely conservative and it will take time, but in the long view, that’s a feature: if the most experienced developers say it’s not ready yet, that’s a no-go for me.

It’s clear that such a change will take 12 to 18 months to reliably deploy after release: 4.7% on the current nodes claim to be running 0.12.1, which is 16 months old. We’ll also need an intensive community awareness campaign during this period.

Since we don’t want to break existing transactions there’s no way to have compulsory 2-way replay protection. But opt-in is certainly possible, such that on either fork you can create transactions which can never be valid on the other fork. For example, if we soft-fork 6 months before the HF to disallow transactions with the high nVersion bit set: these would only be allowed after the hard-fork. Similarly, the HF could also disallow any transactions with the second-highest nVersion bit set.

Note that such a soft fork would also give 6 month warning, as old nodes will complain about seeing a soft-fork activate which they don’t understand.

There were previous discussions about making the old chain unusable, to prevent un-upgraded nodes from being tricked by a malicious miner continuing the old chain. That assumed that nobody would willingly stay on the old chain, which I think is no longer valid: these approaches should be rejected. Thus, setting the (currently invalid) high bit on the block nVersion is the developers’ preferred hard fork method. Unfortunately, without protection for old nodes we cannot shorten the deployment timeframe.

There’s also an argument as to whether a hard-fork should break SPV (“lite”) nodes (which don’t download the whole block, trusting the miners to be honest), or even if it should be detectable by them (it should!). Using the high bit of block nVersion achieves the detectability requirement, and otherwise avoiding any upgrade requirements on SPV nodes seems both simple and desirable (spoonnet does this, for example).

Conclusion

Hard forks are genuinely difficult; they require widespread commitment, technical excellence and universal upgrades. The best failure mode is that it gets abandoned and doesn’t happen, the other failure modes all involve some erosion of bitcoin as a store of value.

But having now sketched out a roadmap of how we could do one, I feel compelled to start actively engaging in the first steps, by reviewing and critiquing the spoonnet code and proposals in depth and offering to collaborate with anyone who has suggestions on the technical ingredients and their tradeoffs. I hope you’ll join me!