Removing checkpoints in Bitcoin Core v30

The discussion initiated by Eric centers around the evolution and implications of mechanisms like "Assumed Valid Blocks" within Bitcoin Core, specifically addressing their role in optimizing the Initial Block Download (IBD) process. This feature, which was deployed starting with Bitcoin Core version 0.14, allows for the skipping of signature validation for older blocks, thereby potentially speeding up the IBD. The reference to assumed valid blocks harks back to the functionality introduced in Bitcoin 0.5.0, where checkpoints were used to expedite IBD by foregoing the verification of signatures for blocks preceding the most recent checkpoint, as detailed in a Bitcoin Core release note.

Eric clarifies that his concern is not with the addition of new performance improvement mechanisms per se but with the removal of existing ones like checkpoints, suggesting that such removals could degrade performance rather than enhance it. He argues that the rationale behind introducing such features should be scrutinized based on their consequences rather than their original intent. Moreover, he points out that current practices, including "assume valid" and "assume UTXO," aim to mitigate validation efforts to improve IBD times, highlighting a community perception that these mechanisms have "solved" the IBD problem. However, Eric challenges this view by presenting his own findings from syncing operations, indicating that the major cost driver in bitcoind architecture is not signature validation but rather the accumulation of unspent outputs.

Through his experiments, Eric demonstrates that the difference in sync times with and without checkpoints is significant but argues that the focus should be on the overall necessity of such mechanisms given the minimal actual time saved in certain contexts. He shares insights from syncing libbitcoin both with and without checkpoints, noting substantial differences in completion times but also pointing out that the efficiency gain diminishes at scale. Furthermore, Eric discusses the utility of milestones—a feature provided to facilitate rapid node resynchronization from the network by specifying a previously validated milestone—emphasizing its value not as a replacement for validation but as an enhancement for user experience.

Concluding his message, Eric expresses skepticism about the motives behind making nodes appear usable before their chains are fully validated and questions the complexity and security model that parallels the "assume valid" approach without offering clear benefits. He firmly states his stance against removing checkpoints through hard forking, asserting that there are legitimate reasons to maintain them. Eric's contributions to the discussion are anchored in practical observations and a nuanced understanding of Bitcoin's technical architecture, aiming to provoke a reconsideration of current and future strategies for optimizing blockchain performance.