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:
(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:
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. |
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?