Delivery-date: Thu, 30 May 2024 15:00:23 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) client-ip=2620:6e:a000:1::99;
Message-ID: <d40a0279-6a5f-4748-ae80-6b9f05e40881@mattcorallo.com>
Date: Thu, 30 May 2024 13:46:38 -0400
MIME-Version: 1.0
Subject: Re: [bitcoindev] BIP for Testnet 4
To: Fabian <fjahr@protonmail.com>,
 Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
References: <a6e3VPsXJf9p3gt_FmNF_Up-wrFuNMKTN30-xCSDHBKXzXnSpVflIZIj2NQ8Wos4PhQCzI2mWEMvIms_FAEs7rQdL15MpC_Phmu_fnR9iTg=@protonmail.com>
Content-Language: en-US
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <a6e3VPsXJf9p3gt_FmNF_Up-wrFuNMKTN30-xCSDHBKXzXnSpVflIZIj2NQ8Wos4PhQCzI2mWEMvIms_FAEs7rQdL15MpC_Phmu_fnR9iTg=@protonmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

I believe I raised this on the Bitcoin Core PR, but I strongly think any ne=
w testnet should, like=20
was done with testnet3, get a premine with "interesting" scripts and transa=
ctions in it (presumably=20
the output of the fuzzer from Bitcoin Core and maybe some valid transaction=
s hitting various known=20
edge cases that require valid signatures). This would (potentially) implica=
te the BIP as it would=20
imply shipping with an initial checkpoint of the first NN blocks.

Matt

On 5/28/24 6:01 PM, 'Fabian' via Bitcoin Development Mailing List wrote:
> Hello list,
>=20
> a potential reset or replacement of Testnet 3 has been discussed on this =
list previously here:=20
> https://groups.google.com/g/bitcoindev/c/9bL00vRj7OU/m/9yCPo3uUBwAJ=20
> <https://groups.google.com/g/bitcoindev/c/9bL00vRj7OU/m/9yCPo3uUBwAJ>
>=20
> The discussion continued in the accompanying bitcoin core pull request=20
> (https://github.com/bitcoin/bitcoin/pull/29775 <https://github.com/bitcoi=
n/bitcoin/pull/29775>)=20
> which has been tested in the past couple of weeks and adopted by several =
projects on an experimental=20
> basis, such as https://mempool.space/testnet4 <https://mempool.space/test=
net4>=C2=A0for example.
>=20
> I have now formalized the current rules and genesis block implemented in =
the PR as BIP draft:=20
> https://github.com/bitcoin/bips/pull/1601 <https://github.com/bitcoin/bip=
s/pull/1601>
>=20
> -----------
> =3D=3D Abstract =3D=3D
>=20
> A new test network with the goal to replace Testnet 3. This network comes=
 with small but important=20
> improvements of the consensus rules, that should make it impractical to a=
ttack the network using=20
> only CPU mining.
>=20
> =3D=3D Motivation =3D=3D
>=20
> Quoting the original mailing list post from Jameson Lopp:
>=20
> "Testnet3 has been running for 13 years. It's on block 2.5 million someth=
ing and the block reward is=20
> down to ~0.014 TBTC, so mining is not doing a great job at distributing t=
estnet coins anymore.
>=20
> The reason the block height is insanely high is due to a rather amusing e=
dge case bug that causes=20
> the difficulty to regularly get reset to 1, which causes a bit of havoc. =
If you want a deep dive=20
> into the quirk: https://blog.lopp.net/the-block-storms-of-bitcoins-testne=
t/=20
> <https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/>
>=20
> Testnet3 is being actively used for scammy airdrops; those of us who tend=
 to be generous with our=20
> testnet coins are getting hounded by non-developers chasing cheap gains.
>=20
> As a result, TBTC is being actively bought and sold; one could argue that=
 the fundamental principle=20
