How on earth could such a thing happen?
Well, as we saw in the case of the recent failure of LND nodes, if there is a flaw in one implementation of Bitcoin that is not in other implementations, it can lead to a lack of consensus on whether a block is valid or not.
Bitcoin has no mechanism to fix this. The community outside the protocol must decide what happens next. It sounds very unpleasant.
So much so that Bitcoin developer Peter Todd has said that other implementations must match Bitcoin Core bug-for-bug.
Like this: Multiple implementations are dangerous!
What are the other implementations of Bitcoin and why do they exist?
First of all, most people run Bitcoin Core.
Luke Dashjr sees around 43,000 nodes, 98% of which run Bitcoin Core and something called Coin Dance sees close to 15,000 nodes, 96% of which run Bitcoin Core. So at the moment it seems very few people are using alternate implementations.
Nevertheless, there are active projects 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 the other implementations.
All of these projects have extremely talented developers working on them, and each has been around for more than a few years. Why put so much effort into what seems like such a problem?
Bitcoin is permissionless. Anyone can download the chain; anyone can interact with the network; and no one can stop you from coding or running an alternative implementation.
Still, someone is clearly 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 proposing changes to Bitcoin Core, it is also quite 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 investigated.
The next step in rough consensus is to have more than one popular implementation.
Not having multiple implementations can be more dangerous
There can be no doubt that being one of the people who have committed access to Bitcoin Core is already a very difficult job. In a world where Bitcoin plays a central role as a monetary instrument, this job will become much more difficult. A small group of developers can be a very worthy target. At the very least, their attention will be sought to lobby for various inclusions or exclusions in the next software release.
Consider the lobbying industry that currently exists in politics. Why wouldn’t something like this develop around the people who have committed access to the sole implementation of the Bitcoin protocol?
Like politicians now, they will be perceived as having 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 will it be? Who would voluntarily choose that?
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 committed access to one GitHub repository. Perhaps not so different from the global financial system we are trying to get away from where people’s monetary futures depend on the decisions of a few central banks.
Multiple implementations to the rescue!
The presence and widespread use of multiple implementations on the Bitcoin network can mitigate this pressure by making it much more difficult for a malicious actor to change the Bitcoin protocol.
If the participants in the Bitcoin network are more evenly distributed among different implementations, there is more room for good ideas. Proposing changes to Bitcoin or rejecting them is much more decentralized if everything is not done in one camp.
Using different implementations of Bitcoin clearly increases the risk of a chain split. A catastrophic chain split – where a significant portion of nodes and miners accidentally defected – would not be good for Bitcoin, and certainly not its price. But that wouldn’t threaten Bitcoin’s permissionless nature.
A centralized development environment where everyone only builds on Bitcoin Core could threaten the permissionlessness. The conversation on 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 alternative implementation.
There is a great older article on 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 the opinions of BTC Inc or Bitcoin Magazine.
