Bitcoin Cash ABC adds a controversial post-fork ‘checkpoint’

[dragononcrypto]

Bitcoin Cash ABC adds a controversial ‘checkpoint’: Is it centralized?

• On November 15th, a checkpoint update was made to the Bitcoin Cash ABC client
  
• The checkpoint is a line of code that helps protect against block reorganization attacks, an attack where a separate chain is mined in “secret” with greater hash-rate support until it has greater accumulated proof of work

On November 15th, an update was made to the Bitcoin-ABC client, merged by Amaury Séchet (deadalnix), the lead developer of the ABC client.¹ It was officially released on November 16th in version 0.18.4 and ignited a lot of controversy in the community for the inclusion of one feature: a “checkpoint” that was added.

The checkpoint is a line of code that helps protect against block reorganization attacks, an attack where a separate chain is mined in “secret” with greater hash-rate support until it has greater accumulated proof of work. This attack leads to blockchains potentially being “reorganized” where transactions can be delayed, unreliable, or even reversed. In the past year, public blockchains like Bitcoin Gold and ZenCash have suffered from these attacks.

Social media outrage from various crypto communities has primarily taken on a few forms, that (1) Bitcoin-ABC is centralized because of the way the checkpoint has been added (2) that Bitcoin-ABC isn’t adhering to “Satoshi’s original vision.” (a criticism primarily hurled by advocates of the SV camp) (3) and that the location of the checkpoint is problematic, given it is so close to the tip of the blockchain.

Bitcoin-ABC supporters quickly noted that the dominant Bitcoin client, Bitcoin Core, itself has checkpoints built into it, starting from Satoshi’s 0.3.2 release in 2010 (h/t Daniel Dickey and Matt Odell’s discussion). When releasing this, Satoshi noted:

I’ll probably put a checkpoint in each version from now on. Once the software has settled what the widely accepted block chain is, there’s no point in leaving open the unwanted non-zero possibility of revision months later.

Gregory Maxwell, former Blockstream CTO, clarified in a 2013 thread on bitcointalk that these checkpoints serve an additional purpose: to prevent a DOS attack during initial node sync:

Most of their usefulness is that they prevent a dos attacker from filling up bitcoin node’s disk space with long runs of low difficulty blocks forked off low in the chain.

e.g. you start off with difficulty 1 blocks at block 0, now mine-able by the millions by a single asic— _MAYBE_ a chain that starts off that way could eventually turn out to be the longest so absent the checkpoints a node would happily follow an endlessly long chain of them.

In a 2014 pull request to Bitcoin Core, Peter Todd clarified his stance on creating checkpoints going forward, given the conflict between checkpoints and Proof of Work operating as Bitcoin’s security model:

Checkpoints only exist to solve a DoS attack during initial sync. The previous checkpoint has a difficulty more than high enough to make that DoS attack extremely expensive to pull off, and it’s a continual source of confusion as to the actual security model of Bitcoin.

It’s about time we stop updating them every release.

Of the arguments criticizing this checkpoint, the weakest seems to be that it’s anti-Satoshi, as the Bitcoin Cash SV client (where the codebase was forked from Bitcoin Core) includes the original checkpoints Core includes, unchanged. However, the way older checkpoints were added are in stark contrast to this one. Older checkpoints were added to much older blocks, deep in the chain, where this checkpoint was added very close to the tip of the blockchain, surreptitiously protecting the ABC client against the threat of re-org attack by Craig Wright.

The Bitcoin Core client has not added checkpoints to the code since 2014, though any other client implementation is free to add checkpoints as they see fit (or omit them altogether).

Bryce Weiner, an alt-coin developer and protocol engineer makes the case in a Twitter thread for why checkpoints are necessary for non-economic nodes here:

Reality: two different implementations can have two different sets of checkpoints and still reach unified consensus which is approved by miners who honor the checkpoints. Checkpoints can even be commented out and not impact operation.

Checkpoints are for the benefit of non-mining nodes which rely on block ordering to remain consistent after a specific depth. It is a *courtesy* extended to those who use the network because this technology is insane and anything can go wrong at any time, least of all an attack.

While checkpoints seem like a necessary protection, given the looming threat of attack by Bitcoin Cash SV, the competing Bitcoin Cash factions are left dealing with their own unique identity crises. The ABC faction is currently rationalizing a centralized decision to include a checkpoint very high up in the blockchain and the smaller SV faction is going through their own cognitive dissonance after ABC has a commanding lead in hash-rate (they preached for months that the side with more hash-rate is the winner).

Despite all the controversy, this client has very little adoption by users and businesses. Of the approximately 2000 Bitcoin Cash full nodes currently running, only 52 nodes (~2.3%) have upgraded to the offending client. The market seems un-phased by this drama in what is perceived as a value-destructive fork.

¹Here, “client” refers to software that specifies the rule-set of a public blockchain network. In the case of Bitcoin, “Bitcoin Core” is the dominant client runs, though there are other clients, including bitcoind, libbitcoin, etc. Similarly, Ethereum has multiple software clients which are run by users and businesses, including the dominant Parity and geth clients (both independently maintained). Bitcoin Cash has many different clients, including Bitcoin SV, ABC, and BUCash. 

https://www.theblockcrypto.com/2018/11/16/bitcoin-cash-abc-adds-a-controversial-checkpoint-is-it-centralized/