Editorial 27 August 2018

Eli Afram

Miners will clash, but there will only be one Bitcoin (BCH)

Author’s Update 11/10/2018: When I originally penned this, I inferred an exclusivity of CTOR leading to Pre-consensus. While I still believe that CTOR may help pre-consensus and in turn help Wormhole (depending on implementation), the inference of exclusivity was wrong. It’s important I updated this prior to the fork. I apologise for, and retract such statements.  I have in turn updated the article to reflect this.

Bitcoin Cash is once again making headlines. The biggest headlines in fact, since its day of liberation last year. What many media outlets are calling an upcoming “schism” or “split” in November is in fact a consensus seeking mechanism. This is in fact, an election. Except, unlike a national election for presidency, it is not 1 human = 1 vote. It is 1 CPU = 1 vote. This means, it comes down to hash power. That alone is the consensus seeking mechanism that was built into Bitcoin since day one, and the consensus mechanism that was highlighted in Satoshi’s whitepaper.

What many do not realise is that every time miners choose to run an upgraded piece of software (with different consensus rules), they are actively making a vote change. Usually this happens very seamlessly since most of the small fish, follow the big leads.

Recently some people have been arguing against the whitepaper definition of consensus, stating that it is not exclusively so, and then pointing to Monero, which hardforked, kicking out the majority of its hashpower in its ASIC resistant fork. It’s true that Monero XMR devs changed the rules of the system, and discarded the vast majority of the mining power in doing so. There are few reasons, why this works for Monero, and not Bitcoin. First, Monero is a coin that is centralized to its development team. This means that what gets called Monero is entirely up to the “official” software that Monero devs choose to release. Secondly, if Bitcoin ever tries to change its proof of work (and do something similar), it would kill off every miner in the current eco-system… Miners would not willingly turn suicidal…

But Bitcoin Cash miners are split. On one hand we have ViaBTC and Bitmain who are strongly supporting contentious changes, and on the other hand we have nChain and CoinGeek that are opposing the contentious changes, and also introducing a significant capacity increase.

Let’s re-evaluate how we got here.

Contentious changes being pushed by ABC include “Canonical Transaction Ordering” (CTOR for short) and a later to come ‘pre-consensus’ mechanism yet to be developed. I say the word “contentious” because the lead developer of Bitcoin ABC, Amaury Sechet himself recognised this was a contentious change that would upset many people. In his piece “On markets and pre-consensus”, Amaury concludes:

“The actions I have to take along the way will surely irritate many, but this is too important to not be tackled now.” – Amaury Sechet

He was not wrong. nChain responded in aggressive opposition. CoinGeek issued a statement that they will not support such changes. The culmination of this response has resulted in the birth of yet another Bitcoin client, suitably called “Bitcoin SV” (SV for Satoshi’s Vision) which plans to see functionality of Satoshi’s original intended client resurrected. The client is currently under testing and is planned for initial release in early September.

While we await the release of the client code, what we do know is that they have irreconcilable differences with ABC. It is looking very likely, that we will for the first time in Bitcoin history, see Nakamoto consensus in its full effect, deciding between two factions that wish to take the protocol in different directions.

While many people have been quick to point the finger at nChain and Coingeek for the source of division, it’s important to also recognise that CTOR itself, has been a contentious source of division among many BCH developer groups that oppose it.

Most investors of any cryptocurrency are fine “when things go to plan”. But introduce something that isn’t part of a community’s overall roadmap, and you will face opposition. Rightly or wrongly, this is a typical response. Even new changes that are holistically good without any negatives, they require time for acceptance, scrutiny, testing, and overall confidence.

The issue with CTOR right now is that it is reasonably new idea to much of the community, and many dev groups are calling for more time and data on the subject. Pre-consensus, which is also on the ABC roadmap is perhaps the most glaring reason for Bitcoin SV’s existence. As Amaury rightly points out, it is that that BCH community values 0-Conf payments. Does 0-conf need fixing? Because that is what is being fundamentally changed here. And it will require substantial changes to software across the eco-system.

As for CTOR, if the majority of the community is opposing this change, why are we rushing it for November? Why can’t we have it deployed to a testnet and have it tested with all major parties including Bitcoin Unlimited, CoinGeek, and others, with all existing software for several months, and perhaps gain confidence and acceptance? This is a sticking point.

nChain’s Dr Wright caused commotion when he brought up the fact that CTOR is of a major benefit to Wormhole (Bitmain’s tokenization solution). Wormhole which is a layer 2 technology, Omni Layer fork, doesn’t work with 0-conf. As far as Omni or Wormhole is concerned, BCH 0-confirmation transactions are indeed broken. Transaction ordering is mightily important here. Omni Layer devs have long known the importance of transaction ordering and the requirement for confirmations. This thread on the OmniLayer github, is one of many instances discussing the point.

