How in the world would such a thing come to pass?
Well, as we saw in the case of the recent bug with LND nodes, if there is a bug in one implementation of Bitcoin that is not in other implementations, it can lead to a lack of consensus about whether a block is valid or not.
Bitcoin does not have a mechanism for fixing this. The community outside of the protocol has to decide what happens next. It sounds very unpleasant.
So much so that Bitcoin developer Peter Todd has said that
other implementations need to match Bitcoin Core bug-for-bug.
There you go: Multiple implementations are dangerous!
What Are The Other Implementations Of Bitcoin And Why Do They Exist?
First of all, most everyone runs Bitcoin Core.
Luke Dashjr sees about 43,000 nodes, 98% of which are running Bitcoin Core and something called Coin Dance sees close to 15,000 nodes, 96% of which are running Bitcoin Core. So, at the moment, it looks like very few people are using alternate implementations.
Nevertheless, there are active projects that are trying to build and maintain other codebases that implement the Bitcoin protocol. They include:
Jameson Lopp has an
excellent page with a more exhaustive list and links to all of the other implementations.
All of these projects have extremely talented developers working on them, and each has existed for more than a few years. Why put so much effort into something that seems like such a problem?
Bitcoin is permissionless. Anyone can download the chain; anyone can interact with the network; and nobody can stop you from coding or running an alternate implementation.
Yet, clearly some people are in charge of making changes to the Bitcoin repository and the process for choosing them seems informal. While there is the Bitcoin Improvement Proposal (BIP) process for suggesting changes to Bitcoin Core, it is also pretty informal.
None of this is a direct problem. As Marty Bent points out, rough consensus can be a strength. If the process of changing Bitcoin is difficult and unclear, it means that changes will be more thoroughly vetted.
The next step of rough consensus is having more than one popular implementation.
Not Having Multiple Implementations Might Be More Dangerous
There can be no doubt that it is already a very difficult job to be one of the people who has commit access to Bitcoin Core. In a world where Bitcoin plays a central role as a monetary instrument, this job will get much more difficult. A small group of developers could become a very worthwhile target. At the very least, their attention will be sought in order to lobby for various inclusions or exclusions in the next software release.
Think about the lobbying industry that currently exists in politics. Why wouldn’t such a thing develop around the people who have commit access to the only implementation of the Bitcoin protocol?
Like politicians now, they will be perceived to have access to power. As such, people will target them, except these developers won’t have the muscle of a state to defend them. What kind of life is that going to be? Who would voluntarily choose it?
At the end of the day, the global financial system is a pretty heavy weight to rest on the shoulders of the small group of people who have commit access to one GitHub repository. Maybe not so different from the global financial system we are trying to get away from where people’s monetary future hinges on the decisions of a few central bankers.
Multiple Implementations To The Rescue!
The presence and widespread use of multiple implementations on the Bitcoin network can mitigate these pressures by making it much more difficult for a malicious actor to change the Bitcoin protocol.
If participants in the Bitcoin network are more evenly distributed among different implementations, there is more room for good ideas to surface. Proposing changes to Bitcoin or rejecting them is a lot more decentralized if it isn’t all done in one camp.
Clearly, using different implementations of Bitcoin increases the risk of a chain split. A catastrophic chain split — where a significant portion of nodes and miners accidentally forked off — would not be good for Bitcoin, and certainly not its price. But it wouldn’t threaten Bitcoin’s permissionless nature.
A centralized development environment where everyone only builds on Bitcoin Core could threaten permissionless-ness. The conversation about the topic needs to address the risks of relying so heavily on Bitcoin Core rather than focusing solely on what problems might be caused by an alternate implementation.
There is a great, older
article about this debate by Aaron van Wirdum. You can also read a more recent, informative thread about it.
This is a guest post by Bill Scoresby. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.