Bitcoin is a protocol that allows for the secure and irreversible exchange of units of value. This protocol is essentially a set of rules that network participants must adhere to in order to successfully achieve its intended purpose. 

These rules are maintained through a set of economic incentives that ensure nodes acting honestly in theirs and the networks self-interest will always profit most.

The evolution of Bitcoin’s software

As it is an evolving project where the original client (the end-user software) release was little more than an alpha version, there are occasionally instances where changes must be made to the Bitcoin client run by the nodes on the network so that bugs may be fixed, optimisations can be implemented, and additional security measures introduced when necessary. 

These changes to the node client inevitably involve the dissemination of a newer version and because of the internal mechanisms for Nakamoto consensus, a majority of the nodes must accept the newer version or else risk finding themselves on a minority chain tip. 

‘Upgrade Bitcoin, but…’

While this process was inevitable, the creator of Bitcoin stated that though these upgrades may be introduced the core design of the protocol was set in stone from the moment Bitcoin was released to the world. 

Let’s compare the concept to the Internet Protocol we’re utilising for this website:

Version 4 of the Internet Protocol (IPv4) was first used in production in 1982. Since that time there have been many tweaks and extensions to enhance the performance and security. Despite these changes, the core design hasn’t changed in those 40 years. 

This fact has allowed the development of the myriad of services that rely upon the IPv4 protocol as part of their networking and software stacks. 

As the Economist George Gilder states, in order to generate a high degree of entropy in the provision of services and applications, a low entropy carrier is required. 

If the carrier is high entropy, in that it is always changing, then it’s impossible for a rich and sophisticated technological culture to develop. Instead, developers will constantly be tasked with re-factoring their software and networking arrangements to meet the consistent changes being introduced. 

Only when the protocol stays set in stone as is the case with IPv4 can we create such a vibrant scene. 

That’s not to say that IPv4 is perfect and will never change, since as we can see there has been a gradual adoption and migration of Internet players toward IPv6 which will confer numerous advantages. 

Bitcoin’s protocol get hijacked

In the case of the Bitcoin protocol, however, this natural process of introducing improvements to security and performance was co-opted following a coup on the repository which distributed the Bitcoin node client codebase. 

Following the coup, this mechanism for introducing changes was co-opted such that it became used as a vehicle for farcically conducting ‘distributed democracy’ which would start to introduce protocol changes based on ideology rather than practicality.

From 2013 to 2017 the Bitcoin protocol underwent significant modifications which completely changed the economic incentives that are written into the rules and are leveraged to provide the core functionality of the protocol. 

‘Replace by Fee’ incentivises a small block mentality

The first such change was ‘Replace by Fee’ (RBF). This allowed a user to re-broadcast a transaction with a higher fee that would invalidate an earlier transaction of the same funds. You would make use of this mechanism if your earlier transaction was taking too long to be processed because of a backlog in transaction processing with small blocks. 

There was no evidence to support the introduction of this change. Rather, it sought to create a whole new economic environment which could be gamed by nodes as it incentivised them to maintain a smaller block size as it would create a market pressure which would drive the fees up when block space was scarce. 

Following this there were other changes introduced along the way and many builders consistently expressed their frustrations at having to build their application architecture upon a foundation of shifting sands rather than a set in stone protocol.

Breaking Bitcoin’s chain of digital signatures to incentivise alternative solutions

In 2017 another radical protocol change was promoted through a Sybil attack on this pseudo ‘distributed democracy’ whereby a modification was introduced to the Bitcoin protocol that entirely changed the way the digital signature scheme was constructed, evaluated and enforced by the network nodes. 

The Bitcoin white paper defines an electronic coin as a chain of digital signatures. The protocol change, an introduction of Segregated Witnesses (SegWit), would break that chain of digital signatures, making it unacceptable to those who wished for Bitcoin to maintain its core design in perpetuity and relied upon an intact signature scheme to achieve the whole host of functionality that Bitcoin could offer natively. 

SegWit breaks Bitcoin Core (BTC) and Bitcoin is reborn as Bitcoin Cash (BCH)

And so it was that from August 2017 a group of miners with a majority of the hash rate forked the Bitcoin protocol via the introduction of a new version of the node client and ran with it until this current day under the exchange ticker of BTC.

The true version of the protocol without SegWit was maintained under the identity of Bitcoin Cash with the exchange ticker BCH. 

There were several groups working upon the node client for Bitcoin Cash. Unfortunately, most of these groups were driven by ideology rather than empiricism. A faction emerged that sought, once again, to introduce protocol changes which would restrict the functionality of the protocol in the name of scalability and privacy. 

Bitcoin SV takes over the Bitcoin baton

Thus, it again came to pass, that in November 2018, when a group of developers sought to introduce canonical rather than chronological transaction ordering and a roadmap of protocol changes, the network forked a second time into two different implementations of the Bitcoin rules set.

Once again, exchanges colluded with players in industry to award the BCH exchange ticker to the deviated protocol. The development group that sought only to restore the original functionality of the node client to the best of their ability (due to the changes that have been introduced), had to assume a new identity once again as Bitcoin Satoshi Vision.

Three Bitcoin node implementations, or a different game altogether?

And then there were three Bitcoin node implementations: Bitcoin Core (BTC), Bitcoin Cash (BCH) and Bitcoin Satoshi Vision (BSV).

Some may say this has led to a reality in which there are three implementations of the Bitcoin protocol. And yet, if you are playing a game of chess and the pieces which move around the board are changed from conventional chess pieces to red and yellow discs, then perhaps it’s more accurate to say you are now playing checkers. Similarly, if, on a board that still has the chess pieces, white sought to introduce a new rule mid-game where they get two turns in a row, is it accurate to say they are still playing chess despite using the same pieces?

BTC’s modus operandi

BTC is playing an entirely different game altogether where their intention is to use the blockchain and the Bitcoin protocol as little as possible, so they can introduce exorbitant fees and force everyone to use other (secondary) networks for moving around the lower amounts which are prohibitively expensive to transact on the main chain.

BCH’s modus operandi

Since its birth, Bitcoin Cash has itself forked into various other implementations via additional protocol changes. Its canonical rather than chronological transaction ordering opened it up to double moves within the Bitcoin game, and thus it had to introduce a concept of checkpoints in the ledger (which were provided to the client by a centralised entity) in turn violating Nakamoto consensus. 

BSV’s modus operandi

Bitcoin SV is still chess. Unbounded block sizes enabling the full functionality of the rich scripting language and a set in stone protocol will ensure builders have a solid foundation to base their applications for many, many years to come.

Todd Price
Price