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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/86FA0255-1A81-4DA1-9B1A-E57AD4F1DAAD%40sprovoost.nl.
