From: <eric@voskuil•org>
To: "'Ruben Somsen'" <rsomsen@gmail•com>, <bitcoindev@googlegroups.com>
Cc: "'Sjors Provoost'" <sjors@sprovoost•nl>, <luke@dashjr•org>
Subject: RE: [bitcoindev] The Tragic Tale of BIP30
Date: Fri, 2 May 2025 17:09:05 -0400 [thread overview]
Message-ID: <035301dbbba6$701dd490$50597db0$@voskuil.org> (raw)
In-Reply-To: <CAPv7TjbEK8r8AQgzLvrwPmQHavU-ujgJqSz+7CFy_8W0_pwMvQ@mail.gmail.com>
Hi Ruben,
> >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.
It's more than that. We are contemplating a "consensus bug" that would cause a chain split because the BIP30 exceptions are no longer being covered by any checkpoint. The heights at which this would cause a split are well below all but 3 of the 14 checkpoints. For that to occur 11 formerly checkpointed blocks would first have to be popped, given the existence of a stronger chain capable of triggering the above bug. This implies 11 more chain splits, depending at which point nodes adopted the checkpoint soft fork(s), just to reach this bug, and up to 14 possible in total. It makes no sense to fix this bug without first fixing chain splits that would be triggered *over 200,000 blocks less deep* than this BIP30 bug. And the only way to fix those is to not remove the checkpoints - which renders this bug inert.
> 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).
There is certainly a reason, the checkpoints are consensus rules.
> Even though checkpoints essentially force your node to halt if something were invalid up until that point,
Right, if any other rule conflicted with them then the chain would stall forever at that point. That is not the applied meaning of these rules. The checkpoints declare that the blocks are required and therefore inherently valid. The reason we are having this conversation is the contemplated removal of the checkpoints, which also implies that other validation within covered blocks is not consensus.
> I still think there is value in being able to verify that the rules were followed.
Like them or not, checkpoints are the rules that are required to be 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.
Sure, but these are implementation details, not a matter of consensus. The consensus behavior would be that the second output is popped with its block and the first remains with its block. Assuming it would be written up, that's how I would recommend handling it.
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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/035301dbbba6%24701dd490%2450597db0%24%40voskuil.org.
prev parent reply other threads:[~2025-05-02 22:24 UTC|newest]
Thread overview: 10+ 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
2025-05-02 21:09 ` eric
2025-05-02 21:09 ` eric [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='035301dbbba6$701dd490$50597db0$@voskuil.org' \
--to=eric@voskuil$(echo .)org \
--cc=bitcoindev@googlegroups.com \
--cc=luke@dashjr$(echo .)org \
--cc=rsomsen@gmail$(echo .)com \
--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