Multiple Bitcoin Implementations Are Dangerous – Bitcoin Magazine
This is an opinion editorial by Bill Scoresby, a bitcoin-based small business owner and author of several bitcoin self-storage guides.
The bugs that recently caused many LND nodes to fall out of sync with the Bitcoin blockchain were likely caused by an alternate implementation.
You might be wondering, “Who the hell uses anything but Bitcoin Core?” You may not have known that other implementations of Bitcoin existed. Maybe you’re not sure what another implementation means.
Bitcoin Core began as the software that Satoshi Nakamoto wrote in C++ and released to the world. It has been updated with new versions leading up to today. An alternative implementation is software that does the same thing as Bitcoin Core – enforces the same consensus rules – but is written differently, usually in a different coding language.
How did an alternative implementation break nodes on the Lightning network?
One of the major Lightning Network node versions (LND) relies on an alternative Bitcoin implementation called btcd. When a developer created a very large multisig transaction, btcd did not see it as valid because it contained too much witness data. Other Bitcoin implementations—most notably Bitcoin Core—had no such restriction on taproot transaction witness data, and therefore accepted the transaction and the block containing it as valid.
The result was that miners continued to add new blocks to the chain because they were not using btcd and according to their rules nothing was wrong, but the LND Lightning nodes could not recognize any of these new blocks because they were built on top of the block that contained the one transaction they saw as invalid.
When the failure occurred again on November 1, it was not only LND nodes that were affected. Some electrs instances (an implementation of the Electrum Wallet backend server) also failed to reach consensus with the rest of the chain. While the LND nodes were kicked out of consensus due to a similar problem in btcd, it was an implementation of Bitcoin written in Rust that caused electricity to fall behind, including some highly visible servers powered by mempool.space.
The limit on the size of witness data exists to prevent DoS attacks, and is also part of Bitcoin Core (although Core has a larger limit on Taproot transactions). It appears that the other two implementations that fell out of sync had code that maintained the smaller limit.
Very small differences in implementations can lead to a lack of consensus.
Having multiple implementations of Bitcoin is dangerous
Satoshi did not like the idea of multiple implementations of Bitcoin. “I don’t think another compatible implementation of Bitcoin would ever be a good idea.” The reason he gave was, “So much of the design depends on all nodes getting exactly identical results in lockstep that a new implementation would be a threat to the network.”
Threat? What is the problem?
You’ve probably heard that the chain with the most proof-of-work is the true chain. When two different miners find a block at the same time, the chain splits and other miners start building on the block they hear about first.
As soon as a new block is added to one side of the split, most nodes and miners accept it as the new true chain and leave the other side of the split. These blocks are referred to as stale blocks, although some call them orphan blocks.
Since the average time between blocks in Bitcoin is 10 minutes, it is likely that the entire network will learn about this new block before one is added to the losing side of the split, and the chain with the most work wins.
“Nodes will follow the valid chain with the most work… The key word here is valid. If the node receives a block that it determines is invalid, it doesn’t matter how much work is done on top of that block, the node will not accept that chain. ” -Andrew Chow
The keyword is “valid”. The threat arises when a miner finds a block that some other miners and nodes believe is not valid. Miners who believe it is valid will try to build new blocks on that chain. Miners who believe it is not valid will try to build on the last valid block they know of. The result: Two chains and no way of knowing which is true.
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.
