Delivery-date: Mon, 28 Apr 2025 23:26:01 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of sjors@sprovoost.nl designates 202.12.124.155 as permitted sender) client-ip=202.12.124.155;
Feedback-ID: ie5e042df:Fastmail
From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
Subject: Re: [bitcoindev] Removing checkpoints in Bitcoin Core v30
Date: Mon, 28 Apr 2025 18:25:39 +0200
References: <F8E9B25A-5198-4A5E-B3D7-9DAD6B709825@sprovoost.nl>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
In-Reply-To: <F8E9B25A-5198-4A5E-B3D7-9DAD6B709825@sprovoost.nl>
Message-Id: <8E4DFC2E-23D4-4D22-87C5-415A3CFC7E57@sprovoost.nl>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

Note that my original mail was written in a hurry and does not provide a fu=
ll overview of the arguments for and against checkpoints. Perhaps this thre=
ad can serve as a collection point for the various historical discussions t=
hat 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 checkpoin=
ts.

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 perfor=
mance - 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 ch=
eckpoint 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 represen=
t 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=3D0, i.e. checking all signatures, wh=
ich took 18 minutes.=20

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, w=
hich is required to operate safely with or without (new) checkpoints. In bo=
th cases I used -dbcache=3D3000 to avoid UTXO set disk I/O.

The difference is 30 seconds, but let's round that up to 1 minute because m=
y setup isn't a clean lab.

A full IBD takes at least 5 hours on this machine, so the benefit is roughl=
y 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 speed=
up, which is still only 5%.

Libbitcoin would probably find a different ratio, as might a machine with s=
evere CPU limitations, but I suspect it will be equally negliable. And with=
out 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 highe=
r 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 backg=
round with full validation using block Undo data.

- Sjors

[0] https://gnusha.org/pi/bitcoindev/E8225EAC-BED8-4840-8E3D-81A55C365209@v=
oskuil.org/T/#mf3d290b70bae822cf31a683439ca8dbaed443e42
[1] https://gnusha.org/pi/bitcoindev/CAPv7TjaM0tfbcBTRa0_713Bk6Y9jr+ShOC1KZ=
i2V3V2zooTXyg@mail.gmail.com/

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
8E4DFC2E-23D4-4D22-87C5-415A3CFC7E57%40sprovoost.nl.