Delivery-date: Wed, 19 Mar 2025 00:12:58 -0700
Sender: bitcoindev@googlegroups.com
Date: Wed, 19 Mar 2025 00:01:46 -0700 (PDT)
From: Garlo Nicon <garlonicon@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <f0cace2b-d734-4b36-b8a1-d4364a573a19n@googlegroups.com>
In-Reply-To: <hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU=@protonmail.com>
References: <hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU=@protonmail.com>
Subject: [bitcoindev] Re: Unbreaking testnet4
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_50858_1398682099.1742367706044"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_50858_1398682099.1742367706044
Content-Type: multipart/alternative; 
	boundary="----=_Part_50859_955274755.1742367706044"

------=_Part_50859_955274755.1742367706044
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> I propose to fix this by removing the difficulty reset rule from testnet4=
=20
through a flag day hard fork on 2026-01-01.

You can do that in a soft-fork way. Just rejecting blocks with=20
difficulty=3D1, and requiring always a block with the true network=20
difficulty, is a valid soft-fork.

To better see that, you can imagine, what would happen, if someone would=20
apply difficulty adjustment rule on mainnet. Then, it would be possible to=
=20
temporarily mine a block on a CPU, see it confirmed by your node (and=20
rejected by the rest of the network), and then, when the next real block=20
would appear, your client would automatically switch to a stronger chain=20
(and then, those CPU-mined blocks would be truly worthless).

So, I assume if you change "fPowAllowMinDifficultyBlocks" from "true" to=20
"false", when block time will be greater than unix time "1767225600", then=
=20
you will get a valid soft-fork. Non-upgraded clients could then still see=
=20
some CPU-mined blocks, but they will disappear, if the hashrate majority=20
will support your changes, and then old clients will automatically follow=
=20
your chain. Also note that a single ASIC block can reorg a lot of CPU-mined=
=20
blocks, so it is always guaranteed, that this change will be=20
chainwork-compatible.

wtorek, 18 marca 2025 o 22:24:49 UTC+1 Antoine Poinsot napisa=C5=82(a):

> Hi,
>
> Testnet4 was rolled out a year ago to address the shortcomings of=20
> testnet3. One of those shortcomings was the difficulty reset creating=20
> havoc. [0] In spite of this a similar rule was adopted for testnet4. [1] =
As=20
> a result, testnet4 is similarly creating havoc. [2]
>
> The goal of testnet is to mimic the Bitcoin mainnet. This is why it is=20
> useful to have in addition to a more control testing environment such as=
=20
> Signet.
>
> The given rationale for a difficulty reset was to let developers=20
> occasionally mine blocks on their laptop. But you cannot have your cake a=
nd=20
> eat it too: either the network is permissionless (PoW) or you assign=20
> identities and privileges to some (Signet). By trying to do both at the=
=20
> same time testnet4 created a loophole for abuse. As a result it failed on=
=20
> both count: it neither mimics mainnet nor allows developers to mine activ=
e=20
> blocks on their laptop.
>
> I propose to fix this by removing the difficulty reset rule from testnet4=
=20
> through a flag day hard fork on 2026-01-01. I picked a date well in the=
=20
> future to minimize disruption. This leaves enough time for a patch to be=
=20
> reviewed, merged, included in the next major Bitcoin Core release,=20
> backported to previous releases and adopted by the infrastructure running=
=20
> on testnet4. That should be enough for a test network.
>
> Let me know what you think,
> Antoine
>
> [0]=20
> https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vP...@mail.gmail.=
com=20
> <https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64N=
SNPH-3fDCUfw@mail.gmail.com>
> [1]=20
> https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki#rule-speci=
fication
> [2] https://fork.observer - pick the network on the top right corner
>

--=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 visit https://groups.google.com/d/msgid/bitcoindev/=
f0cace2b-d734-4b36-b8a1-d4364a573a19n%40googlegroups.com.

------=_Part_50859_955274755.1742367706044
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

&gt; I propose to fix this by removing the difficulty reset rule from testn=
et4 through a flag day hard fork on 2026-01-01.<br /><br />You can do that =
in a soft-fork way. Just rejecting blocks with difficulty=3D1, and requirin=
g always a block with the true network difficulty, is a valid soft-fork.<br=
 /><br />To better see that, you can imagine, what would happen, if someone=
 would apply difficulty adjustment rule on mainnet. Then, it would be possi=
