Delivery-date: Tue, 09 Apr 2024 10:01:38 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.159 as permitted sender) client-ip=103.168.172.159;
Feedback-ID: i525146e8:Fastmail
Date: Tue, 9 Apr 2024 16:48:36 +0000
From: Peter Todd <pete@petertodd.org>
To: "David A. Harding" <dave@dtrt.org>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Re: The Future of Bitcoin Testnet
Message-ID: <ZhVxZN6eLiCpdQ/F@petertodd.org>
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>
 <FB86E432-FAF0-466D-802D-938614AE0BDD@dtrt.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="jyulslSAKEGKB+6g"
Content-Disposition: inline
In-Reply-To: <FB86E432-FAF0-466D-802D-938614AE0BDD@dtrt.org>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--jyulslSAKEGKB+6g
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 06, 2024 at 01:04:16PM -1000, David A. Harding wrote:
>=20
>=20
> 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.
>=20
> What about fundamentally requiring BIP34 from the start of the next testn=
et?  I haven't heard anyone say this, but I assume the current testnet4 hav=
ing reverted[1] to BIP30 is bad for utreexo?
>=20
> 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 d=
on'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 m=
atches a given txid.  Thus, as I understand it, Utreexo depends on every tr=
ansaction having a unique txid.
>=20
> BIP34 requires every coinbase transaction include a unique data push, fix=
ing the only known way to include two bit-identical transactions in the sam=
e valid blockchain.  On blockchains such as mainnet and testnet4 that start=
ed before BIP34, duplicate transactions remain possible in some rare edge c=
ases (called the Block 1,983,702 Problem), so BIP30 support remains necessa=
ry unless the underlying issue is further fixed (e.g. [2]).  For new blockc=
hains, 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 i=
t
would have to eventually deal with in mainnet.

In fact, ideally if we reset testnet we'd delibrately *add* non-unique txid=
s 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 ha=
ve a
large body of weirdness in the current testnet that serves as good test cas=
es
for any implementation. At the very least, if we do a testnet reset we shou=
ld
consider re-adding all those weird edge cases to the new testnet.

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

--=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/ZhVxZN6eLiCpdQ/F%40petertodd.org.

--jyulslSAKEGKB+6g
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmYVcVAACgkQLly11TVR
LzelIBAAiEmuFFVgz0IYZxbVTZ2ScUZU0r5U8Fky6rJxJR4J/6WsRyGymh8jojHQ
mw2EAZjeQd6wJaIMtbxH5iVp/6pAgd3dGXBDVCw+4N3a+pB3A1UvWiuguurxUFyw
QOIwawRTLosS98j7IbEot16ABJDyuVrkq/NlKCTWoMTdugc8jqv2Gx4NAD7/A6iC
WFC5dC9h5gMLCtRjT1OnLtRBudMfA6XoZyPRCMfU/U1KCIQ7Z2PIoKf5zztqXqqv
2PKo8p5/OqmjKJLKfZGfbGzDu44gUw8IKNae+bmkCcXU7swMBi9LMQ5udMjiTW6m
Wunm+IhpG+0UEdxYWez3iPcmIyp5zOpX0RE3NDCkbZktssHYsaKdcy9dhw8Hb26q
oZ/G9cgp2obX8g4j/JF15mLlKSIf5duNAjtGPTmr/hIlMCwF9PjcsIJiY7245OMh
H+NhA+NkvjtUu3dPggP06MtVfXkWTQwWojdbqgsGgcaJ9rHDvkbUb5Apngnj4n2V
JNrlyTCETay2EJnAZMKsnIwQ0ZV2eJR6u5yK5XRwjedwOyE8iLdAk6bzgsedbPog
R1gsUEoIocm7aQZmiVTOow5S9zA+AyB9qpIwuSwzk6YMCqNhzxAoYISfED7gPtyY
WRL6Qc5J1uUO4RJRHM3IDiM9BWynDADl6a6yZtOq48Qb82czVDA=
=k8v/
-----END PGP SIGNATURE-----

--jyulslSAKEGKB+6g--