Open-source Governance in Bitcoin

Josh Kroll, Ian Davey, and I have a new paper, The Economics of Bitcoin Mining, or Bitcoin in the Presence of Adversaries, from the Workshop on Economics of Information Security. Our paper looks at the dynamics of Bitcoin, how resilient it would be in the face of attacks, and how Bitcoin is governed. Today I want to talk about governance in Bitcoin.

I wrote previously about how Bitcoin relies on two forms of consensus: a social consensus about the rules that govern which transactions and log blocks are considered valid, and an informational consensus about the contents of the Bitcoin log (a list of all the transactions that have occurred). These two forms of consensus make possible a third consensus: that Bitcoins have value. I described in the previous post how the Bitcoin community has changed the rules, by consensus, to deal with technical mishaps. We argue in our paper that further rule changes will be necessary to deal with longer-term economic challenges, such as how to maintain a sufficient level of mining activity.

At present, governance of Bitcoin is tied together with governance of the Bitcoin reference software, because most people either use the reference software or emulate its behavior. So Bitcoin has a de facto governance structure, based on the governance of the reference software—and in fact the lead developers of the reference software are seen as leaders in the Bitcoin community.

The reference software follows a standard open-source model. And the political dynamics of open-source projects are interesting. Typically there is a person or group who makes final decisions about which proposed changes to the software are accepted into the next release. In one sense, these deciders might seem to have absolute power to determine the direction of the software. But their power is limited by the possibility that someone will fork the software. Anyone, at any time, can create their own version of the software, by copying the code and then setting themselves up as deciders for the new “forked” copy. Of course, the fork is unlikely to survive or to have any importance at all, unless a substantial number of participants switch from the original version to the forked version.

So the possibility of a fork disciplines the deciders. As long as their decisions are well-aligned with the interests of the participants, then there is little chance that participants would want to start or join a fork. But if the deciders start to deviate from what participants want, then a fork becomes likely—and the forked version may acquire dominant market share and become the new de facto standard. It’s a standard story about how the possibility of exit disciplines the leaders of a group—except that forking is an especially strong form of exit in which the departing members get to keep using and improving the group’s main product, so the right to fork gives members more power than a simple right to exit would.

But it’s not just the Bitcoin software that can fork. It’s also possible for the Bitcoin rules to fork. Imagine that half of the Bitcoin community started following Ruleset A, while at the same moment the other half started following Ruleset B. (Either A or B could be the same as the current rules; that doesn’t matter.) The result would be a fork in the Bitcoin log—the two groups would agree on the history up until the rule-fork, but after the rule-fork each group would have its own idea of the log, reflecting its own understanding of the history of Bitcoin transactions that had occurred.

In effect, this would be a fork of the currency. What was once a single Bitcoin currency would be replaced by two currencies, which we might call BitcoinA and BitcoinB, which had different rules and diverging histories. If you owned a single Bitcoin at the fork point, then just after the fork point you would own a single BitcoinA and a single BitcoinB, which you could then dispose of separately. As with a software fork, either branch might end up dying out due to lack of interest, but it’s also possible that both could survive in the long run. Whatever power the lead software developers, or anyone else, might have to control the rules of Bitcoin will be limited by the ability of others to fork the rules, and therefore to fork the currency.

(To be clear: forking the currency is not the same as starting a new currency with your own rules. What makes a fork special is that the forked version considers the original version to be valid, and its rules to be governing, up until the fork point. A fork is like a religious schism, in which each branch considers itself to be the one true successor of a common tradition.)

Bitcoin is a new kind of thing: a currency whose rules are determined by open-source governance.

What does this mean for governments that want to regulate Bitcoin? I’ll consider that question in a future post.