* [bitcoindev] Removing checkpoints in Bitcoin Core v30
@ 2025-04-28 11:34 Sjors Provoost
2025-04-28 16:25 ` Sjors Provoost
0 siblings, 1 reply; 2+ messages in thread
From: Sjors Provoost @ 2025-04-28 11:34 UTC (permalink / raw)
To: Bitcoin Development Mailing List
Dear list,
I thought this was already communicated, but I can't find a thread.
A recent pull request was merged into Bitcoin Core that removes existing checkpoints and all related support code.[0] The current plan is for this change to be part of v30 which should be released this fall.
Checkpoints are no longer needed in order to protect against low proof-of-work header spam attacks, thanks to the headers pre-sync functionality included since v24. [1]
The existing checkpoints no longer provide enough security against those attacks. Adding new checkpoints is not desirable.
However, if someone is aware of another attack, please disclose it (ideally responsibly) so the change can be reverted. [2]
Since older versions of Bitcoin Core, as well as other Bitcoin implementations, still enforce the checkpoints, an extremely large reorg (attack by aliens, NSA, etc) would split the network. This may already be the case due to the way some older soft forks have been grandfathered / buried in Bitcoin Core.[3]
I think many would consider Bitcoin a total loss in such a scenario and not worth salvaging - especially if the attacker didn't airdrop you any coins in the reorg. But it could be useful for someone to write a BIP that describes what happens in such a scenario. It could recommend ways to at least regain consistency, and perhaps permanently apply some soft fork rules from genesis (e.g. activate them if the last checkpoint header is absent).
Kind regards,
Sjors Provoost
[0] https://github.com/bitcoin/bitcoin/pull/31649
[1] https://bitcoin.stackexchange.com/a/121235/4948
[2] https://github.com/bitcoin/bitcoin/blob/master/SECURITY.md
[3] https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/F8E9B25A-5198-4A5E-B3D7-9DAD6B709825%40sprovoost.nl.
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [bitcoindev] Removing checkpoints in Bitcoin Core v30
2025-04-28 11:34 [bitcoindev] Removing checkpoints in Bitcoin Core v30 Sjors Provoost
@ 2025-04-28 16:25 ` Sjors Provoost
0 siblings, 0 replies; 2+ messages in thread
From: Sjors Provoost @ 2025-04-28 16:25 UTC (permalink / raw)
To: Bitcoin Development Mailing List
Note that my original mail was written in a hurry and does not provide a full overview of the arguments for and against checkpoints. Perhaps this thread can serve as a collection point for the various historical discussions that were had on this topic.
In the context of BIP30 [0] Eric Voskuil brought up performance:
> The top checkpoint is consensus for over 11 years and materially reduces the validation cost of 295,000 blocks.
I don't think performance should be a consideration when removing checkpoints.
Afaik checkpoints were not introduced as a performance feature, but rather as a DoS vulnerability fix.
Even if they were, imo they shouldn't be used for performance enhancement, as it creates a temptation to add more - although Eric clearly says:
> I would never advocate for adding more
But perhaps someone else would fork Bitcoin Core (or Libbitcoin) and start with honest checkpoints, in order to gain adoption due its excellent performance - especially when combined with a UTXO snapshot. And then suddenly it has an "upgrade".
But even if this wasn't a concern, the performance benefit of the latest checkpoint from 2014 is just very small. That's because the early blocks don't have that many signatures to check. The first 5 years of Bitcoin represent only 3% of all historical transactions.
On an M4 MacBook I did an IBD up to the last checkpoint at height 295,000. This took 17.5 minutes.
I then ran it again with -assumevalid=0, i.e. checking all signatures, which took 18 minutes.
These times are from connecting the first block until connecting block 295,000. They exclude the 1.5 minutes spent on the header pre-sync mechanism, which is required to operate safely with or without (new) checkpoints. In both cases I used -dbcache=3000 to avoid UTXO set disk I/O.
The difference is 30 seconds, but let's round that up to 1 minute because my setup isn't a clean lab.
A full IBD takes at least 5 hours on this machine, so the benefit is roughly 0.3% (unless we add another checkpoint).
Loading a UTXO snapshot at the checkpoint height, without doing background validation of historical blocks, might get us an additional 15 minute speedup, which is still only 5%.
Libbitcoin would probably find a different ratio, as might a machine with severe CPU limitations, but I suspect it will be equally negliable. And without new checkpoints the ratio keeps going down over time.
Note that -assumevalid doesn't need checkpoints, it just falls back to more slow validation if there is a major reorg (but perhaps sub catastrophic). Its performance benefit for the present day blockchain should be much higher than what I found here.
That said, I've never been a fan of -assumevalid conceptually. Hopefully it can be replaced by something like AssumeUTXO + SwiftSync [1] for the background with full validation using block Undo data.
- Sjors
[0] https://gnusha.org/pi/bitcoindev/E8225EAC-BED8-4840-8E3D-81A55C365209@voskuil.org/T/#mf3d290b70bae822cf31a683439ca8dbaed443e42
[1] https://gnusha.org/pi/bitcoindev/CAPv7TjaM0tfbcBTRa0_713Bk6Y9jr+ShOC1KZi2V3V2zooTXyg@mail.gmail.com/
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8E4DFC2E-23D4-4D22-87C5-415A3CFC7E57%40sprovoost.nl.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-04-29 6:26 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-04-28 11:34 [bitcoindev] Removing checkpoints in Bitcoin Core v30 Sjors Provoost
2025-04-28 16:25 ` Sjors Provoost
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox