Bitcoin faces a crossroads, needs an effective decision-making process

Joint post with Andrew Miller.

Virtually unknown outside the Bitcoin community, a debate is raging about whether or not to increase the maximum size of Bitcoin blocks. Blocks are created in Bitcoin roughly once every ten minutes and are currently limited to a size of 1 megabyte, putting a limit on the rate at which the network can handle transactions. At first sight this might seem like a technical decision for the developers to make and indeed it’s largely being treated that way. In reality, it has far-reaching consequences for the Bitcoin ecosystem as it is the first truly contentious decision the Bitcoin community has faced. In fact, the manner in which the community reaches — or fails to reach — consensus on this issue may set a crucial precedent for Bitcoin’s long-term ability to survive, adapt, grow, and govern itself. [1]

If the Bitcoin protocol is decentralized and no one controls it, then how can it be changed at all?

You may know that Bitcoin is a decentralized system and that no single company, government, or entity controls it. In that sense it’s a lot like the Internet. But unlike the Internet, which is an ad-hoc collection of networks and protocols, and thus can be gradually upgraded piecemeal, all Bitcoin nodes are basically part of one giant distributed computation which means that upgrades need to be much more tightly — dare we say centrally — coordinated. The default Bitcoin software, Bitcoin Core, is that point of coordination. The five Core developers have a huge amount of power in determining how the network operates and in making upgrades to it.

The developers don’t have all the power though — if changes made to Bitcoin Core are contentious, people running the software are free to go their own way, creating a “fork”. The distribution of power between the different entities in the Bitcoin ecosystem is fascinating and intricate, and we encourage you to take a look at Chapter 7, “Community, Politics, and Regulation” of our Bitcoin textbook-in-progress or the corresponding sections of the video lecture. The bottom line, though, is that while changing the Bitcoin protocol can and does happen, it requires consensus of a social kind. This is related to but different from the technical consensus protocol that Bitcoin miners execute.

There are numerous stakeholders in the block size debate with widely differing incentives

Most of the time, protocol changes are purely technical decisions. They might be deployed to increase the network’s efficiency or prevent potential attacks, so no one has a specific reason to oppose them beyond the general risk of making changes which may introduce new bugs or cause incompatible clients to diverge. But the block size debate is different. A decision to change the current policy of a fixed 1MB block size would affect virtually every group of Bitcoin stakeholders and, moreover, it would affect them differently.

At a high level, Bitcoin will likely evolve in different directions depending on whether the block size limit remains fixed or is increased. [2] With a fixed block size, transactions will become increasingly expensive because space for transactions on the block chain will become scarce. That means the Bitcoin network may be limited, directly handling only a few types of transactions such as settlement transactions between financial intermediaries. Transactions representing everyday purchases (“buying coffee with Bitcoin”) will get pushed off the main network into “side chains” or off-chain payment channels.

Various companies have made bets on one or the other future. Some have developed alternative blockchains or payment channels that would thrive in a fixed-block-size world whereas others such as Bitcoin payment processors stand to benefit from a growing block size that accommodates everyday transactions.

Another high-level impact is on mining: larger blocks will favor bigger miners. Bigger miners can more easily absorb fixed costs of storing larger blocks and verifying more transactions. More importantly, they can invest more in the necessary network infrastructure to quickly retrieve large blocks and can “peer” with other large miners directly to avoid costly delays in hearing about new blocks. Smaller miners will face higher processing costs as well as increased propagation delays on the public Bitcoin peer-to-peer network. Ultimately, many may drop out entirely. The resulting centralization of mining may leave the system more open to a 51% attack, making security worse for everyone. Similarly, it’s been argued that the number of independent entities running “full nodes” will decrease because of the increased storage and bandwidth, again weakening the decentralization and security of the system.

Finally, some of the development community’s implicit criteria are informed by the development process itself. For example, Gavin Andresen explains that proposal to increase the limit to 20MB is the “the simplest possible set of changes that will work,” and therefore the easiest to pass testing and code review. On the other hand, core developer Pieter Wuille has expressed concern that this increase is a stopgap solution, ultimately creating more “technical debt” to pay off later.

Resolving the block size debate — and similar contentious issues in the future — requires effective governance

A popular perception in the Bitcoin community is that Bitcoin doesn’t need governance, or at least structured governance. While Bitcoin may not need traditional governments, the very consensus process by which Bitcoin operates is an example of governance. So far, that governance has operated loosely without much formal structure — and this has worked well.

