Team CryptoInsightfull 
Short answer: there remained a single known attack (low-difficulty header spam) that checkpoints somewhat protected against, even if they were old. As mining hardware continued to become cheaper per hash, that protection became weaker too, as explained in a recent security disclosure. Since Bitcoin Core 24.0, that attack is no longer possible, using a solution (headers presyncing) that does not require forcing a particular chain onto users (unlike checkpoints). As of early 2025, there is active discussion about removing checkpoints entirely.
Longer answer.
Ever since headers-first synchronization was introduced in Bitcoin 0.10, the only reason checkpoints were still useful is to combat headers spam.
I will quote another answer on the topic of mine:
since the headers-first synchronization introduced in Bitcoin Core 0.10.0, blocks are never downloaded before their headers are known and verified to have sufficient work (which means: enough to be within one day of the active chain tip, and more than the preconfigured minimum chain work). This means we already don’t need to worry about low-difficulty block spam anymore. The blocks are just not downloaded unless they’re part of a chain that’s proven to be good enough.
Yet, a weaker problem remained: a peer could start giving us (multiple) chains of headers that never amount to anything valuable. Since the headers are sent in forward order, there is no way to know at the beginning how good the result will get.
I give this as context, because when discussing security measures it is always good to keep in mind what problems we are trying to prevent: checkpoints were just there to prevent attackers from filling people’s disks and memory with large amounts of low-difficulty chains that fork off very early on (e.g., just after the genesis block) and never actually reach as much work as the real one, but the software has no means of figuring out that they can’t.
However, if somehow a chain existed which actually forked off from right after genesis, which was valid, and had more work than the chain we consider real today, the software should accept it, drastic as it is. Bitcoin’s security model relies on proof-of-work, which means accepting the most-work valid chain, even if it is perhaps not the chain we want.
I mention this, because people sometimes believe that checkpoints are a security feature that protects against deep reorgs. I believe that is a mistake: if deep reorgs happen, some of the very core assumption underlying proof-of-work are broken, and we should consider fixing it. Checkpoints are not a fix for this: either they are put so far in the past that they have no effect on which chain is accepted (as is the case now), or they’re made frequently at which point it is replacing a computer-system based consensus system with a human one.
So: all checkpoints do is force a headers-spamming attacker to fork off from the chain in 2014, rather than in 2009, where the difficulty is a lot higher (but still orders of magnitude lower than today). This makes the headers-spam attack many times more expensive, but as mining hardware has kept developing, as of 2022, the cost of the attack had gone down to roughly 1 BTC in mining costs (as explained in the security disclosure).
Since Bitcoin Core 24.0, a new approach to headers synchronization is introduced: headers pre-syncing (see PR 25717). It splits the headers-synchronization in two phases:
- One (presyncing) during which headers are downloaded from peers, and verified, but not stored (except for a very small commitment).
- If (and only if) the presync phases reaches headers that beat the minimum chainwork setting, and have a chance of beating the chain we already have, the headers are redownloaded and compared against what we received before, and stored for further processing (which includes downloading the full blocks).
By doing this, an attacker cannot spam a node anymore in a way that matters using a low-difficulty headers chain. This fixes the problem entirely, without checkpoints, and even extends the protection to points before the node has reached the checkpoints. With the last-known weakness that checkpoints protect against gone, they could be removed entirely.
To answer your actual questions:
Why a list of checkpoints is saved if only the last one is used?
Every checkpoint worked (and so far, works) only when reached. Its effect is that once you accept a block whose hash matches a checkpoint, no more reorgs are permitted away from it. This means that if the checkpoint list were completely wrong, it would have no effect, rather than preventing you from synchronizing at all.
This also meant that before the introduction of headers-presync, the concern for headers spam was even greater for a new node that just started up, because as long as it had not passed all the checkpoints, it would be vulnerable to header spam chains that fork off from earlier checkpoints, or even genesis, which would be far cheaper still.
Why are they still being used if the last checkpoint is from 2014?
At this point, the only reason is because of unknown unknowns: are there perhaps undiscovered attacks (like low-difficulty header spam, but perhaps different) that are not prevented by headers presync, but are made more expensive by checkpoints, even if just mildly? We believe not, but this concern, plus inertia, have resulted in them not having been removed yet.
Wouldn’t it better to use the assumevalid block as a “checkpoint”?
That, or another more recent checkpoint, would have been alternatives to the issue of falling costs of a low-difficulty spam attack. I believe the headers pre-sync approach we used instead is a lot more elegant, as it effectively lifts the protection of the minchainwork setting to header spam protection in a very generic way, and it does so without ever actually even potentially affecting which chain is actually considered valid, unlike checkpoints.
Disclaimer: I helped design the headers pre-synchronization mechanism.