Omni develper, dexX7 has since responded stating that CTOR does not directly help Omni (or Wormhole).

However, some code changes to Omni or Wormhole could make use of CTOR as could most chainless apps.

It’s also possible that Bitmain may seek to reduce block times at some point– this would have positive affect on Wormhole also, for the very same reasons noted in the above thread. However, it’s importantly fair to address that ABC have not included any such change, nor pushed for anything of this nature in the upcoming November fork.

But both Haipo and Jihan (ViaBTC and Bitmain) have both tweeted in favour of such a change to Bitcoin Cash. Perhaps assessing community reactions (which would be a clever thing to do as first step by all means)..

Certainly the idea of making changes to Bitcoin functionality, in order to satisfy a second layer project, is something that the Bitcoin Cash community is burned and scarred from. The idea may not sit well with some. Then there’s question marks over the dynamics of Wormhole and its effects on on the economic system behind Bitcoin. Notably, Wormhole requires the burning of 1 BCH to mine 100 Wormhole Cash tokens. Try to envisage a scenario where a Wormhole token becomes more valuable than a BCH coin. This would cause a major burn off of BCH coin for Wormhole. Although this risk is extremely unlikely, the consequences could be catastrophic. But if Bitmain and ViaBTC’s intention truly is make Bitcoin work better for Wormhole, then as miners, it is their hashpower given right to attempt and vote on such changes. These are the rules of the game we all signed up to as investors. We presume everyone has done their research and as a bare minimum would have at least covered the whitepaper and understood how the voting mechanism works. Miners choose, and Bitmain has every right to.

Miners will clash, but there will only be one Bitcoin Cash.

By the same token, it is the right of every other miner to choose to vote against or for the change. Coingeek and nChain are resolute in their position, and are moving in to deflect the challenge, and then counter-vote in a 128MB capacity increase. This is how the system works, these are the rules of engagement. That’s the system we invested in.

The community has barely had enough time to digest the idea and notion of CTOR. Perhaps it may have been a better draw card from Bitmain and ABC if they decided to have this out for a year on testnet, and really show the advantages of the change. Instead the push to have this out in November has had the opposite effect, raising alarm bells. The case for Canonical Transaction Ordering in Bitcoin was made in June this year. Interestingly, one of the stated benefits of CTOR is to help Bitcoin “process very large blocks”, yet ABC are reluctant on removing or adjusting the actual cap blocksize in November. The questions and concerns around CTOR then increased when an opposing paper titled “A opinionated critique of the ‘Canonical Transaction Ordering For Bitcoin’ white paper, written by Joannes Vermoreletal.” was published by /u/awemany with key thoughts by Tom Zander.

This also then led Bitcoin Unlimited’s Chief Scientist Dr Peter Rizun to repeatedly call for cool heads to prevail over the rush introduction of CTO.

It is beginning to appear that the intentional stagnation on scaling BTC has had a full pendulum swing of opposite effect on BCH. The dev community seems so exuberant with having the shackles of scalability freed that we’re beginning to over-compensate, and trying to throw in every conceivable function as a development proposal. The “hard fork every six month plan”, although initially put forward with good intentions, is also beginning to back fire, creating a portal for dev groups to introduce feature-creep and potentially leading to undesirable long term side effects from software-bloat and over complication, rather than simple, working design.

When we first forked Bitcoin Cash, it was first and foremost with the intent to scale the blocksize and restore original Bitcoin set out by Satoshi’s vision. The community was in large, united on that front. What leaves the community clearly torn however, are changes that deviate from this direction. This is not to say that things that Satoshi did not think of are bad or negative – No. It is that we have 8 years of evidence that Satoshi’s fundamental design, works. All other features should therefore be evaluated with the most stringent level of scrutiny, testing, and appraisal. Bitcoin was never supposed to be an experiment to incorporate every idea that a developer group had. It was first and foremost meant to be stable, sound money that the world could use. When did we lost sight of that?

If we want large companies, governments, banks, and multi-national entities to invest in the BCH blockchain, we need to show stability. In the early days, Vitalik Buterin actually opted out of building Ethereum on Bitcoin purely because Core devs showed they were willing to tamper with the protocol, proving Bitcoin too volatile of a platform to build on. How big would Bitcoin have been today if Vitalik was able to use the Bitcoin blockchain for smart contracting purposes? Imagine Ethereum’s value added to Bitcoin.

