Delivery-date: Sat, 06 Apr 2024 16:15:55 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of dave@dtrt.org designates 208.79.240.5 as permitted sender) client-ip=208.79.240.5;
Date: Sat, 06 Apr 2024 13:04:16 -1000
From: "David A. Harding" <dave@dtrt.org>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Re: The Future of Bitcoin Testnet
User-Agent: K-9 Mail for Android
In-Reply-To: <efa3e907-cd2b-4897-b476-8bbc6091a3edn@googlegroups.com>
References: <CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com> <950b875a-e430-4bd8-870d-f9a9fab2493an@googlegroups.com> <CADL_X_fs0OVAoFiekm3sLUyODXr6j7mh8M6zQV_dEyg05itE6A@mail.gmail.com> <efa3e907-cd2b-4897-b476-8bbc6091a3edn@googlegroups.com>
Message-ID: <FB86E432-FAF0-466D-802D-938614AE0BDD@dtrt.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


On April 4, 2024 6:30:19 PM HST, Calvin Kim <ccychc@gmail.com> 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 havin=
g reverted[1] to BIP30 is bad for utreexo?

For context, BIP30 invalidates any block that has a transaction with the sa=
me 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 u=
ntrusted third party can't prove to a utreexo node that no current UTXO mat=
ches a given txid.  Thus, as I understand it, Utreexo depends on every tran=
saction having a unique txid.

BIP34 requires every coinbase transaction include a unique data push, fixin=
g 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 cas=
es (called the Block 1,983,702 Problem), so BIP30 support remains necessary=
 unless the underlying issue is further fixed (e.g. [2]).  For new blockcha=
ins, like a potential testnet5,  I think we should probably require BIP34 f=
rom genesis so that there's no need to ever rely on BIP30.

-Dave

[1] https://bitcoinops.org/en/newsletters/2022/01/12/#bitcoin-core-23882
[2] https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710=20

--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/FB86E432-FAF0-466D-802D-938614AE0BDD%40dtrt.org.