From: Ruben Somsen <rsomsen@gmail•com>
To: bitcoindev@googlegroups.com
Cc: Eric Voskuil <eric@voskuil•org>,
Sjors Provoost <sjors@sprovoost•nl>,
luke@dashjr•org
Subject: Re: [bitcoindev] The Tragic Tale of BIP30
Date: Tue, 29 Apr 2025 17:11:40 +0200 [thread overview]
Message-ID: <CAPv7TjbEK8r8AQgzLvrwPmQHavU-ujgJqSz+7CFy_8W0_pwMvQ@mail.gmail.com> (raw)
In-Reply-To: <E8225EAC-BED8-4840-8E3D-81A55C365209@voskuil.org>
[-- Attachment #1: Type: text/plain, Size: 2869 bytes --]
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 <eric@voskuil•org> wrote:
>
> > On Apr 28, 2025, at 08:04, Sjors Provoost <sjors@sprovoost•nl> 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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAPv7TjbEK8r8AQgzLvrwPmQHavU-ujgJqSz%2B7CFy_8W0_pwMvQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 3763 bytes --]
next prev parent reply other threads:[~2025-04-29 15:14 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 [this message]
2025-04-29 15:28 ` Sjors Provoost
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=CAPv7TjbEK8r8AQgzLvrwPmQHavU-ujgJqSz+7CFy_8W0_pwMvQ@mail.gmail.com \
--to=rsomsen@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=eric@voskuil$(echo .)org \
--cc=luke@dashjr$(echo .)org \
--cc=sjors@sprovoost$(echo .)nl \
/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