Explaining the Background Behind the Bitcoin Cash Hard Fork (2018)

So What’s Going On?

Two Simple Words:

Hard Fork

For those that are unaware, there’s a major debate in the Bitcoin Cash community currently that is expected to result in a complete chain split (various individuals within the Bitcoin Cash community have stated their intentions to create such).

The purpose of this article will be to dissect what’s going on, why it’s going on, and assess how it unfolded by recounting (most) details from the inception of the issue to current time.

Given the depth of this situation, this singular article should not be consulted as the sole authority on the protocol dispute, because there are several additional dimensions, code submissions, and philosophical arguments that must be reviewed in detail before one will be able to acquire a true understanding of the full breadth of the situation.

However, reading this piece is a good start.

So, let’s briefly discuss the three different versions of Bitcoin Cash [software] that exist currently. 

Three Separate Implementation Proposals

The three distinct, separate implementation proposals are as follows:

  1. Bitcoin ABC’s Proposal
  2. Bitcoin Unlimited Proposal
  3. Bitcoin SV Proposal

We’re going to cover each one of them comprehensively, below.

Bitcoin ABC Proposal 

We’re going to start here, because it is this proposal that is the root of the dissent on the protocol and Bitcoin ABC is largely seen as the leading software implementation of the protocol. Traditionally, Bitcoin ABC has been considered the analogical equivalent of Bitcoin Core. 

Nature of the Bitcoin ABC Proposal 

In a press release distributed in August of 2018 on the Bitcoin ABC website, the team announced that they had released a new software implementation (Bitcoin ABC 0.18.0) of the Bitcoin Cash protocol that includes, “implementation and activation of the Bitcoin Cash network upgrade that will take effect on Nov 15, 2018.”

In the same press release, the Bitcoin ABC team listed their proposed changes, which you can see in the screenshot provided below:

Source: https://www.bitcoinabc.org/2018-08-20-announcing-bitcoin-abc-0-18-0/


There are two major things that you need to note at this point:

  1. The hard fork is slated for November 15th, 2018. 
  2. The primary source of angst (and disagreement resulting in the contentious hard fork) can be found in the statement, “The introduction of canonical transaction ordering.”

Let’s focus on #2, shall we?

What is Canonical Transaction Ordering? [CTOR]

We’re going to try to explain this concept in the most ELI5, non-technical way possible.

The general nature of the proposal was covered recently in research published by members of the Bitcoin ABC team, who are as follows:

Johannes Vermorel (Loka), Amaury Sechet (Bitcoin ABC), Shammah Chancellor (Bitcoin ABC), Tomas van der Wansem (Bitcrust)

In the piece, they state that the current Bitcoin Cash protocol uses TTOR, which stands for ‘Topological Transaction Ordering’.

The way that the team defines this in the paper is fairly straightforward.

Within the piece, they provide the following excerpt on TTOR to explain it:

“The consensus rules of Bitcoin inherited from the original Satoshi client requires that the list of transactions listed within a block be topologically sorted from the perspective of outpoints consumptions, i.e. if a transaction B depends on a transaction A to be valid, then the transaction B must appear after the transaction A within the block. Thus, the consensus rule enforces a partial ordering on the transactions.”

They define their proposal when they state:

“We propose the CTOR as an alternative where transactions, within a blockc, are ordered by increasing transaction identifier. We argue that the CTOR is highly desirable for a series of reasons notably:

Also below, are the major bullet point justifications provided by the team as justification for what makes CTOR superior to TTOR. 

  1. Block emission is more efficient

  2. Block propagation is more efficient

  3. Software implementations are simplified

  4. Proofs of transaction are simplified

  5. Opt-in locality between participants becomes possible

  6. Potential attack vectors are mitigated

The remainder of the paper goes on to explain the pirmary theory behind why the team believes that TTOR should be removed with CTOR being implemeneted in its stead.

We’re not going to dive too deeply into the theory behind CTOR or outline the pros and cons because that would be a bit off-topic (Remember: We’re trying to ascertain here why there is a hard fork; not debate the merits of each proposal).

What has been written thus far characterizes the crux of this portion of the ABC proposal, which has been one of the major topics of debate among various factions of the Bitcoin Cash protocol.

