As one of its most important properties and a key selling point, Bitcoin is not controlled by any government, (central) bank or company. Nor is there even an active inventor to call the shots, as is the case in many other open-source projects. But that doesn’t mean the peer-to-peer electronic cash system is not governed by humans at all.
Many attribute this governance role to the Bitcoin Core development team. This is a misguided attribution, however. While Bitcoin Core developers may have an influential position, Bitcoin is really governed by only two groups of people: users and miners.
Bitcoin Implementations
Bitcoin itself is essentially nothing but a protocol; a language shared by computers. And importantly, Bitcoin is an “open” protocol: there are no gatekeepers or requirements to become part of the Bitcoin network, other than following this protocol.
Anyone with the required skill-set can develop software to follow the protocol. But the easier option, of course, is to simply download and run software developed by others.
There are currently several Bitcoin software implementations to choose from, as well as forks (near copies) of these implementations. The most used of these is probably still Bitcoin Core, the software stack that evolved from Bitcoin inventor Satoshi Nakamoto’s original Bitcoin implementation. But Libbitcoin, Bitcoin XT*, Bitcoin Classic* and a handful of other implementations all follow the same protocol too and exist on the same network side by side.
(*Bitcoin XT and Bitcoin Classic are programmed to deviate from the current Bitcoin protocol if certain conditions are met, but do follow the current Bitcoin protocol until then.)
Frankly, all these implementations and forks are “governed” by their respective developers in whatever way these developers want. Where Bitcoin Classic developers set up a (non-binding) consider.it page to crowd-source ideas on the direction of development, former Bitcoin XT lead developer Mike Hearn was more willing to act as a “benevolent dictator.”
Bitcoin Core is governed by a loosely meritocratic process of peer review and rough consensus among its most active contributors. This is guided by the — theoretically implementation-independent — Bitcoin Improvement Proposal process and moderated by Bitcoin Core lead developer, Wladimir van der Laan, as well as several developers with commit access. Libbitcoin is governed in a similar fashion but with lead developer Eric Voskuil as its moderator.
The important thing, however, is that governance of Bitcoin implementations — including Bitcoin Core — is fundamentally distinct from governance of Bitcoin itself. Whatever code change Bitcoin developers adopt and release really only exists as a series of ones and zeros hosted on websites like bitcoin.org or bitcoincore.org. It has no bearing on the Bitcoin network itself.
It’s only if actual Bitcoin users download and run a new release on their own computers that it can become part of the Bitcoin network. And, of course, developers have no control over which software people run on their own computers. Anyone who runs Bitcoin Core or any other Bitcoin implementation does so autonomously and voluntarily.
Developers are, therefore, perhaps best understood as tool providers with what could be considered a sort of advisory role. Their influence is limited to offering people software they can use to connect to the Bitcoin network if they want to.
Governing the Protocol
Bitcoin governance itself ultimately emerges from users through the software they run on their computers.
This type of governance is perhaps best compared to human languages. While no single governing body has historically really been in charge of the English language, many people do voluntarily choose to apply the same grammar rules in order to communicate. People “govern” the English language by using it.
Those who communicate in English with many people — perhaps popular news anchors — will have a stronger influence on the English language. Those who communicate with fewer people, like secluded monks, will have a weaker influence. Similarly, the amount of influence Bitcoin users exert on the protocol depends on their participation.
More specifically, bitcoin is really only useful (and therefore valuable) if people accept it as payment. Accepting bitcoin as payment, therefore, adds value to the specific set of protocol rules applied to accept the payment.
Users that accept more payments (or payments of higher value) carry more weight within the network. If many Bitcoin users want to transact with AlphaBay or BitPay, such companies can have a greater impact on Bitcoin’s protocol rules and, therefore, on Bitcoin’s governance process.
And since only fully validating Bitcoin nodes apply to all protocol rules, users who run these “full nodes” have a stronger impact on Bitcoin’s governance process as well.
Bitcoin developers — Core or otherwise — add weight to the Bitcoin protocol to the extent that they are users. But their status as developers grants them no special privilege, even if they wanted it to.
Changing the Protocol
Applying and enforcing existing protocol rules is easy. Changing Bitcoin’s protocol rules is often much harder.
Some protocol changes can be applied by a subset of participants of the Bitcoin network (kind of how slang can be applied by a subset of English speakers). But other protocol changes require network-wide agreement: consensus. Even small differences may cause different Bitcoin implementations to become entirely incompatible with each other. This could lead to a “blockchain fork,” splitting the Bitcoin network into two or more separate networks and, therefore, two or more separate currencies.
(Which changes require consensus, and which do not, is explained in more detail here.)
Some incompatible changes to the Bitcoin protocol therefore require all users to apply the new rules at some agreed-upon point in time. Everyone must switch to an entirely new network, incompatible with the old network, or else two different networks will exist. Put differently; everyone must start using an entirely new “coin” and must agree that this coin is the new bitcoin.
The real challenge, therefore, is not so much writing new code or even creating a new network. The real challange is convincing everyone to switch to this new network and consider it the new bitcoin.
Once again, Bitcoin developers have no special powers to make users switch to a new network — except to the extent that users may choose to follow their advice. Even if the Bitcoin Core developers were to release a new version of their software to create such a new network, users of the older software implementations could simply ignore the update and continue using the existing protocol as they please.
(It should be noted that a subset of users can always opt to switch to a new network even if not everyone else agrees. It may just be unlikely that everyone will consider this new coin to be the “real” bitcoin.)
Soft Forks
Getting everyone to harmoniously switch to a new protocol is no easy task. That’s why the current Bitcoin Core development team prefers to change the protocol in such a way that not everyone needs to switch at the same time — or at all.
Through “soft forks,” the existing Bitcoin protocol can be changed within the bounds of the current protocol. They “limit” the existing rules. Though through clever tricks — liketheseones — soft forks can actually be deployed to expand Bitcoin’s capabilities.
Soft forks achieve this by deeming transactions that would previously have been considered valid as invalid. And since not all users, but only miners, decide which transactions are included in blocks, soft forks can be carried out by a mere majority of miners by hash power. (Any minority miner that doesn’t switch may have its blocks rejected by the majority, while still following the majority chain; there can be no blockchain split.)
In today’s relatively centralized mining landscape, where only a small subset of users mine (and an even smaller subset of users control mining pools), very few users can enforce soft forks. Bitcoin Core developers therefore only propose soft forks they believe should be uncontroversial. These soft forks also require 95 percent hash power support, rather than a mere majority. And they only propose soft forks that clearly signal that the protocol will change, so all users can upgrade their software or take alternative precautions, if that is what they want.
Of course, miners can soft-fork without support from developers or Bitcoin’s broader user base as well. But if miners act against user interests, there is a possible solution. The Bitcoin protocol can be changed to require a new mining algorithm, instantly making specialized mining hardware obsolete. This should re-decentralize mining from industrial farms back to regular computers at least temporarily, effectively firing the current set of miners. Some Bitcoin Core developers maybesupportive of such a change in some instances. Once again, of course, developers could only propose such an incompatible change. Users would have to adopt it.