How the Bitcoin experiment might fail

Hard forks and the block size debate

Gavin Andresen has been advocating strongly that Bitcoin’s blocks need to be permitted to be much larger. Earlier this year, he announced plans to release code that implements larger block sizes via a “hard fork” — a non-backwards-compatible change — against the wishes of most other Bitcoin Core developers, and encourage miners and merchants to adopt his code. Yesterday, he released a draft BIP, a proposal for how the protocol should change, along with draft code that implements his proposal. But even if one agrees with Gavin’s vision for what the technical features of Bitcoin ought to be, his proposal is an irresponsibly risky path forward. This has nothing to do with what block sizes should be, but instead about Bitcoin’s much greater experiment: in the absence of a central authority, can people come to agreement on what money to use?

It’s useful to step back and think about why anyone might ascribe any value at all to a virtual currency. There are certainly many technical features a currency must have to be a candidate for being worth anything (if you can’t transact it, or if there’s no way to secure it, or there is an infinite amount of it, it’s probably not very useful). But looking past the technical issues, the more fundamental test you’d apply when deciding whether to use a given coin as money is whether you think everyone else will treat it as money too. In particular, if at some point in the future you worried that what you thought was money was not actually considered money by others, then you would probably choose something else to be a store of value.

This is the most important lens through which we should view Gavin’s proposal. If you have a money that other people accept, under what circumstances should you change it to be a different, new money? That is exactly what a hard fork entails: Gavin is asking 75% of miners to switch to a new currency with new and different properties. If they do so, then they will trigger a permanent change to the consensus rules for those running Gavin’s software. The idea is that if everyone goes along with it and changes their software to match, then we can still call it Bitcoin, and the lack of backwards compatibility is a non-issue (since no one will be around running incompatible code).

So why might everyone switch to a new currency? One reason is if the current one is clearly broken — something like the March 2013 fork, where a latent bug in the reference implementation caused the network to split. In that situation, it was clear to everyone there was a problem, and running software that is buggy was clearly not in anyone’s interest (whether or not others kept running the buggy software). If a hard fork is required to make your money have any utility at all, you’re likely to choose to do it (as long as you believe your solution is the same one everyone else will be deploying!).

But if what you’re using isn’t clearly broken or if there are multiple incompatible choices of code to use to implement a bug fix, the decision is much more difficult. Somehow you have to coordinate your actions with everyone else. And what if there are dissenters? Is it worth risking splitting the network in two (or more)? Under what circumstances is that risk worth taking? Naively, we might reason that a majority in favor of a given hard-fork proposal might refrain from advancing it if they believe there’s a meaningful minority opposed to it, because splitting the network makes the currency less valuable for everyone. However, the majority might employ some game theory of their own, and reason that if there are enough of them, then perhaps the minority will feel coerced into going along with a change, because the minority risks the same downsides to splitting the network that the majority does. By proposing a miner vote with a 75% trigger to hard fork the network, Gavin’s proposal is a big game of chicken — with no good outcome for anyone.

I think this is the existential question for Bitcoin (or any other decentralized digital currency). If splitting the network in two is an easy thing for a majority to decide to do in the face of obvious opposition, then each of us must worry that we might someday be on the wrong side of a future split. Equally, one could interpret such an outcome differently: if Bitcoin’s network can split because there exists some person or people who are able to change the currency against the wishes of others, then perhaps it’s incorrect to think of it as lacking a central authority.

Taking either of these interpretations to their logical conclusion suggests that Bitcoin would be an essentially failed experiment. Because however you look at it, it would make much more sense to trust a known authority to run your digital currency (whether that’s a company or a government): many of the technical advantages of Bitcoin could remain and, indeed, future improvements could be more efficient to deploy, if we could jettison the technical baggage that comes from working on a decentralized currency. Of course, you also lose whatever hope you might have had that Bitcoin would be better than any currency backed by a central authority. Still, there could be something beneficial to society even in this case, and maybe Bitcoin could morph into a much better version of Paypal or Visa, and maybe that’s the local maximum that Gavin’s path forward could lead to. This may even be a net win for society compared with the status quo; however it would be an obviously disappointing outcome for many who have different, longer-term aspirations for the technology.

It’s fair to ask, if 75% of miners voting on what the hard fork should be is a bad idea, then what is a better trigger? This is a central challenge with hard forking changes to Bitcoin — I don’t think anyone knows the answer to that question. Pieter Wuille brought up this topic on the bitcoin-development mailing list and pointed out that any trigger using miner voting as a component should have a 100% threshold for the vote, because the whole point is that hard forks should not happen before everyone has had a chance to upgrade, so if some miners clearly haven’t upgraded their software, then it’s risky to change consensus while blocks may still be mined on the deprecated chain (which could cause confusion for users who haven’t upgraded). I think that is a reasonable point of view, and Gavin’s response to that appears to be (from the draft BIP):

A 75% supermajority was chosen so that one large mining pool does not have effective veto power over a blocksize increase.

This statement leaves me wondering whether an increase in mining centralization might cause Gavin or others, when proposing a future hard fork, to reduce this trigger down further? Could a 60% miner vote be appropriate the next time someone presses for a hard fork if there’s a 38% hash-rate mining pool in existence?

The problem is more complex than this, because miners shouldn’t want to vote in favor of a hard fork if they don’t believe that users will want to switch. But we also don’t have a great way of knowing what code users want to be running (users themselves are likely not aware of the technical details that go into Bitcoin, and so sensibly rely on the advice of technical experts to decide what software is worth running). Still, miners shouldn’t want to trigger a hard fork unless there is obviously no meaningful dissent, for the reasons above — and surely a 24.99% hash power mining operation represents significant risk of the network splitting in a meaningful way.

And that is not taking into account the already clear dissent from the people who are most expert in the field. Under some circumstances it may be difficult to tell whether there is unanimity or near-unanimity amongst people that a particular change to Bitcoin may be a good idea (say, to fix a known bug), but this isn’t one of those situations.

However, Gavin has a high profile, and as the technical leader of the project until last year, many still view him as the face of Bitcoin. He may have the power to sway users, merchants, and miners to go along with his code change against the advice of the other technical leaders. I urge rejection of consensus code changes that have not been accepted into Bitcoin Core, and in particular I would urge rejection of Gavin’s proposed code.

Much of the block size debate has been about technical tradeoffs, and especially concerns about scaling versus decentralization. Virtually everyone working on the project appears to believe it is important and valuable to figure out how to scale the network’s capacity, but there are differing opinions about how to go about it. I expect we’ll see technical consensus ultimately reached about deploying a different solution to increase block sizes, to give us a way forward with a much lower risk of splitting the network. But whether or not you agree with Gavin’s technical view on block sizes, the philosophy behind decentralized currencies is fundamentally incompatible with deploying his code in the way that he proposes.