Quick reply: there remained a single identified assault (low-difficulty header spam) that checkpoints considerably protected in opposition to, even when they have been previous. As mining {hardware} continued to change into cheaper per hash, that safety grew to become weaker too, as defined in a current 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 (in contrast to checkpoints). As of early 2025, there may be energetic dialogue about eradicating checkpoints totally.

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:

for the reason that 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 ample work (which suggests: sufficient to be inside sooner or later of the energetic chain tip, and greater than the preconfigured minimal chain work). This implies we already needn’t fear about low-difficulty block spam anymore. The blocks are simply not downloaded except they’re a part of a series that is confirmed to be ok.

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 is no such thing as a strategy to know at first how good the end result will get.

I give this as context, as a result of when discussing safety measures it’s at all times good to bear in mind what issues we are attempting to stop: checkpoints have been simply there to stop attackers from filling folks’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 really attain as a lot work as the actual one, however the software program has no technique of determining that they can not.

Nonetheless, if someway a series existed which really forked off from proper after genesis, which was legitimate, and had extra work than the chain we contemplate actual right now, 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 would like.

I point out this, as a result of folks typically imagine that checkpoints are a safety characteristic that protects in opposition to deep reorgs. I imagine that could be a mistake: if deep reorgs occur, a few of the very core assumption underlying proof-of-work are damaged, and we must always contemplate fixing it. Checkpoints usually are not a repair for this: both they’re put thus far prior to now that they don’t have any impact on which chain is accepted (as is the case now), or they’re made incessantly at which level it’s changing a computer-system primarily based consensus system with a human one.

So: all checkpoints do is power a headers-spamming attacker to fork off from the chain in 2014, fairly than in 2009, the place the issue is a lot increased (however nonetheless orders of magnitude decrease than right now). This makes the headers-spam assault many occasions dearer, however as mining {hardware} has saved growing, as of 2022, the price of the assault had gone right 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 in opposition to 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 totally, with out checkpoints, and even extends the safety to factors earlier than the node has reached the checkpoints. With the last-known weak spot that checkpoints shield in opposition to gone, they may very well be eliminated totally.

To reply your precise questions:

Why an inventory 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 when you settle for a block whose hash matches a checkpoint, no extra reorgs are permitted away from it. Which means if the checkpoint record have been utterly unsuitable, it will don’t have any impact, fairly 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 larger 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 will be weak 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 totally different) that aren’t prevented by headers presync, however are made dearer by checkpoints, even when simply mildly? We imagine 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 options to the problem of falling prices of a low-difficulty spam assault. I imagine 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 really even doubtlessly affecting which chain is definitely thought of legitimate, in contrast to checkpoints.

Disclaimer: I helped design the headers pre-synchronization mechanism.