> of testnet coins having no value has been broken."
>=20
> Since then the issue with block storms has been further demonstrated on T=
estnet 3 when three years'=20
> worth of blocks were mined in a few weeks while rendering the network pra=
ctically unusable at the=20
> same time.
>=20
> =3D=3D Specification =3D=3D
>=20
> Consensus of Testnet 4 follows the same rules as Testnet 3 with the excep=
tion of the two new rules=20
> detailed below.
>=20
> This means that the existing 20 min difficulty exception in Testnet 3 is =
explicitly kept in place,=20
> meaning that a block with a timestamp 20 minutes further into the future =
from the current time is=20
> allowed to have a minimum difficulty of 1 instead of whatever the actual =
level currently is.
>=20
> =3D=3D=3D Block Storm Fix =3D=3D=3D
>=20
> When the next work required is calculated for the first block in a new di=
fficulty period, the=20
> difficulty of the last block of the previous difficulty period is only us=
ed as the base for this=20
> calculation if its difficulty is not 1. If its difficulty is 1, all block=
s in the previous=20
> difficulty period are checked in reverse order if any of them have a diff=
erent difficulty than 1.=20
> When a different difficulty is encountered, it is assumed to be the actua=
l difficulty of the network=20
> and used as the base for the calculation of the new difficulty level. Onl=
y if all blocks from the=20
> previous difficulty period have had a difficulty of 1 (possibly by the us=
e of the 20-min rule), this=20
> is also used as the base for the calculation of the next difficulty perio=
d.
>=20
> For the avoidance of doubt, no matter which block in the previous difficu=
lty period provides the=20
> actual difficulty used as the basis for the calculation, the timestamp of=
 the last block is always=20
> the one that is used as the end time of the difficulty period.
>=20
> =3D=3D=3D Time Warp Fix =3D=3D=3D
>=20
> To protect against the time warp attack, the following rule proposed as p=
art of The Great Consensus=20
> Cleanup is enforced: "The nTime field of each block whose height, mod 201=
6, is 0 must be greater=20
> than or equal to the nTime field of the immediately prior block minus 600=
. For the avoidance of=20
> doubt, such blocks must still comply with existing Median-Time-Past nTime=
 restrictions."
>=20
> =3D=3D Rationale =3D=3D
>=20
> The applied changes were the result of discussions on the mailing list an=
d the PR. The selected=20
> changes try to strike a balance between minimal changes to the network (k=
eeping it as close to=20
> mainnet as possible) while making it more robust against attackers that t=
ry to disrupt the network.=20
> Several alternative designs were considered:
>=20
> * For the block storm fix an alternative fix could have been to prevent t=
he last block in a=20
> difficulty period from applying the existing difficulty exception. Both s=
olutions were deemed=20
> acceptable and there was no clear preference among reviewers.
> * Removal of the 20-min difficulty exception was discussed but dismissed =
since several reviewers=20
> insisted that it was a useful feature allowing non-standard transactions =
to be mined with just a CPU.
> * Increase of minimum difficulty was discussed but dismissed as it would =
categorically prevent=20
> participation in the network using a CPU miner.
> * Increase of the delay in the 20 min difficulty exception was suggested =
but did not receive=20
> significant support.
> * Re-enabling <code>acceptnonstdtxn</code> in bitcoin core by default was=
 dismissed as it had led to=20
> confusion among layer-2s that had used testnet for transaction propagatio=
n tests and expected it to=20
> behave similar to mainnet.
> * Motivating miners to re-org min difficulty blocks was suggested but thi=
s may still be done after=20
> Testnet 4 is deployed, so it can be considered out of scope for this BIP.
> * Persisting the real difficulty in the version field was suggested to pr=
event exploits of the=20
> 20-min rule in an even more robust way, but did not receive a critical le=
vel of support since it=20
> would be a more invasive change.
>=20
> =3D=3D Network Parameters =3D=3D
>=20
> =3D=3D=3D Consensus Rules =3D=3D=3D
>=20
> All consensus rules active on mainnet at the time of this proposal are en=
forced from block 1, the=20
> newest of these rules being the Taproot softfork.
>=20
> =3D=3D=3D Genesis Block =3D=3D=3D
>=20
> * Message: <code>03/May/2024 000000000000000000001ebd58c244970b3aa9d783bb=
001011fbe8ea8e98e00e</code>
> * Pubkey: <code>000000000000000000000000000000000000000000000000000000000=
000000000</code>
> * Time stamp: 1714777860
> * Nonce: 393743547
> * Difficulty: <code>0x1d00ffff</code>
> * Version: 1
>=20
> The resulting genesis block hash is=20
> <code>00000000da84f2bafbbc53dee25a72ae507ff4914b867c565be350b0da8bf043</c=
ode>, and the block hex is=20
> <code>0100000001000000000000000000000000000000000000000000000000000000000=
0000000ffffffff5504ffff001d01044c4c30332f4d61792f32303234203030303030303030=
303030303030303030303030316562643538633234343937306233616139643738336262303=
0313031316662653865613865393865303065ffffffff0100f2052a01000000232100000000=
0000000000000000000000000000000000000000000000000000000000ac00000000</code>=
.
>=20
> =3D=3D=3D Message Start =3D=3D=3D
>=20
> The message start is defined as <code>0x1c163f28</code>. These four bytes=
 were randomly generated=20
