Several Bitcoin Implementations Are Dangerous CryptoBlog

This is an opinion editorial by Bill Scoresby, owner of a small bitcoin-based business and author of several bitcoin self-custody guides.

Bugs that recently caused many LND nodes to get out of sync with the Bitcoin blockchain were probably caused by an alternate implementation.

You may be wondering, “Who in the world uses anything other than bitcoin heartYou may not know that there are other Bitcoin implementations. Perhaps you are not sure what a different implementation means.

Bitcoin Core started as the software that Satoshi Nakamoto written in C++ and published globally. It has been updated with new versions leading up to the present day. An alternative implementation is software that does the same thing as Bitcoin Core – applies the same consensus rules – but is written differently, most often in a different coding language.

How did an alternate implementation break nodes on the Lightning Network?

One of the main versions of the Lightning Network node (NDL) relies on another Bitcoin implementation called btcd. When a developer created a very large multisig transaction, btcd would not consider it valid because it contained too much cookie data. Other Bitcoin implementations – most notably Bitcoin Core – had no such limit on Taproot transaction witness data, and therefore accepted the transaction and the block that contained it as valid.

The result was that the miners kept adding new blocks on the chain because they weren’t using btcd and according to their rules nothing was wrong, but the LND Lightning nodes couldn’t recognize any of these new blocks because they were built on top of the block containing that transaction which they considered invalid.

When the bug reoccurred on November 1, it wasn’t just the LND nodes that were affected. Some electrs instances (a backend server implementation for Electrum Wallet) also failed to reach consensus with the rest of the chain. While LND nodes were taken out of consensus due to a similar issue in btcd, it was a Bitcoin implementation written in Rust that causes electrs nodes to lagincluding some very visible servers run by

Cookie data size limit exist to prevent DoS attacks, and is also part of Bitcoin Core (although Core has a bigger limit for Taproot transactions). It looks like the other two implementations that got out of sync had code that maintained the smallest limit.

Very small differences in implementations can lead to a lack of consensus.

Having Multiple Bitcoin Implementations Is Dangerous

Satoshi didn’t like the idea of ​​multiple bitcoin implementations. “I don’t believe a second compatible Bitcoin implementation will ever be a good idea.” The reason he gave was: “Much of the design depends on all nodes achieving exactly identical results at the same rate that a second implementation would be a threat to the network.”

Threatens? What is the problem ?

You’ve probably heard that the chain with the most proof of work is the real chain. When two different miners find a block at the same time, the chain splits and the other miners start building on the block they hear about first.

As soon as a new block is added on one side of the split, most nodes and miners accept it as the new real chain and drop the other side of the split. These blocks are called obsolete blocks, although some people 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 keyword here is valid. If the node receives a block that it determines is invalid, no matter how much work has been done on that block, the node will not accept that chain. — Andrew Chow

The keyword is “valid”. The threat appears when a miner finds a block that other miners and nodes consider invalid. Miners who think this is valid will try to build new blocks on this chain. Miners who think this is invalid will try to build on the last valid block they know of. The result: two strings and no way to know which is true.

How the hell would such a thing happen?

Well, as we saw in the case of the recent bug with LND nodes, if there is a bug in one bitcoin implementation that is not in other implementations, it can lead to a lack of consensus on the validity or not of a block.

Bitcoin has no mechanism to solve this problem. The community outside of the protocol must decide what happens next. It seems very unpleasant.

So much so that Bitcoin developer Peter Todd said that other implementations must match bug for bitcoin core bug.

There you have it: multiple implementations are dangerous!

What are other bitcoin implementations and why do they exist?

First of all, almost everyone uses Bitcoin Core.

Luke Dashjr sees around 43,000 knots, 98% of them use Bitcoin Core and something called Coin Dance sees nearly 15,000 nodes, 96% of them use Bitcoin Core. So at the moment it seems that very few people are using alternative implementations.

Nevertheless, there are active projects trying to create and maintain other codebases that implement the Bitcoin protocol. They understand:

Jameson Lopp has a excellent page with a more comprehensive list and links to all 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 something that seems like such a problem?

Bitcoin is permissionless. Anyone can download the channel; anyone can interact with the network; and no one can stop you from coding or running another implementation.

Yet, clearly some people are in charge to make changes to the Bitcoin repository and the process for choosing them seems informal. While there is the Bitcoin Improvement Proposal (BIP) Process to suggest changes to Bitcoin Core is also quite informal.

None of this is a direct problem. As Marty Bent points out, a rough consensus can be a strength. If Bitcoin’s change process is difficult and unclear, it means the changes will be looked at further.

The next step in rough consensus is to have more than one popular implementation.

Not having multiple implementations could be more dangerous

There is no doubt that it is already a very difficult job to be one of the people who has access to Bitcoin Core. 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 could become a very interesting target. At the very least, their attention will be sought in order to lobby for various inclusions or exclusions in the next version of the software.

Think of the lobbying industry that currently exists in politics. Why wouldn’t such a thing develop around people who have commit access to the only implementation of the Bitcoin protocol?

Like politicians today, they will be seen 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 is it going to be? Who would voluntarily choose it?

Ultimately, the global financial system is quite a heavy weight that rests on the shoulders of the small group of people who have access to a GitHub repository. Perhaps not so different from the global financial system we are trying to get out of, where people’s monetary futures depend on the decisions of a few central bankers.

Several implementations to the rescue!

The presence and widespread use of multiple implementations on the Bitcoin network can alleviate these pressures by making it much more difficult for a malicious actor to modify the Bitcoin protocol.

If participants in the Bitcoin network are more evenly distributed among the different implementations, there is more room for good ideas to surface. Proposing changes to Bitcoin or rejecting them is much more decentralized if it’s not all done on one side.

Obviously, using different bitcoin implementations increases the risk of a chain split. A catastrophic chain split – where a significant portion of nodes and miners accidentally branched off – would not be good for Bitcoin, and certainly not its price. But that wouldn’t threaten the permissionless nature of Bitcoin.

A centralized development environment where everyone only builds on Bitcoin Core could threaten lack of permission. Conversation on the topic needs to address the risks of relying so heavily on Bitcoin Core rather than just focusing on the issues that could be caused by an alternative implementation.

There is a large, older article on this debate by Aaron van Wirdum. You can also read a newer version, informative thread on this subject.

This is a guest post by Bill Scoresby. The opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

Comments are closed.