The great ‘Hash War’ of 2018 in Bitcoin Cash went off with a whimper, not a bang. “There will be no split” they said, “We will bankrupt you!” they said, “Satoshis shotgun will go bang” they said… Well, was that all mate?
A little bit underwhelming is truly being kind. What was promised to be a spectacular showing of chaos and fireworks, a hash war for BCH supremacy waged by no other than the ‘maniacal’ Craig Wright and Bitcoin SV, was seemingly won (and lost) within hours of the hardfork taking place.
As the 15th of November drew ever closer bringing with it the activation of new consensus rules, Craig Wright’s army demonstrated their collective hash power by becoming the majority miner of BCH with a significant margin several times. Bitcoin ABC, who were clearly deeply terrified of the ever impending threat of the hashing boogie man, a possible secret chain being mined by camp Craig and CoinGeek, was in the 11th hour able to issue a ‘temporary’ band-aid solution.
The medicine? Bitcoin ABC 18.4 – A patch to support rolling checkpoints was created. This patch was then issued to all major exchanges within 8 hours of the rollover to the new consensus rules. Some exchanges went along against their own better judgement, and some perhaps their own will it seems. I guess money and power talks in the magic world of internet money.
Rolling Checkpoints are a consensus rule change that essentially stops the current blockchain being reorganised past a certain block height, a 10 block default in this case, ‘protecting’ the chain from deep reorganisations. It is worth noting that this precaution introduces many of its own issues.
On the topic of checkpoints: The following is a discussion where Bitcoin Unlimited’s Chief Scientist Peter Rizun mentions that rolling checkpoints was an unfavourable countermeasure, and perhaps a terrible idea entirely.
16th November, The ABC 18.4 patch for ABC that enacted a 10 block checkpoint was rushed out to GitHub within hours, meaning the hash war was won with silent keystrokes just moments after it began. The SV dragon was slain, Craig is in essence defeated. The medicine inoculated the ABC chain from any deep reorganisation attempts by Bitcoin SV.
21st November, Four days later ABC released version 18.5. The rush to introduce checkpoints introduced some undesirable results, and a new rush had ensued to clean up the mess, demonstrating true kid gloves by the ABC team. Rushing out patch after patch is only kicking the can down the road. All of this work was performed with little oversight and little time for peer review or consensus before implementation.
Checkpointing is only a band-aid solution that introduces exploitable vulnerabilities to the network. Or as Andreas M. Antonopoulos so aptly put it, “10 ft walls only serve to increase production of 11ft ladders”
A checkpoint system can further create the risk of chain splits, sometimes deep reorganisation is a feature, not a bug. What happens in the event of a massive network partition? What if France goes dark for a day? What if all of Europe goes dark for a week? A reorg of this scale would be somewhat painful, but it’s better than the alternative catastrophic set of chain splits.
Eric Wall demonstrates how this could be exploited for a relatively small sum, a cost that has vastly decreased as the hashing rate is now almost ¼ of the relative hashing at time of posting:
When any production code is rushed the obvious side effect is bugs and technical debt. This is due to the lack of planning and forethought put into code, its structure, and the way it interacts with the current legacy architecture. It might function now, but it may also introduce issues that aren’t entirely surface deep.
The bitter truth is – all good code should always go through thorough peer review that only time and many eyeballs can afford, and it still can go pear-shaped!
When sloppy code is allowed to be rushed into a live production implementation of digital money, a dangerous precedent is set! The technical debt from this war will most likely be haunting the ABC implementation for some time to come. The 6-month production schedule for consensus changing hardforks for Bitcoin Cash was already borderline (if not entirely) grossly negligent.
Precedents set by ABC have shown flagrant disregard for safety and users of the ABC chain, and the entirety of users money on a live production chain. Perhaps they can get away with it now with a small user base, but this clearly demonstrates the regard in which they hold users funds. Funds safu for now, but later? Who knows…
The major casualties of the war have been the chequebooks of the armies and the decentralisation of the network. A large player leaving the mining ecosystem drastically reduces security and competition. This has also further driven the mining reserves built up by each to increase, centralising the monetary supply. In this market wearing heavy reserves is financial kryptonite and may drive an increased need to lighten heavy stockpiles, keeping the price further deflated.
All things relative, the hash war on the surface was won seemingly by Bitmain and ABC, but only by throwing out the game board entirely and introducing centralised checkpointing. ABC’s first move was to inflict self-damage, in essence, by conceding the hash war to win the name war, a move that demonstrated their willingness to sacrifice on design principles to win an entirely pointless war. More on that soon.
Implementing checkpoints compromises and perverts the integral nature of Nakamoto consensus, centralises the network to Bitmain’s version of history, introduces localised exploits, and is essentially another small erosion of the decentralised nature of the bitcoin protocol. Yes, Satoshi did implement checkpoints in early versions of Bitcoin code, but once realised these could be exploited they were soon discarded as a method to secure the chain, and they were never used in close intervals.
Yes, that’s right folks, this all could have all been avoided. In August, Bitcoin Cash developers from SV, ABC, and Bitcoin unlimited alike voted unanimously in favour of delaying the addition of CTOR for further research. A decision to honour this vote may likely have led to a cease-fire and/or possible resolution. This war was nothing but one big pissing contest between billionaires that could have been settled reasonably months ago by merely delaying CTOR and meeting in the middle.
Canonical Transaction Ordering(CTOR) is a change to the way the protocol handles the ordering of transactions, relinquishing the natural order of transactions as received by nodes and deeming it as wasteful. This removes a lot of ‘excessive’ ordering data and enables much greater block compression by radically reducing graphene blocksize, after we start reaching gigablocks. The contention is there is very little data and research into CTOR, it is not needed for years, and its addition has more or less been rushed and forced into production without consensus. This goes against the very nature of Bitcoin.
So the question is if ABC introduced a feature themselves that introduces attack surfaces, and can cause permanent chain splits, and they never really had consensus for CTOR in the first place, did they really win?
Bitcoin is secured via proof-of-work, and this security is balanced with a very delicate incentive model based on evolutionary game theory. This economic incentive-based security model is designed to ultimately incentivise honest actors performing honest work inside the network, honest work builds on honest work, hardening its security over time. This model demonstrably does not allow for a minority chain with the same competing proof-of-work algorithm to survive long-term.
Why is this so? Because this crux of this concept relies on the pool of honest workers available growing in relation to the value available in the network. Therefore as the value of the network rises, so does the pool of honest workers competing to build upon the established honest work. If there is always a much greater pool of actors creating the exact same proof of work algorithm on another competing network, the balance of difficulty to introduce a majority of dishonest actors into the minority system is always skewed entirely in favour of the majority network.
This may not seem economically rational to attack, but when war games are afoot, economic rationality goes out the window. The game for SHA-256 dominance is a zero-sum game. Even if this attack by the marauding majority is only designed for disruption, the result is the same. Murphy’s law predicts that this attack will inevitably will come to pass.
A minority network will ultimately become the target of one of (or all of) the actors in majority chains. The difference in hashrate between BTC and BCH is currently over 3000%, making the threat of a annihilation ever looming, and the need to fork away from SHA-256 demonstrably necessary for the future survival of the project.
While the resources exist to reorg BCH at will, the battle will continue ad infinitum. Yes, forever. Both sides will have to face the contention that being minority chains they are forever vulnerable against attack by the larger tribe. Until there is a proof-of-work hardfork by either network, reorgs will be possible and there is a non-trivial chance they will come to pass.
For now, the war it seems has taken a new direction in favour of statists. A lawsuit has been filed inside the United States taking aim at Bitmain & the Bitcoin ABC developers. The suit claims among other things of a connection to Bitcoin Cash and a Chinese government plot to take control of the network. Whether or not this lawsuit will eventuate into anything… Well, your guess is as good as mine. The ultimate victor is yet to be decided, but all I see in the battle of the Bitcoin Cash hash wars are losers.