RECAP: Remember, apart from CTOR, there are three other partitions ofthe Bitcoin ABC proposal that they are looking to implement on November 15th, which are:

Minimum Transaction Size of 100 bytes


Push-only mandate for scriptsig


There has (and continues to be) been significant debate in dissent within the protocol regarding the effectiveness/security of the potential op_code additions, with OP_CHECKDATASIGVERIFY (CDSV) being another focal point of dissent for Craig Wright, in specific.


Additional Recap: Making Sure You [The Reader] Are Currently Up to Speed

Before we continue on to the next portion of this article, let’s make sure that everyone is caught up to speed on what’s going on:

  1. Bitcoin ABC released new Bitcoin Cash protocol software back in August and announced a planned hard fork scheduled for November 15th, 2018. 
  2. In that planned hard fork, there are four major upgrades/changes to the protocol. 
  3. Various different factions within the Bitcoin Cash community (with varying levels of influence + various roles in the $BCH ecosystem) have voiced dissent for a variety of purported grievances. 
  4. As a result, it is almost guaranteed that the planned hard fork on November 15th, 2018, will be a contentious one.

Intro Craig Wright’s Dissent

Craig Wright, known as ‘@ProfFaustus’ on Twitter, has been very vocal about his disagreement with the ABC team’s proposals.

For those that do not know, Craig Wright is one of the unofficial figureheads of the Bitcoin Cash protocol. His entry into cryptocurrency was met with significant controversy as the world gained awareness of his existence through the combination of Buzzfeed/Gizmodo research into the whereabouts/identity of Satoshi Nakamoto, the famed pseudonymous developer of Bitcoin whom disappeared in 2015.

Currently, there has been no conclusive proof provided to suggest that Craig Wright is Satoshi Nakamoto by his own admission, and several have questioned his credibility as an academic. However, there exists a faction of supporters that remain convinced that Craig Wright is Satoshi Nakamoto. Regardless of his true identity or affiliation with Bitcoin’s creation or the Satoshi Nakamoto identity, one thing that cannot be denied is his influence on the Bitcoin Cash protocol.

Thus, we are going to cover Craig Wright’s visceral reaction to the ABC proposal that we outlined above.

Craig Wright’s Initial Reaction to the ABC Proposal

Just three short days after the Bitcoin ABC proposal, Craig Wright took to his Twitter account to tweet out the following message:

Dr Craig S Wright on Twitter

OP_CHECKDATASIGVERIFY is not happening. If a certain ABC dev wants to push this, then we will just fund replacement Devs. Trust me. There are others. Miners vote Think we are not serious. Watch the Axe fall. @CalvinAyre @yhaiyang

The message reads:

“ OP_CHECKDATASIGVERIFY is not happening. If a certain ABC dev wants to push this, then we will just fund replacement Devs. Trust me. There are others. Miners vote Think we are not serious. Watch the Axe fall. @CalvinAyre @yhaiyang

In essence, Craig Wright was issuing a public message letting the ABC team know that, if they continued their plans to implement the proposed changes in their original announcement concerning the hard fork, then he (expressed as an ambiguous ‘we’ in the tweet), “will fund replacements”.


Confusion Over the Ominous Threat by Craig Wright

There has been some confusion over Craig Wright’s threat (as well as subsequent statements) because, as many have noted, the premise of his threats are antithetical to the principal of decentralization.

For example, the concept of being able to ‘fund replacement devs’ is discordant with the idea of a decentralized protocol which allows merit-based additions to the code, rather than additions based on prestige (i.e., only accepting the contributions of a developer with a well-established name).

Now, there may be certain individuals that are hired for the purposes of developing code on a protocol, but if they are fired — there should be nothing to stop them from continuing development on the protocol if they so choose (although it would more than likely be pro-bono from that point forward).

Continued Attacks by Craig Wright

On August 30th, Craig Wright continued the ongoing warfare between himself and the Bitcoin ABC team by tweeting:

Dr Craig S Wright on Twitter

ABC use lies and FUD in an attempt to say bitcoin is broken and only they can save it. Not worth even talking with them. Block headers are simple to check. The so called attack scenarios are reminiscent of Core

