A decisive opening battle has been won by the defenders of Bitcoin Cash in Craig Wright's war to hostile takeover the chain. The chain is now permanently split despite Craig's repeated declarations that "There will be no split!" and now SV supporters are crying foul because the Bitcoin Cash developers have added a checkpoint into the code to prevent Craig from wiping out a day's worth of blocks, causing people to lose millions of dollars, and undoing the chain split. In this article I will thoroughly explain what checkpoints are and why BSV supporters are wrong, yet again, about how the protocol works.
A checkpoint is a line added to the code that prevents the software from reorganizing the blockchain below the checkpointed block. In the event that an attacker (such as Craig Wright) were to try to 51% attack and wipe out all blocks and transactions that happened on Bitcoin Cash over the past day, the software will not let him do it.
BSV supporters are claiming that checkpoints are a violation of the Bitcoin protocol and thus make the ABC side of the chain somehow "not Bitcoin" or "opposed to Satoshi's design". The fact of the matter is checkpoints have been part of the Bitcoin codebase since 2010 WHEN SATOSHI ADDED THEM! Here's what he wrote about it:
The checkpoints also exist in the Bitcoin Core codebase though the Core developers have stopped adding new ones. Thus since at least 2010 no implementation of Bitcoin has allowed unlimited length reorgs back to the genesis block. If BSV supporters want to claim that being able to reorg back to the genesis block is a requirement for something to be "bitcoin", well then I guess nobody has been using Bitcoin all this time.
Checkpoints do not materially change the security properties of the software. All Bitcoin full node implementations are shipped with the genesis block hardcoded into the software. If, by chance, the developers hardcoded the wrong genesis block you node could sync onto an invalid chain and thus you could be tricked into accepting fake bitcoins as payment. If you want be sure that you bootstrapped onto the correct chain you have two choices: 1) Download the source code. Manually verify the genesis block against a known good source*. Then manually compile the software. 2) Trust that the developers hardcoded the correct genesis block. * Finding a known good copy of the genesis block is not as easy as it sounds as you need to make sure the source you're downloading it from is trust worthy (and can you really be sure?) and you have to make sure you aren't man-in-the-middle-attacked as you do so. But those are your two options. A checkpoint could be thought of as simply rolling the genesis block forward. As someone who wants to make sure they bootstrapped onto the correct chain your options are still: 1) Download the source code. Manually verify the checkpoint block against a known good source*. Then manually compile the software. 2) Trust that the developers hardcoded the correct checkpoint. This is nearly identical security. So, no, checkpointing after the fork does not make Bitcoin Cash "centralized".
The downside to checkpointing is introduces a non-zero risk of consensus failure. Imagine for instance that new software is released that checkpoints a block a week ago. Some nodes on the network upgrade to the new software and other nodes do not. If a reorg were to happen that would otherwise wipe out over a weeks worth of blocks, the upgraded nodes would reject the reorg but the non-upgraded nodes would not. Essentially nodes will have fallen out of consensus with each other. The Bitcoin Core developers have stopped adding checkpoints for this reason. If a long reorg were to happen (say weeks or months) their software would technically continue to function as written and everyone on the network would reorg on to the new chain. But while the software would continue to function technically, it obviously would not be functioning economically. A deep reorg like that would be catastrophic for a system that is supposed to be sound money. If that ever happened, consensus failure is the least of your worries as the value of the chain would likely crash close to zero. So checkpoints are are tradeoff between the risk of a catastrophic reorg and consensus failure. In that instance I'm personally more likely to come down on the side of consensus failure because at least that doesn't destroy the whole system and a consensus failure can possibly be rectified simply by telling people with old software to update.
When the fork happened Craig and Calvin were mining BSV with about 3.5 exahashes. As of now they are mining with around 5 exahashes. Where did this extra 1.5 exahash come from and where was it when the chain split started? The most likely explanation is they were trying to 51% attack Bitcoin Cash by mining a hidden chain and then had to abandon the hidden chain once they learned of the checkpoint. But this is sheer incompetence! Bitcoin Cash has checkpointed after each of it's three previous hardforks. If they had even passing familiarly with the development practices of the network they are trying to take over or the software that they are now trying to manage, they would have known this! Here are the checkpoints in the code for the three previous hardforks:
Finally, I stand firmly by my belief that the vast majority (if not all) of the loud voices on the BSV side of the debate have virtually no technical understanding whatsoever. That they would all of a sudden be shocked and offended by a practice that has been going on since 2010 when Satoshi started it shows you that they have no idea how the protocol works, how the software works, and do not have anywhere near the depth of knowledge of these subjects that the Bitcoin Cash side has. Yet they desire to take over and run Bitcoin. You decide who's on the right side of this one.