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-81a55c365...@voskuil.org/T/#mf3d290b70bae822cf31a683439ca8dbaed443e42 [1] https://gnusha.org/pi/bitcoindev/capv7tjam0tfbcbtra0_713bk6y9jr+shoc1kzi2v3v2zoot...@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+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8E4DFC2E-23D4-4D22-87C5-415A3CFC7E57%40sprovoost.nl.
