From: Sjors Provoost <sjors@sprovoost•nl>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Removing checkpoints in Bitcoin Core v30
Date: Mon, 28 Apr 2025 18:25:39 +0200 [thread overview]
Message-ID: <8E4DFC2E-23D4-4D22-87C5-415A3CFC7E57@sprovoost.nl> (raw)
In-Reply-To: <F8E9B25A-5198-4A5E-B3D7-9DAD6B709825@sprovoost.nl>
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.
prev parent reply other threads:[~2025-04-29 6:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-28 11:34 Sjors Provoost
2025-04-28 16:25 ` Sjors Provoost [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8E4DFC2E-23D4-4D22-87C5-415A3CFC7E57@sprovoost.nl \
--to=sjors@sprovoost$(echo .)nl \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox