Competing with Bitcoin Core

Abstract: We examine the power and dynamics of the “Bitcoin Core” software project and we draw distinctions between the various different ways one can compete with the project. We address the misconception that the Bitcoin Core software repository has the unique capability to change or prevent changes to Bitcoin’s consensus rules. We also discuss some common misconceptions and explain that if the Bitcoin Core repository becomes hijacked by nefarious actors or deleted, Bitcoin should be largely unaffected.

Venn diagram illustrating the various ways to “compete” with Bitcoin Core

(Sources: Bitcoin ABC, Bitcoin UASF, BTCGPU, Bitcoin XT, BTC1, Bitcoin Classic, Bitcoin Cash Cobra, Bitcoin SV, Bitcoin Unlimited, BitcoinX, Bitprim, Bcoin, Parity Bitcoin, BTCD, Libbitcoin, Caesure, Bits of Proof, Bitcoinj, Ufasoft Coin, Bitcrust, Picocoin, Bitcoin Addrinex, Bitcoin Knots, Bitcoin-RBF, Bitcoin BitMEX Research)

The three kinds of competition

One can categorise competing software projects with Bitcoin Core into three different groups:

Type of competition Explanation
Competition between chains This is when the competing software project deliberately has a different set of consensus rules to the implementations the users currently run. This includes both hardforks and softforks. Running such software can be considered risky in certain circumstances, as it can split the coin into two chains.

Therefore this kind of competition is between different coins/chains, rather than  merely competing with a different implementation of Bitcoin. Indeed if one does a software fork of Bitcoin Core and changes the consensus rules, most of the code is still likely to be written by the same development team, so it is not really competing against the team, but potentially launching a new coin whose code was written by that same team.

Competition between independent implementations This form of competition occurs when Bitcoin is re-implemented without using the code from Bitcoin Core. Typically a new coding language is used; to try to capture some advantages other languages may have.

Like the above form of competition, many consider this form of competition risky, as it may increase the chance of unplanned chain splits, caused accidentally by different consensus rules. The alternative client needs to match the consensus behaviour of the software users currently run, even matching bugs or unintended behaviour in the majority client.

Other competing software projects (which neither change the consensus rules nor re-implements the codebase) One can compete with Bitcoin Core by neither trying to change the consensus rules nor by writing a new independent codebase. One can do this by creating a software fork of the project and then making only non consensus changes.

This type of competition does not share many of the risks mentioned above.

The debate over competing consensus rules

This topic has been widely discussed in the Bitcoin community, largely in the context of the “blocksize war”, which ran from the summer of 2015 to November 2017. We are not going to repeat all those arguments in this report, where the primary purpose is to articulate the different types of competition.

In favour of competition Opposed to competition
Competition over the rules should be encouraged, since this ensures the coin is flexible and able to adapt and compete. The model of the status quo ruleset always prevailing mean that the rules may never change, even when the case is highly compelling, as in this contentious environment a minority will always oppose any change.

Competition over the rules is far less likely to cause significant disruption than many people think. In reality large businesses and the community will quickly rally behind one coin and change the client they run to follow the economic majority or hashrate majority.

It is best to try to avoid competition over the consensus rules, as doing so is risky and damages the stability of the coin. In the event of a dispute, the existing consensus rules should prevail, this keeps the existing rules of the coin, such as the 21 million cap robust, a key and unique property of Bitcoin. The disruption which can be caused by changing the consensus rules without widespread agreement, is therefore a highly desirable characteristic of Bitcoin.

Changing the consensus rules should therefore occur in one of the following two ways:

  1. With widespread agreement across the community of coin users and technical experts.  Sufficient time must also be given for users to upgrade their clients
  2. If developers are unsure if a sufficient number of users will upgrade to the new rules, this could result in the launch of a new coin. In this case various safety measures such as strong two way replay protection and chain wipeout protection (for both fully verifying clients and light clients) may be necessary to reduce the risk of users losing funds

(If the change in the rules is a softfork (as opposed to a hardfork), it may be possible to prevent a chainsplit if the majority of miners upgrade)

The debate on competing independent implementations

As above, this is also a very controversial and divisive topic, however we still think it’s a fundamentally different issue to competition over deliberate changes to the consensus rules.

In favour of competition Opposed to competition
Although one dominant implementation may protect the network from unexpected consensus bugs, it may leave the coin exposed to certain types of critical bugs, such as bugs which caused clients to crash or allow unexpected coin inflation to occur. A recent example of this is CVE-2018-17144, a critical inflation bug only discovered in September 2018.

If, for example, there were ten independent implementations, each with a 10% market share, if a bug occurred on one of the implementations which caused it to crash or caused inflation, 90% of the network could continue as normal. The network would therefore become more resilient. Diversity of the clients users run is therefore a key strength.

The strongest opponent of this form of competition was probably Satoshi, he/she famously said:

I don’t believe a second, compatible implementation of Bitcoin will ever be a good idea.  So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.  The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.

A second version would be a massive development and maintenance hassle for me.  It’s hard enough maintaining backward compatibility while upgrading the network without a second version locking things in.  If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version.  If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version. This is a design where the majority version wins if there’s any disagreement, and that can be pretty ugly for the minority version and I’d rather not go into it, and I don’t have to as long as there’s only one version.
(Source: Bitcointalk)

Although ten popular implementations might be good, the issue is the transition from one dominant implementation to a diversity of popular clients, without entering dangerous territory such as two popular independent implementations, each with a 50% market share, leaving the network vulnerable to consensus bugs. Therefore a better plan may be to have one dominant implementation which is highly scrutinized, to keep consensus bugs to a minimum. This way the network may be reliable for all users, even 10% of a minority chain may be a problem for that 10%.

Other competing clients

Even if one really likes a robust ruleset, opposes competition over the consensus rules and one religiously follows Satoshi’s negative view about competing implementations, this does not mean one cannot have competing software projects. The competition can simply be in the white area, outside of the circles in the above venn diagram. This form of competition, which neither initiates a deliberate change to the consensus rules nor re-implements the code, is not controversial at all, as far as we can tell.

Therefore in theory Bitcoin never needs to suffer from the apparent problems of who controls a particular software repository in Github or arguments over who has commit access to the repository. In our view, many of these apparent problems are based on a misunderstanding, by people who appreciate some of the risks of competing software projects, but fail to distinguish appropriately between the different types of competition. Therefore many seem to overestimate the power of the Bitcoin Core software repository, thinking that any competition is risky or somehow unacceptable.

Bitcoin Core’s genesis

Prior to 2013, there was no software project named Bitcoin Core. The Satoshi client was sometimes just called the reference implementation or Bitcoin-QT/Bitcoind. Then in February 2013, Gavin Andresen, a prominent Bitcoin developer, posted to the Bitcoin Foundation forum asking:

There was some discussion about renaming Bitcoin-Qt and the reference implementation in general in IRC today; I thought some of you smart people might have good name ideas.

Mike Hearn, another developer, then responded:

Oh good, about time. This has irritated me for a while. How about Bitcoin Core?
(Source: Bitcoin Foundation Forum)

Many then started referring to the software project as “Bitcoin Core”, but nothing actually changed. Bitcoin Core then began to develop a strong brand, associated with prudence and stability, or as Gavin said at the time, “[its] like a rock”.

The impact of the “blocksize war”

During the blocksize war, many characterised the debate as being Bitcoin Core vs miners or large businesses, with the Bitcoin Core side opposing hardforks and blocksize limit increases. In our view the characterisation was mostly incorrect. However, many who made this characterisation then subsequently concluded that Bitcoin Core won, since there was no hardfork. This same group therefore currently overestimate the power of Bitcoin Core, in our view.

Bitcoin Core is not as powerful as many people think

It is not the Bitcoin Core software repository that defines Bitcoin’s consensus rules. The rules are defined by the clients economically significant users currently run. These are typically previously released versions of Bitcoin Core. The Bitcoin Core software project cannot change what software users are running and the users are a lot more independent minded than many people think, in our view. Even if Bitcoin Core had released a hardfork client, which increased the blocksize limit, it is not clear if the community would have upgraded. Therefore concerns about the Bitcoin Core software repository becoming deleted, hacked or hijacked should be far less of an issue than many people think. If this happens it will not affect clients users are already running and if further upgrades or improvements are needed, one can simply switch to a different repository or many different repositories, without worrying about any coordination problem or other risks.

Actually, in the summer of 2017, in some ways, a client competing with Bitcoin Core, Bitcoin UASF, overthrew Bitcoin Core and deliberately changed the networks consensus rules. Therefore, concluding that Bitcoin Core is all powerful, is the wrong lesson to learn from the blocksize war.

BitMEX Research is launching a new client to compete with Bitcoin Core (For illustrative purposes only)

Today BitMEX Research is announcing a new client to compete with Bitcoin Core, Bitcoin BitMEX Research. Since it is a software fork of Bitcoin Core, it carries none of the risks of not being bug for bug compatible, like Satoshi was concerned about. The BitMEX Research client also doesn’t change Bitcoin’s consensus rules, so the concerns about contentious chainsplits do not apply. Therefore, if the Bitcoin Core repository gets hijacked or deleted, the codebase can still improve using the Bitcoin BitMEX Research client or any other set of clients.

Conclusion

Following the resolution of the blocksize war, there is too much emphasis on the power of the Bitcoin Core software repository. Common questions now are “Who controls the repository?”, “What if they delete the Bitcoin Core GitHub?”. In our view, these questions may illustrate one is missing the point of Bitcoin.

People tend to look for somebody who is in control of Bitcoin’s protocol rules. Prior to and during the blocksize war, many thought it was miners, large businesses or Gavin Andresen. One of the unexpected negative consequences of that war is that many seem to have switched their opinions to believing Bitcoin Core is incharge, an equally flawed view. The truth is, as hard as it is to appreciate, end users are ultimately in charge of Bitcoin.

Of course this could be unrealistic, in reality, ASIC manufacturers, large mining farms, developers, large custodians, large exchanges and even an individual software repository are highly influential. We may be idealistic in saying that users are ultimately in control. However, isn’t that what “user controlled money” means? If one doesn’t think users control Bitcoin, what exactly is Bitcoin for anyway?