From: Sjors Provoost <sjors@sprovoost•nl>
To: Ruben Somsen <rsomsen@gmail•com>
Cc: bitcoindev@googlegroups.com, Eric Voskuil <eric@voskuil•org>,
luke@dashjr•org
Subject: Re: [bitcoindev] The Tragic Tale of BIP30
Date: Tue, 29 Apr 2025 17:28:13 +0200 [thread overview]
Message-ID: <ECC8258A-2DA5-4DD3-9D87-34D77C0C2C05@sprovoost.nl> (raw)
In-Reply-To: <CAPv7TjbEK8r8AQgzLvrwPmQHavU-ujgJqSz+7CFy_8W0_pwMvQ@mail.gmail.com>
Ruben Somsen wrote:
> >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.
- Sjors
--
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/ECC8258A-2DA5-4DD3-9D87-34D77C0C2C05%40sprovoost.nl.
prev parent reply other threads:[~2025-04-29 15:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-27 16:45 Ruben Somsen
2025-04-27 18:20 ` Luke Dashjr
2025-04-27 18:30 ` eric
2025-04-27 21:01 ` eric
2025-04-28 11:48 ` Sjors Provoost
2025-04-28 12:39 ` Eric Voskuil
2025-04-29 15:11 ` Ruben Somsen
2025-04-29 15:28 ` 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=ECC8258A-2DA5-4DD3-9D87-34D77C0C2C05@sprovoost.nl \
--to=sjors@sprovoost$(echo .)nl \
--cc=bitcoindev@googlegroups.com \
--cc=eric@voskuil$(echo .)org \
--cc=luke@dashjr$(echo .)org \
--cc=rsomsen@gmail$(echo .)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