Subject: Re: [bitcoindev] The Tragic Tale of BIP30

From: Ruben Somsen <[email-masked]>
Date: Tue, 29 Apr 2025 17:11:40 +0200

Hi,

Replying to parts of all messages thus far.

>The obvious solution to this problem is to not create the problem in the
first place.

Yes, that is a fair point. Not removing the checkpoints is one way of
ensuring the consensus bug cannot be triggered. I'm agnostic about whether
having checkpoints is also a reason to forgo consensus checks such as
BIP30 (or my proposed alternative of checking the coinbase TXID for
uniqueness and ensuring no future collision). Even though checkpoints
essentially force your node to halt if something were invalid up until that
point, I still think there is value in being able to verify that the rules
were followed.

>Solution C could be to remove it, but restore the previous UTXO

Yes, as Sjors also pointed out, I do think it is best to be precise about
which of the duplicates you're keeping. In fact, it's probably required to
ensure the rolling UTXO set hash remains consistent.

>In the case of BIP30, one option could be to have a rule that says: if the
2014 checkpoint is missing, then enforce the BIP54 Consensus Cleanup
nLockTime rule from genesis. BIP34 can then simply go away.

I'm afraid it's not that simple. If you wanted to fork off from some
arbitrary point prior to the last checkpoint, you'd want to enforce the new
consensus rules from that exact point (not from genesis), but that requires
shipping the full node software with a hash for every possible block that
could be forked off from. It's roughly 8MB of data so it's not impossible,
and I even had this written up as an alternative solution, but I removed it
in favor of the solution I ended up describing.

Cheers,
Ruben

On Mon, Apr 28, 2025 at 2:39 PM Eric Voskuil <[email-masked]> wrote:

>
> > On Apr 28, 2025, at 08:04, Sjors Provoost <[email-masked]> wrote:
> >
> >> I'm not aware of any compelling argument to hard fork out the existing
> checkpoints
> >
> > Bitcoin Core plans to remove checkpoints entirely by v30 this fall. I
> just started a thread about this.
>
> The thread does not provide or reference any compelling argument (or any
> argument that I can find) for removing the checkpoints.
>
> One reference states that “assume valid” speeds IBD, but of course it does
> so by not validating. So this does not provide a comparable offset to the
> increased validation cost, and even if it did does not provide an argument
> for hard forking them out.
>
> e

-- 
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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAPv7TjbEK8r8AQgzLvrwPmQHavU-ujgJqSz%2B7CFy_8W0_pwMvQ%40mail.gmail.com.