From: Sjors Provoost <sjors@sprovoost•nl>
To: bitcoindev@googlegroups.com
Cc: Ruben Somsen <rsomsen@gmail•com>
Subject: Re: [bitcoindev] The Tragic Tale of BIP30
Date: Mon, 28 Apr 2025 13:48:31 +0200 [thread overview]
Message-ID: <86FA0255-1A81-4DA1-9B1A-E57AD4F1DAAD@sprovoost.nl> (raw)
In-Reply-To: <CAPv7TjZTWhgzzdps3vb0YoU3EYJwThDFhNLkf4XmmdfhbORTaw@mail.gmail.com>
Luke Dashr wrote:
> Solution C could be to remove it, but restore the previous UTXO. In other words, treat the overwrite as a spend of the overwritten transaction.
This might also be cleaner at the Bitcoin Core implementation level, because each UTXO set entry contains its creation height. And it might (conceptually) help Utreexo and SwiftSync.
Eric Voskuil 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.
Ruben Somsen wrote:
> One last point to address is why BIP34 gets deactivated if block 227931 is reorged out. The reason for this is because otherwise it'd open the door to possibly creating outputs prior to BIP34's activation that will conflict with BIP34's rules for ensuring coinbase transaction uniqueness (the exact issue the Consensus Cleanup is seeking to resolve).
>
> Ideally, it'd be nice to be able to sunset the BIP30 UTXO set check completely, ensuring it's no longer required, even in case of a reorg.
As I suggested in the other thread, it might be useful to have a more general BIP to describe the various issues around an alien-attack level reorg, for those who want to stick around and salvage the project.
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.
(while you're at it, this rule could disable bare script, p2pk, p2sh, segwit v0, sigops counting and maybe some legacy stuff)
- 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/86FA0255-1A81-4DA1-9B1A-E57AD4F1DAAD%40sprovoost.nl.
next prev parent reply other threads:[~2025-04-28 12:04 UTC|newest]
Thread overview: 6+ 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 [this message]
2025-04-28 12:39 ` Eric Voskuil
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=86FA0255-1A81-4DA1-9B1A-E57AD4F1DAAD@sprovoost.nl \
--to=sjors@sprovoost$(echo .)nl \
--cc=bitcoindev@googlegroups.com \
--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