The key point of this post is that Bitcoin is now at a stage where the current process is no longer adequate. The block size debate is the first time in Bitcoin’s history that a change is being contemplated that will steer the ship in one of two (or more) very different directions. Virtually every participant in the Bitcoin ecosystem is touched by it, and their incentives are not all aligned. Keeping the block size constant is not the simple “status quo” option it may appear to be. Due to continuously increasing transaction volume, Bitcoin will surely change significantly even if nothing is done. The debate is an old one within the community, but it has now started to become urgent. [3] And while this might be the first such contentious issue, it won’t be the last: a decision will need to be made on sidechains soon, attacks might be discovered that can’t be fixed to everyone’s satisfaction, and over the long run there’s always the question of whether mining will survive the repeated halving of block rewards or whether some changes are necessary.

What do we want out of a governance process for deciding debates such as this? First, every stakeholder’s voice should be heard. Not only should it be technically possible for them to air their views, but the community should actively and systematically seek their input. Second, it should be clear how different stakeholders’ views were weighed against each other and how trade-offs were made. Third, the stakeholders and other observers should be convinced that there were no back-channels to the Core developers — who are, after all, the ones with the technical ability to push changes. Fourth, there should be a transparent transcript of all the inputs and the decision-making process, so that if the decision that was made turns out to be sub-optimal, there’s a way to revisit it using the logs and learn lessons for the future.

Bitcoin’s current governance model is seriously inadequate

So far, the bitcoin-developers mailing list has been the primary place for discussion of technical changes to Bitcoin, augmented by the Bitcoin Improvement Proposal (BIP) process, GitHub’s issue tracker, IRC channels, and a “long tail” of other avenues: the Bitcointalk forum, blog posts, Twitter, Reddit, and, of course, conferences and other physical meetings. While this model worked great as long as proposed changes were purely technical, it breaks down for contentious issues. In fact, it satisfies virtually none of the criteria we laid out above.

First of all, many stakeholders such as miners aren’t participating in the debate, either because they’re not aware of the effect of the decision on their interests or because they don’t realize they have a voice. The Core developers seem to do their best to take miners’ views into account, but often this amounts to informed guessing. None of the groups other than developers post regularly on the developer mailing list, which is entirely natural — the interface isn’t familiar to non-developers, resulting in a lot of friction, not to mention a lot of noise considering that the vast majority of discussions are about technical issues of no interest to non-developers. Miners sometimes post on the Bitcointalk forum, but for the most part they don’t voice their views publicly. As for Bitcoin companies, venture capitalists, and other relatively privileged groups, their best way to influence the decision is to communicate directly, and perhaps privately, with the developers.

Furthermore, the plethora of public channels ironically serves to decrease transparency. It’s not clear which of these are noticed — and valued — by the developers. And there’s the danger that whoever shouts the loudest will drown out other more reasonable voices.

As a result, what’s happened so far is this: the block size debate has been up in the air for years (for example, see this thread from October 2013). Developers seem to have waited for technical consensus to occur naturally — as it usually does — perhaps not fully realizing the extent to which this debate is different from the purely technical ones of the past. Everyone who is speaking now has already weighed in, while a variety of others who should be heard from have still today remained silent. It’s not clear to anyone how the decision will ever be made and a bit of panic is starting to set in. [4]
 

Bitcoin urgently needs formal governance

Structurelessness is a myth. [5] What we’ve been seeing is Bitcoin’s latent, informal governance structure manifest itself. While it’s been effective for most decisions, in this case it’s led to confusion and inaction. The only way out of this mess is more explicit, well thought out, structured governance.

Of course, that’s going to be a tough pill to swallow, both because of the politics of many in the Bitcoin community and because of what happened with the Bitcoin Foundation. The allegations of corruption and lack of transparency the Foundation has faced are precisely the kinds of things that can go wrong with formal governance. A crucial difference, though, is that the Bitcoin Foundation focused on loosely defined goals like advocacy rather than protocol changes to Bitcoin. A governance process for Bitcoin Core — and nothing else — could be far more light-weight and transparent. Hopefully, if it worked well, it would only need to be invoked occasionally.

Rejecting governance altogether is not an option. To meet the challenges now facing it — to grow up — Bitcoin will have to develop effective governance. The current debate, then, is a rite of passage.

Three suggestions for better governance

In keeping with the light-weight yet formal approach to governance we’ve suggested, here are three suggestions for more effective governance for Bitcoin Core. We intend these to be a starting point for discussion. Note that each of these can be adopted individually.

1. Form a technical advisory board. Many open-source projects utilize an advisory board as one governance mechanism. For Bitcoin Core, the goal would be to bring the different types of stakeholders together to deliberate major or controversial decisions. For each such change, the board will produce a document that describes the inputs, the output(s), and the criteria that were used to make the decision — especially who the stakeholders are, their opinions and interests, and how their interests were weighed. By being more methodical, the advisory board’s deliberations would hopefully also be more scientific than the current process. [6]