Recently I engaged a number of companies who were looking into blockchain technology. Many of these companies are seeking to develop their own private blockchains. Why private? A compelling reason that was given was control of the protocol. In their view, the lack of control around public blockchains means changes can be implemented which may pose a risk to their data. That ‘risk’ of unstable platform, as is perceived by companies, needs to be eliminated.

Coingeek and nChain are pushing for a lock-down of a protocol. Recent comments of this nature have flared up criticism. Locking down the protocol doesn’t mean that we never make changes to it ever again – that would be counter-productive. It means that we lock down the capacity for change to be limited to functions that may be crucial, or highly opportunistic, and only after significant testing and appraisal can be attained. This also doesn’t mean that development will come to a halt – not at all. The majority of development will move to building an array of applications on top of the blockchain, which are proving crucially valuable. But further, nobody can actually “lock” the protocol. The statement made by nChain refers to their intention that they will vote to keep Bitcoin as consistently stable as possible. Other miners will always be able to also exercise their right and vote for change.

The battle here is over the same BCH blockchain. It is excessively unlikely, that we will get a split coin in November, since both mining factions are fighting over the BCH ticker and existing eco-system. The hashpower is over one chain in true nakamoto consensus. No team, is seeking to split into a different coin.

As painful as it is to watch mining giants that have already given so much to the eco-system at odds, the fact is that this sort of thing is inevitable, and only a matter of time… although almost certainly it won’t be the last time. For some others it’s an exciting opportunity to witness a hash war – something we are yet to see at this scale.

Eli Afram

Note: Tokens on the Bitcoin Core (segwit) Chain are Referred to as BTC coins. Bitcoin Cash (BCH) is today the only Bitcoin implementation that follows Satoshi Nakamoto’s original whitepaper for Peer to Peer Electronic Cash. Bitcoin BCH is the only major public blockchain that maintains the original vision for Bitcoin as fast, frictionless, electronic cash.
Note: Tokens on the Bitcoin Core (segwit) Chain are Referred to as BTC coins. Bitcoin Satoshi Vision (BSV) is today the only Bitcoin implementation that follows Satoshi Nakamoto’s original whitepaper for Peer to Peer Electronic Cash. Bitcoin BSV is the only major public blockchain that maintains the original vision for Bitcoin as fast, frictionless, electronic cash.


Tom Stankewicz

HAHA why even try to report news anymore? CoinGeek is a propaganda outlet for $BCH


1) Am I the only one who finds a certain irony in the HF’ing of BCH?
2) Does BCH even have a white paper that is theirs? Why do they cite BTC’s?
3) If only government could be HF’s as easily as open source software…

IMHO, hard fork as much as is necessary to provide as many options as possible, then let the market decide.


Scott Veronie

Very good read. Thanks.

Grant Grey

1 person = many CPUs = many votes = authoritarianism.


    We do the same thing when we ‘vote with our dollars’ in the marketplace.

    Eli Afram

    1 person can indeed equal many votes. Thats been Bitcoin for 8+ years. Nothing new here…

What's the frequency, Kenneth?

What’s not said here is that nChain and Coingeek are really the same person, Calvin Ayre, listening to one other person Craig S Wright. Think about that as you re-read.


Geez, this is worst than fishmongers haggling against each other at the market: there is now a GLOBAL audience to this BCH argument.
The biggest losers are the supporters of the BCH who now have to dig into the tech details to make sense of each possible outcome.

All in all, the Blockchain tech is still VERY new, and the best way to test its solidity is to throw money at it: if it survives, then it was genuinely worth it from the beginning. 🙂

Add a Comment

latest news

Bitcoin Core’s SegWit still not viable a year after being introduced

Editorial 2 hours ago

Bitcoin Core’s SegWit still not viable a year after being introduced

Now, we’re looking at SegWit and wondering why, over a year after it was going to “rock the crypto world,” it is still floundering, not able to achieve the success its developers anticipated.

Read More
Dan Held almost gets Satoshi’s Vision correct

Editorial 16 January 2019

Dan Held almost gets Satoshi’s Vision correct

Dan Held may be a notable cryptocurrency veteran and a former executive with Blockchain.com, but several recent Twitter posts offering his take on digital currencies and, in particular, the interpretation of the original Satoshi’s Vision miss the mark.

Read More
Under China’s new blockchain laws, Bitmain-ABC’s BCH is in trouble

Editorial 15 January 2019

Under China’s new blockchain laws, Bitmain-ABC’s BCH is in trouble

Under the new regulations, blockchain information service providers are within the purview of the CAC and a range of penalties has been outlined for the violation of the provisions.

Read More