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

From: <[email-masked]>
Date: Fri, 2 May 2025 17:09:29 -0400

Hi Sjors, 

> > >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.
> 
> The trick is that no blocks obey the BIP54 rule for nLockTime, so they'll
all be
> rejected and you can fork off starting at block 1.

This ignores the chain splits resulting from the 14 checkpoints that have
been removed to get to block 1. If the consensus is to not care about these
hard forks causing chain splits, there is really no reason to care about
this BIP30 chain split being caused by their removal.

Best,
Eric

-- 
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/035401dbbba6%247ea41790%247bec46b0%24%40voskuil.org.