What is the purpose of checkpoints in the blockchain?

Published: 2019-01-15


Q: What do you think about the use of checkpoints?

A couple of weeks ago in November 2018, maintainers and developers of the Bitcoin Cash ABC (BCHABC) branch added a controversial feature, which was a rolling ten block checkpoint that prevents reorganizations of the chain. That means a node can't present a chain that reorganizes above ten blocks. This rolling checkpoint is a feature that was intended to protect BCHABC against a specific type of attack... that uses what is called secret mining. Secret mining is where rival hashing power is mining blocks without broadcasting them to the network. Once it has enough block height and has mined the longest, greatest cumulative difficulty chain, they then broadcast the blocks, which causes a reorganization within the clients of the 'victim' chain. I am using "attack" and "victim" here as computer security terms, not political terms; so please don't read too much into it.

With secret mining, you would have a portion of the hash power mining without broadcasting blocks, for example, until they are a whole ten blocks ahead, and then broadcasting this longer chain all at once. This will force a reorganization of the clients, which will exclude the blocks from the 'victim' / rival chain... mined by the rest of the hash power. This is primarily intended to cause disruption or act as a hostile takeover of the chain. Not quite sure how you want to characterize it, but that is possible within the blockchain logic. Now compare this to how Bitcoin works.

To date, the Bitcoin blockchain does not have a rolling checkpoint. The consensus algorithm allows for a reorganization of any length. The largest we've seen was back in March 2013. There was a glitch in the upgrade between 0.7 and 0.8. which caused an unplanned, unexpected, accidental divergence of the network into two different chains... that diverged for twenty-six blocks at the highest level. One chain was selected, the other one was orphaned, and the main chain reorganized twenty-six blocks. That is the deepest reorganization which has happened.

On an almost daily basis, you will see reorganizations of one block. Every month or so, you see reorganizations of two or three blocks, due to the statistical variance... in the number of blocks that can be mined within a ten-minute period. Blocks are seen by different parts of the network with differing latency. These are normal, expected network forks, where the Nakamoto consensus temporarily forks... into two possible chains, which are being seen by different parts of the network. They soon re-converge when one of them achieves more proof-of-work than the other. The longest chain reorganization we have seen was twenty-six blocks, which was a very unusual event. In any case, there has never been a rolling checkpoint.

There is another type of checkpoint which is hard-coded inside the client software, putting a bottom limit that says, 'Everything below this block height is considered established history... and cannot change,' prohibiting chain reorganizations below that block height. That kind of checkpoint is different. It involves hard-coding a specific hash in the client software, 'This particular block cannot be reorged away.' That was used in the twenty-six block reorg, I believe, but the use of checkpoints significantly reduced since. What do I think about this? Checkpoints are a matter of the relative power of two constituencies in consensus. I have talked about this before. Consensus is a multi-constituency mechanism. Consensus is not just miners or developers. It is not just merchants, exchanges, or wallets. It is five different groups of consensus with overlapping influence and power: miners, developers, exchanges, merchants, and wallets. Miners, developers, and economically important nodes all contribute to emergent consensus... by deciding which rules to follow, how to set the rules, and what software to use.

When you put a change in the algorithm about what can and cannot be reorganized, software with rolling checkpoints, that shifts a bit of power away from miners and towards developers. Developers are changing the way the protocol behaves by preventing certain classes of reorganizations. Hard-coded checkpoints are a more serious and direct shift in power, because developers are essentially... deciding which chain is valid, rather than allowing the proof-of-work consensus algorithm... to make that decision independently via the miners. These types of changes and checkpoints represent a slight shift in power within the consensus mechanism, away from one group and towards another group. But it is really up to you to decide, how serious this change is and whether it is justified. For example, you might think that in the case of a deliberate, secret mining attack, when someone has actually threatened to spend millions of dollars purely to damage the other chain... in a competition between two forks...

Is that a reasonable response to a portion of the miners trying to take more power, for the developers to take more power by changing the rules of reorganization, or to create a bigger shift by setting repeated hard checkpoints to prevent any reorganization? That is a subjective question. Whether you think this is a valid change or not, you can express your role in consensus... as an economic user who runs a validating node to broadcast and receive transactions of value. Nodes with economic power, which generate transaction volume and other economic activity, such as merchants, exchanges, wallets, big companies, whales, etc. They choose what software to run on their nodes. In choosing what software to run, that is their contribution to the emergent consensus. If you see developers making these changes, you can choose to run different software, or you can choose to upgrade to the new software. Either way, you are expressing your consensus vote.


Filed Under: Blockchain