In the tweet, he states:

“ABC use[sp?] lies and FUD in an attempt to say bitcoin is broken and only they can save it.

Not even worth talking with them.

Block headers are simple to check. The so called attack scenarios are reminiscent of Core”

In the tweet above, its easy to see how Craig Wright’s tone gradually became more belligerent and hostile toward the ABC team. Again, it remains unclear as to what angered Craig Wright to the extent where he felt that ABC’s hard fork proposal stemmed from nefarious motivations or what evidence, if any, he had to corroborate his assertions that the ABC team’s proposals were malevolent at the root. 

Objectively speaking, Wright’s tweet appears to grossly mischaracterize the ABC team by stating that they have merely been insisting ‘bitcoin is broken’, when it seems clear that the team was making a proposal for a potential improvement in the protocol’s functioning.

However, there is an alternate proposal and protocol versioning that has been proposed (and rigorously) endorsed by Craig Wright, himself. 

Inception of Bitcoin SV

Undoubtedly, created as a response to the Bitcoin ABC team proposal, nChain — an organization/business that Craig Wright is a leading executive of, in partnership with CoinGeek (which Calvin Ayre, a billionaire, heads) publicly pledged to support one the launch of the Bitcoin SV protocol implementation just a little over a week after the original Bitcoin ABC announcement.

For that do not know, the SV in the name ‘Bitocin SV’, stands for ‘Satoshi’s Vision’.

This alternate protocol version, which was announced on August 16th, 2018, just 8 days after the original Bitcoin ABC announcement, was released into the public domain on August 16th, 2018.

Briefly Reviewing the Bitcoin SV Proposal Press Release

On the front page, the headline of the press release proclaims:

“Bitcoin SV Full Node Implementation Launched to Fully Restore Original Bitcoin Protocol”

The proposal, written by Jimmy Nguyen the Chief Executive Officer of nChain, states that the new protocol was created at the behest of,

“BCH mining enterprise CoinGeek and other miners, Bitcoin SV is intended to provide a clear BCH implementation choice for miners who support Bitcoin’s original vision, over implementations that seek to make unnecessary changes to the original Bitcoin protocol.”

The press release fails to quantify how one would be able to determine any palpable difference between a ‘necessary’ change and an ‘unnecessary’ one, but it continues on this premise to then state,

“CoinGeek’s announcement made clear that it will not support implementations or projects that make unnecessary changes to the original Bitcoin protocol.”

Then the press release continues on to expand on the opinion of Calvin Ayre (head of CoinGeek and the CoinGeek mining pool on the $BCH protocol).

Primary Advertised Benefit(s) of the SV Protocol

The major selling points of this protocol implementation (per CoinGeek + nChain) are:

  1. Adhering to the ‘original Bitcoin’ vision (hence the name, ‘Satoshi’s Vision’)
  2. Enhanced scalability 

This protocol involves the vertical scaling of the protocol to include block sizes that are 128 MB, rather than the current 32 MB limit.

Launch of Bitcoin SV

Per a paid news release on PR Newswire, it was announced that ‘Bitcoin SV version 0.1’ had went live on October 15th, an entire month before it was scheduled to do so on the Bitcoin protocol.

Bitcoin Unlimited

The third ‘faction’ on the protocol is a software implementation called ‘Bitcoin Unlimited’.

The goal of this third and final implementation is to create a ‘resolution’ between the two competing factions, making the ABC and SV implementations choices that miners of that software implementation may select.

More information about this software implementation can be found here:

BUIP098: (passed) Bitcoin Unlimited’s Strategy for the November 2018 Hard Fork


This article, despite its length, is only a surface-level dive into the dispute that has enveloped the Bitcoin Cash protocol over the past few weeks.

What initially was a non-controversial, impartially received routine update by the ABC team has turned into full-scale warfare between competing factions. As stated from the onset of this article, the goal in this piece was not to present any particular side as the ‘winner’ or ‘loser’, but rather to present an objective view of what the source of disagreement is allegedly over.

However, in subsequent pieces we will begin to dig into the merits of various arguments and proposals and identify some benefits, negatives and other issues that should draw concern from users.

Until next time —

This is a Zerononcense Production




Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.