> and have no special meaning.
>=20
> =3D=3D Compatibility =3D=3D
>=20
> This specification is backward compatible in the sense that existing soft=
ware can use Testnet 4 out=20
> of the box, assuming support for Testnet 3 already exists.
>=20
> Simply by adding the network parameters for Testnet 4 (magic number, etc.=
), a client can connect to=20
> and use Testnet 4 without further modifications. The block headers have v=
alid proof of work, so=20
> clients can trivially check that blocks are "probably" valid.
>=20
> However, without the implementation of the changes detailed in Specificat=
ions, a client could follow=20
> a chain that does not follow the rules. Any fully validating node should =
check these rules and=20
> reject blocks that fail to follow them. Clients should either validate th=
ese rules or connect to=20
> trusted peers that do full validation.
>=20
> =3D=3D Reference implementation =3D=3D
>=20
> Pull request at https://github.com/bitcoin/bitcoin/pull/29775=20
> <https://github.com/bitcoin/bitcoin/pull/29775>
>=20
> =3D=3D References =3D=3D
>=20
> # Original mailing list thread: https://groups.google.com/g/bitcoindev/c/=
9bL00vRj7OU/m/kFPaQCzmBwAJ=20
> <https://groups.google.com/g/bitcoindev/c/9bL00vRj7OU/m/kFPaQCzmBwAJ>
> # Blog post on block storm bug: https://blog.lopp.net/the-block-storms-of=
-bitcoins-testnet/=20
> <https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/>
> # Consensus Cleanup BIP draft:=20
> https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediaw=
iki=20
> <https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.media=
wiki>
> # Consensus Cleanup PR draft: https://github.com/bitcoin/bitcoin/pull/154=
82=20
> <https://github.com/bitcoin/bitcoin/pull/15482>
>=20
> =3D=3D Copyright =3D=3D
>=20
> This document is licensed under the Creative Commons CC0 1.0 Universal li=
cense.
>=20
> --=20
> You received this message because you are subscribed to the Google Groups=
 "Bitcoin Development=20
> Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to=20
> bitcoindev+unsubscribe@googlegroups.com <mailto:bitcoindev+unsubscribe@go=
oglegroups.com>.
> To view this discussion on the web visit=20
> https://groups.google.com/d/msgid/bitcoindev/a6e3VPsXJf9p3gt_FmNF_Up-wrFu=
NMKTN30-xCSDHBKXzXnSpVflIZIj2NQ8Wos4PhQCzI2mWEMvIms_FAEs7rQdL15MpC_Phmu_fnR=
9iTg%3D%40protonmail.com <https://groups.google.com/d/msgid/bitcoindev/a6e3=
VPsXJf9p3gt_FmNF_Up-wrFuNMKTN30-xCSDHBKXzXnSpVflIZIj2NQ8Wos4PhQCzI2mWEMvIms=
_FAEs7rQdL15MpC_Phmu_fnR9iTg%3D%40protonmail.com?utm_medium=3Demail&utm_sou=
rce=3Dfooter>.

--=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/d40a0279-6a5f-4748-ae80-6b9f05e40881%40mattcorallo.com.