The output of the advisory board wouldn’t be binding in any way on the Core developers, but if Bitcoin Core departs in a significant way from the advisory board’s recommendations, then it’s a sign that something is seriously wrong.

2. Create a polling mechanism and a public comment process. Let’s make better use of Bitcoin’s unprecedented capability to have built-in voting and opinion polling mechanisms. The challenge of Bitcoin governance is actually a great opportunity, since Bitcoin’s technical innovations include new tools for effective governance! For example, miners can express their preferences and vote on decisions by putting data into block headers (in other words, votes are weighted by proof-of-work). This has already used by Core developers in the rare “soft-fork” upgrade procedure, but proof-of-work voting could also be used more frequently even when it isn’t so urgent. Investors — people who hold bitcoins — can similarly vote via proof-of-stake. Regular users running Bitcoin nodes could vote if a polling mechanism is built into Bitcoin Core, although this would require some way to prevent sybil attacks. All these stakeholders are important, so no one voting mechanism is superior to the others. None of these votes would be binding and they’re better thought of as opinion polls. The idea is to give the Core developers actual data on how each contingent feels about a decision, and to collect such data in ways that can’t be easily gamed.

We also recommend a public comment process analogous to what most federal agencies use to solicit inputs for decision-making. This would give a voice to merchants, payment services, exchanges, and other such entities whose opinions can’t be as easily captured through built-in polling mechanisms. Public comments would be written documents as opposed to votes. Unlike polling, these would not be anonymous and, indeed, the identity of the respondents would be important for evaluating the comments.

3. Reach consensus on evaluation criteria and tradeoffs in advance of the actual discussion. In a way, this is the most important suggestion — it directly addresses the reason why we think the block size debate is currently going nowhere. Instead of simply re-hashing the not-directly-comparable pluses and minuses of each option, the community must first reach consensus on how competing interests will be balanced against each other. The first two suggestions can be seen as ways to make this easier, but even in their absence, “meta-discussion” is essential to break out of the gridlock.

In summary, the current block size debate has made it clear that the decision-making process for the Bitcoin protocol is lacking. But the need for structured governance was anticipated long ago in a paper by Kroll, Davey and Felten at Princeton. [7] The problems we’ve pointed out aren’t new and some Bitcoin developers have already at times hinted at the need for improvement (for example, here’s Matt Corallo’s post about the need for discussing decision criteria, incentives, etc). But sometimes it’s more apparent from the outside when a process needs to change and adapt. We hope the suggestions we’ve laid out will be a starting point for some much-needed changes.

[1] Gavin Andresen has been the main public proponent of increasing the block size. His blog post earlier this year addressing the technical feasibility of a block size increase (and acknowledging that “economic arguments” remained) kicked off the latest round of debate, which has reached a crescendo over the last week.

[2] We’re simplifying a bit and considering only the two main options: keeping the block size fixed vs. growing it indefinitely as necessary over time to accommodate demand. There are various other possibilities such as allowing the market to decide the size of each block. For some examples, see here.

[3] The chart is a projection of when the current limit will become insufficient, but some have suggested that things could come to a head far sooner, say due to a flooding attack.

[4] For example, Mike Hearn is quite pessimistic about the ability of the developer community to reach consensus.

[5] The link goes to a famous essay reflecting on the feminist movement in the 1960s. The movement resisted organizational structure, viewing structure as oppressive. The author argues that structureless groups don’t exist, that the only choice is between formal and informal structure, and that formal structure is necessary for effective action, especially in large groups. The similarities to Bitcoin’s current quandary are remarkable.

[6] Emin Gün Sirer has also suggested a Technical Advisory Board. Some of his other Tweets on the topic: “The #Bitcoin blocksize debate, at the moment, is being waged in a way that has nothing to do with science. A TAB can help refocus.” and “The most critical thing to do on the #Bitcoin dev front is to help elevate the discussion, from half-baked forum posts to proper science.”

[7] The paper identified the dwindling block reward as the key challenge that would require governance. However, much of what they said parallels what we’ve said here about the block size debate:

“…we argue that Bitcoin will require the emergence of governance structures, contrary to the commonly held view in the Bitcoin community that the currency is ungovernable.”

“The only way to preserve the system’s health will be to change the rules … Different groups benefit from each solution … The choice is likely to drive political disputes within the Bitcoin community …  A political choice such as this is difficult to make without some sort of governance structure, even if an informal one.”

The authors also point out that: “Other challenges to the system’s health and viability may also emerge, perhaps due to issues of scaling or security.” The block size is, of course, primarily a scaling issue.