ble to temporarily mine a block on a CPU, see it confirmed by your node (an=
d rejected by the rest of the network), and then, when the next real block =
would appear, your client would automatically switch to a stronger chain (a=
nd then, those CPU-mined blocks would be truly worthless).<br /><br />So, I=
 assume if you change "fPowAllowMinDifficultyBlocks" from "true" to "false"=
, when block time will be greater than unix time "1767225600", then you wil=
l get a valid soft-fork. Non-upgraded clients could then still see some CPU=
-mined blocks, but they will disappear, if the hashrate majority will suppo=
rt your changes, and then old clients will automatically follow your chain.=
 Also note that a single ASIC block can reorg a lot of CPU-mined blocks, so=
 it is always guaranteed, that this change will be chainwork-compatible.<br=
 /><br /><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">=
wtorek, 18 marca 2025 o=C2=A022:24:49 UTC+1 Antoine Poinsot napisa=C5=82(a)=
:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex;=
 border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style=
=3D"font-family:Arial,sans-serif;font-size:14px"><div style=3D"font-family:=
Arial,sans-serif;font-size:14px"><div>Hi,<br><br>Testnet4
 was  rolled out a year ago to address the shortcomings of testnet3. One
 of those shortcomings was the difficulty reset creating havoc. [0] In=20
spite of this a similar rule was adopted for testnet4. [1] As a result,=20
testnet4 is similarly creating havoc. [2]<br><br>The goal of testnet is=20
to mimic the Bitcoin mainnet. This is why it is useful to have in=20
addition to a more control testing environment such as Signet.<br><br>The
 given rationale for a difficulty reset was to let developers=20
occasionally mine blocks on their laptop. But you cannot have your cake=20
and eat it too: either the network is permissionless (PoW) or you assign
 identities and privileges to some (Signet). By trying to do both at the
 same time testnet4 created a loophole for abuse. As a result it failed=20
on both count: it neither mimics mainnet nor allows developers to mine=20
active blocks on their laptop.<br><br>I propose to fix this by removing=20
the difficulty reset rule from testnet4 through a flag day hard fork on=20
2026-01-01. I picked a date well in the future to minimize disruption.=20
This leaves enough time for a patch to be reviewed, merged, included in=20
the next major Bitcoin Core release, backported to previous releases and
 adopted by the infrastructure running on testnet4. That should be=20
enough for a test network.<br></div><div><br>Let me know what you think,<br=
>Antoine<br><br>[0] <span><a href=3D"https://gnusha.org/pi/bitcoindev/CADL_=
X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com" rel=3D"noref=
errer nofollow noopener" target=3D"_blank" data-saferedirecturl=3D"https://=
www.google.com/url?hl=3Dpl&amp;q=3Dhttps://gnusha.org/pi/bitcoindev/CADL_X_=
eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com&amp;source=3Dgm=
ail&amp;ust=3D1742453976191000&amp;usg=3DAOvVaw2KRR5rLc4XGN5XbfLVsJtJ">http=
s://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vP...@mail.gmail.com</a=
></span><br>[1] <span><a href=3D"https://github.com/bitcoin/bips/blob/maste=
r/bip-0094.mediawiki#rule-specification" rel=3D"noreferrer nofollow noopene=
r" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=
=3Dpl&amp;q=3Dhttps://github.com/bitcoin/bips/blob/master/bip-0094.mediawik=
i%23rule-specification&amp;source=3Dgmail&amp;ust=3D1742453976191000&amp;us=
g=3DAOvVaw24C2ZYjr5v1sroxqiDiX9X">https://github.com/bitcoin/bips/blob/mast=
er/bip-0094.mediawiki#rule-specification</a></span><br>[2] <span><a href=3D=
"https://fork.observer/" rel=3D"noreferrer nofollow noopener" target=3D"_bl=
ank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dpl&amp;q=3Dhtt=
ps://fork.observer/&amp;source=3Dgmail&amp;ust=3D1742453976191000&amp;usg=
=3DAOvVaw3-KWmnANv6EJ8q2rnLHyJh">https://fork.observer</a> - pick the netwo=
rk on the top right corner</span></div></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
    <div>
       =20
            </div>
   =20
            <div>
       =20
            </div>
</div>
</div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/f0cace2b-d734-4b36-b8a1-d4364a573a19n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/f0cace2b-d734-4b36-b8a1-d4364a573a19n%40googlegroups.com</a>.<br />

------=_Part_50859_955274755.1742367706044--

------=_Part_50858_1398682099.1742367706044--