Subject: Re: [bitcoindev] Re: The Future of Bitcoin Testnet

From: Peter Todd <[email-masked]>
Date: Tue, 9 Apr 2024 16:48:36 +0000

On Sat, Apr 06, 2024 at 01:04:16PM -1000, David A. Harding wrote:
> 
> 
> On April 4, 2024 6:30:19 PM HST, Calvin Kim <[email-masked]> wrote:
> >I support reseting testnet3.
> >
> >However, I'm more inclined towards keeping the rules the same.
> 
> What about fundamentally requiring BIP34 from the start of the next testnet?  I haven't heard anyone say this, but I assume the current testnet4 having reverted[1] to BIP30 is bad for utreexo?
> 
> For context, BIP30 invalidates any block that has a transaction with the same txid as an entry in the current UTXO set.  A utreexo node doesn't have a complete copy of the utxo set, so it can't enforce BIP30 by itself.  I don't think current designs support efficient proof of non-membership, so an untrusted third party can't prove to a utreexo node that no current UTXO matches a given txid.  Thus, as I understand it, Utreexo depends on every transaction having a unique txid.
> 
> BIP34 requires every coinbase transaction include a unique data push, fixing the only known way to include two bit-identical transactions in the same valid blockchain.  On blockchains such as mainnet and testnet4 that started before BIP34, duplicate transactions remain possible in some rare edge cases (called the Block 1,983,702 Problem), so BIP30 support remains necessary unless the underlying issue is further fixed (e.g. [2]).  For new blockchains, like a potential testnet5,  I think we should probably require BIP34 from genesis so that there's no need to ever rely on BIP30.

NACK

One of the purposes of testnet is to exercise edge cases in code, in an
environment where mistakes don't cost money. It's a good thing that, eg, a
utreexo testnet implementation has to deal with all the the same warts as it
would have to eventually deal with in mainnet.

In fact, ideally if we reset testnet we'd delibrately *add* non-unique txids to
testnet to ensure that code related to that flaw is exercised; IIRC testnet
currently does not have any.

I also believe this principal is a reason to avoid resetting testnet: we have a
large body of weirdness in the current testnet that serves as good test cases
for any implementation. At the very least, if we do a testnet reset we should
consider re-adding all those weird edge cases to the new testnet.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
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-masked].
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZhVxZN6eLiCpdQ/F%40petertodd.org.