This is an opinion editorial Bill Scoresby, bitcoin-based small business owner and writer of several guides to bitcoin self-control.
The bugs that recently caused many LND nodes to fall out of sync with the Bitcoin blockchain are likely caused by an alternate implementation.
You’re probably wondering, “Who else in the world uses Bitcoin Core?” You didn’t know that there are other applications of Bitcoin. Maybe you’re not sure what a different application means.
Bitcoin Core began as a piece of software written in C++ by Satoshi Nakamoto and released to the world. Updated with new versions leading up to date. An alternative implementation is one that does the same thing as Bitcoin Core – it applies the same consensus rules – but written in a different way, often in a different coding language.
How did the alternative implementation break the nodes in the lightning network?
One of the main Lightning Network node versions (LND) is based on an alternative Bitcoin implementation called btcd. When the developer created a very large multisig transaction, btcd did not consider it valid because it contained too much witness data. Other Bitcoin implementations—most notably Bitcoin Core—had no such restriction on the Taproot transaction’s witness data, and therefore considered the transaction and the block it contained valid.
As a result, miners kept adding new blocks to the chain because they weren’t using btcd and nothing was wrong with their rules, but LND Lightning nodes couldn’t recognize any of these new blocks because they were built on top of the block. a transaction they consider invalid.
When the bug reoccurred on November 1, it wasn’t just LND nodes that were affected. Some Electrum instances (backend server implementation for Electrum Wallet) failed to reach consensus with the rest of the chain. While LND nodes were removed from consensus due to a similar issue in btcd, it was an implementation of Bitcoin written in Rust that caused power nodes to lag behind, including some highly visible servers. Managed by mempool.space.
There is a limit to the size of witness data To prevent DoS attacks, and is also part of Bitcoin Core (although Core has a larger limit for Taproot transactions). Apparently there was code from the other two apps that got out of sync kept the small limit.
Very small differences in implementation can lead to a lack of consensus.
It’s Dangerous for Bitcoin to Have Multiple Applications
Satoshi didn’t like the idea of multiple Bitcoin implementations. “I don’t believe that a second, compatible application of Bitcoin will ever be a good idea.” The reason he gives is, “The design depends so much on all nodes getting exactly the same results when locking that a second implementation would be a threat to the network.”
A threat? What’s the big deal?
You’ve probably heard that the most proof-of-work chain is the real chain. When two different miners find a block at the same time, the chain splits and other miners start building on whichever block they hear about first.
As soon as a new block is added to one side of the split, most nodes and miners treat it as the new real chain and leave the other side of the split. Although some people call them orphan blocks, these blocks are called old 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 will win.
“Nodes will follow a reliable chain by working the most… The key word here is reliable. If a node receives a block it considers invalid, no matter how much work is done on that block, the node will not accept that chain.” – Andrew Chow
The key word is “valid”. A threat occurs when a miner finds a block that some other miners and nodes think is not valid. Miners who think it is valid will try to build new blocks on that chain. Miners who think this is not valid will try to build on the last valid block they know. Conclusion: Two chains and no way to know which is correct.
How in the world could such a thing happen?
Well, as we saw in the recent bug situation with LND nodes, if one implementation of Bitcoin has a bug that other implementations don’t, it can lead to a lack of consensus on whether a block is valid or not.
Bitcoin has no mechanism to fix this. The non-protocol community must decide what happens next. It sounds very unpleasant.
So much so that Bitcoin developer Peter Todd said that other applications should be compatible with Bitcoin Core bug-for-bug.
Here it is: Multiple apps are dangerous!
What Are Other Applications of Bitcoin and Why Do They Exist?
First of all, everyone runs Bitcoin Core.
Luke Dashjr sees around 43,000 nodes, 98% of which run Bitcoin Core, and something called Coin Dance sees around 15,000 nodes, 96% of which run Bitcoin Core. So, very few people are using alternative apps now.
Nevertheless, there are active projects trying to build and maintain other codebases that implement the Bitcoin protocol. They include:
Jameson Lopp has a great page with a more detailed list and links to all the other apps.
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 something that seems like such a problem?
Bitcoin is unauthorized. Anyone can download the chain; anyone can connect to the network; and no one can stop you from coding or implementing an alternative.
However, some people are responsible for making changes to the Bitcoin repository, and the process of choosing them seems informal. While there is a Bitcoin Improvement Proposal (BIP) process for proposing changes to Bitcoin Core, it is also quite informal.
None of these are direct problems. As Marty Bent points out, rough consensus can be power. If the process of changing Bitcoin is difficult and uncertain, it means that the changes will be more thoroughly checked.
The next step in rough consensus is to have multiple popular apps.
Not Having Multiple Apps May Be More Dangerous
There is no doubt that being one of the people with access to Bitcoin Core is already a very difficult task. In a world where Bitcoin plays a central role as a monetary instrument, this task will become even more difficult. A small group of developers can become a very valuable target. At the very least, their attention will be sought to lobby for various inclusions or exclusions in the next release of the software.
Consider the lobbying industry that currently exists in politics. Why wouldn’t something like this evolve around the people who have access to the only implementation of the Bitcoin protocol?
Now, like politicians, they will have access to power. So people will target them, but these developers won’t have the government muscle to defend them. What kind of life will it be? Who would voluntarily choose it?
At the end of the day, the global financial system is too heavy a burden to rest on the shoulders of a small group of people with access to a GitHub repository. Perhaps not so different from the global financial system we are trying to move away from, where people’s monetary futures depend on the decisions of a few central bankers.
Multiple Apps to the Rescue!
The availability and widespread use of multiple applications on the Bitcoin network can mitigate these pressures by making it much more difficult for a malicious actor to modify the Bitcoin protocol.
If the participants of the Bitcoin network are more evenly distributed among different applications, there is more room for good ideas to emerge. Proposing or rejecting changes to Bitcoin is more decentralized, if not all in one camp.
Obviously, the use of different applications of Bitcoin increases the risk of chain fragmentation. A catastrophic chain split — where a significant number of nodes and miners accidentally disconnect — would not be good for Bitcoin, and certainly not its price. But this will not threaten the permissionless nature of Bitcoin.
A centralized development environment where everyone builds only on Bitcoin Core can threaten unauthorized access. The conversation on the topic should address the risks of relying too heavily on Bitcoin Core, rather than just focusing on what problems an alternative implementation might cause.
Aaron van Wirdum has a great, old article about this debate. You can also read a more recent, informative thread about this.
This is a guest post by Bill Scoresby. The views expressed are entirely their own and do not necessarily reflect the views of BTC Inc or Bitcoin Magazine.