Removing checkpoints in Bitcoin Core v30

Checkpoints, initially implemented to safeguard against Denial of Service (DoS) attacks, have become a focal point due to their perceived potential to enhance performance. This has raised concerns over the possibility that their misuse for performance improvements could prompt the development of alternative Bitcoin Core or Libbitcoin versions exploiting "honest" checkpoints alongside a UTXO snapshot for accelerated performance. An experiment conducted on an M4 MacBook to evaluate the impact of checkpoints on Initial Block Download (IBD) times revealed that the difference in time with and without checkpoints up to block 295,000 was minimal, suggesting that the early blocks constituting only 3% of all transactions do not significantly benefit from checkpointing in terms of signature verification times. Moreover, it was argued that loading a UTXO snapshot at checkpoint height might offer a modest speedup, but this would only marginally improve efficiency.

The conversation also delved into the -assumevalid feature as an alternative to checkpoints, suggesting its replacement with a combination of AssumeUTXO and SwiftSync to allow more efficient background validation while maintaining full validation capabilities. This proposal aims to boost blockchain performance without overly depending on checkpoints or compromising security against DoS attacks. The upcoming v30 release of Bitcoin Core will see the removal of checkpoints and all related support code, based on the assessment that these measures have become redundant following the introduction of headers pre-sync functionality in v24, which effectively counteracts low proof-of-work header spam attacks. The consensus among developers suggests that new checkpoints are unnecessary for adequate security against such threats. The dialogue also recognized the potential for network splits due to extremely large reorganizations, though such events are considered highly improbable. Despite the humorous attribution of these scenarios to aliens or the NSA, they underline a significant vulnerability in network resilience. The conversation acknowledges the existential risks posed by such catastrophic events to Bitcoin's value and utility, proposing a Bitcoin Improvement Proposal (BIP) to establish protocols for restoring network consistency and recommending the permanent activation of certain soft fork rules from the genesis block in the absence of the last checkpoint header. This proactive approach reflects a commitment to preserving Bitcoin's integrity against theoretical threats to its continuity and stability. Further details and technical rationale behind these decisions can be found through references to Bitcoin Core Pull Request and Headers Pre-Sync Functionality.