The Consensus Path To A Bitcoin Hard Fork: Part 2

Part 1 discussed the technical ingredients we might see in a future consensus hard fork, now we need to figure out what consensus is. IETF’s RFC 7282 is an eloquent document which describes important aspects on consensus, and worthwhile if you want a more nuanced interpretation than “widespread agreement and disagreements addressed (even if not acommodated)”.

Measuring Consensus

Once we have a concrete technical proposal, and it seems to have some traction, we need to figure out if we really have consensus before it gets deployed.

The simplest way to do this is a yes/no vote on a concrete proposal, with “no” meaning “… and don’t ask again for 4 years”.

No method of doing this is fool-proof: any measurement can be gamed or can invoke gaming behaviors in participants, so the best we can do is use multiple “soft” approaches, which might include:

1. Developers: get bitcoin core developers to vote, and measure by both number of developers and by code-lines-changed.
2. Developers: create a list of bitcoin wallets with non-trivial number of users, and ask them.
3. Users: use the top exchanges to allow user voting (accounts over a year old, with non-zero volume). Luke-Jr’s KYCpoll offers one way, but ideally it would cover multiple exchanges, and be supported by them with some independent auditing. localbitcoins users might have a different opinion than Coinbase users, for example.
4. Users: publicly accessible nodes could set their UA comment strings to vote, using a list of nodes which have been active for over a year, and using the blockhash to select one in the case where there are multiple IP addresses in the same IP block (avoiding 1000 votes for AWS, for example). Various DNS seeds scan for active nodes, so have historical data on which nodes have been around for a long time.
5. Users: there are multiple lists of bitcoin businesses which could be polled. Weighting them would difficult (I seem to recall that coin.dance weights this by some web metric?), but requiring them to have some active bitcoin offerings would be a minimum bar.
6. Users: a simple vote weighted by number of coins is quite easy, though gives a large vote to centralized entities such as exchanges, and any other counting method is likely to be too flawed to be useful.
7. Miners: Doing a poll by hash power is fairly easy (use two version bits), but in many cases would be a poll of mining pools, rather than miners.

Doing all these would be a lot of work, both with coordination, and determining fair, auditable and reliable methods of measurement. But this work is vital if you want to achieve consensus that we actually have achieved consensus; if this raises red flags, it makes it clear that “no change” is the safest path, otherwise it’s clear that “proceed” is the safest path.

Remember: a lack of consensus doesn’t destroy bitcoin, it just keeps it to its current state, which is truly the best failure mode a store-of-value system can have! I’d personally and loudly oppose a proposal I agreed with, unless I was convinced it had consensus.

Onwards to Deployment

In part 3, I’ll talk about how a hard fork might be rolled out…