Quick reply: there remained a single identified assault (low-difficulty header spam) that checkpoints considerably protected towards, even when they have been previous. As mining {hardware} continued to grow to be cheaper per hash, that safety turned weaker too, as defined in a latest safety disclosure. Since Bitcoin Core 24.0, that assault is not doable, utilizing an answer (headers presyncing) that doesn’t require forcing a specific chain onto customers (not like checkpoints). As of early 2025, there may be lively dialogue about eradicating checkpoints fully.
Longer reply.
Ever since headers-first synchronization was launched in Bitcoin 0.10, the solely cause checkpoints have been nonetheless helpful is to fight headers spam.
I’ll quote one other reply on the subject of mine:
because the headers-first synchronization launched in Bitcoin Core 0.10.0, blocks are by no means downloaded earlier than their headers are identified and verified to have adequate work (which suggests: sufficient to be inside in the future of the lively chain tip, and greater than the preconfigured minimal chain work). This implies we already need not fear about low-difficulty block spam anymore. The blocks are simply not downloaded until they’re a part of a sequence that is confirmed to be adequate.
But, a weaker drawback remained: a peer might begin giving us (a number of) chains of headers that by no means quantity to something useful. For the reason that headers are despatched in ahead order, there isn’t a solution to know originally how good the outcome will get.
I give this as context, as a result of when discussing safety measures it’s at all times good to remember what issues we try to forestall: checkpoints have been simply there to forestall attackers from filling individuals’s disks and reminiscence with massive quantities of low-difficulty chains that fork off very early on (e.g., simply after the genesis block) and by no means truly attain as a lot work as the actual one, however the software program has no technique of determining that they cannot.
Nevertheless, if one way or the other a sequence existed which truly forked off from proper after genesis, which was legitimate, and had extra work than the chain we think about actual as we speak, the software program ought to settle for it, drastic as it’s. Bitcoin’s safety mannequin depends on proof-of-work, which suggests accepting the most-work legitimate chain, even whether it is maybe not the chain we wish.
I point out this, as a result of individuals generally consider that checkpoints are a safety function that protects towards deep reorgs. I consider that may be a mistake: if deep reorgs occur, a number of the very core assumption underlying proof-of-work are damaged, and we must always think about fixing it. Checkpoints are usually not a repair for this: both they’re put thus far up to now that they haven’t any impact on which chain is accepted (as is the case now), or they’re made regularly at which level it’s changing a computer-system primarily based consensus system with a human one.
So: all checkpoints do is drive a headers-spamming attacker to fork off from the chain in 2014, relatively than in 2009, the place the issue is a lot greater (however nonetheless orders of magnitude decrease than as we speak). This makes the headers-spam assault many instances dearer, however as mining {hardware} has stored creating, as of 2022, the price of the assault had gone all the way down to roughly 1 BTC in mining prices (as defined within the safety disclosure).
Since Bitcoin Core 24.0, a brand new method to headers synchronization is launched: headers pre-syncing (see PR 25717). It splits the headers-synchronization in two phases:
- One (presyncing) throughout which headers are downloaded from friends, and verified, however not saved (apart from a really small dedication).
- If (and provided that) the presync phases reaches headers that beat the minimal chainwork setting, and have an opportunity of beating the chain we have already got, the headers are redownloaded and in contrast towards what we obtained earlier than, and saved for additional processing (which incorporates downloading the total blocks).
By doing this, an attacker can’t spam a node anymore in a approach that issues utilizing a low-difficulty headers chain. This fixes the issue fully, with out checkpoints, and even extends the safety to factors earlier than the node has reached the checkpoints. With the last-known weak point that checkpoints defend towards gone, they could possibly be eliminated fully.
To reply your precise questions:
Why a listing of checkpoints is saved if solely the final one is used?
Each checkpoint labored (and thus far, works) solely when reached. Its impact is that after you settle for a block whose hash matches a checkpoint, no extra reorgs are permitted away from it. Which means that if the checkpoint record have been fully unsuitable, it might haven’t any impact, relatively than stopping you from synchronizing in any respect.
This additionally meant that earlier than the introduction of headers-presync, the priority for headers spam was even better for a brand new node that simply began up, as a result of so long as it had not handed all of the checkpoints, it might be susceptible to header spam chains that fork off from earlier checkpoints, and even genesis, which might be far cheaper nonetheless.
Why are they nonetheless getting used if the final checkpoint is from 2014?
At this level, the one cause is due to unknown unknowns: are there maybe undiscovered assaults (like low-difficulty header spam, however maybe completely different) that aren’t prevented by headers presync, however are made dearer by checkpoints, even when simply mildly? We consider not, however this concern, plus inertia, have resulted in them not having been eliminated but.
Would not it higher to make use of the assumevalid block as a “checkpoint”?
That, or one other newer checkpoint, would have been alternate options to the problem of falling prices of a low-difficulty spam assault. I consider the headers pre-sync method we used as a substitute is much more elegant, because it successfully lifts the safety of the minchainwork setting to header spam safety in a really generic approach, and it does so with out ever truly even doubtlessly affecting which chain is definitely thought of legitimate, not like checkpoints.
Disclaimer: I helped design the headers pre-synchronization mechanism.