Delivery-date: Wed, 19 Mar 2025 02:04:42 -0700
Sender: bitcoindev@googlegroups.com
Date: Wed, 19 Mar 2025 01:43:16 -0700 (PDT)
From: Garlo Nicon <garlonicon@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <66e51750-56d3-4fc7-b55b-eb838c07adb4n@googlegroups.com>
In-Reply-To: <688E575D-C370-4D7D-A6DB-11E0B56710B1@sprovoost.nl>
References: <hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU=@protonmail.com>
 <f0cace2b-d734-4b36-b8a1-d4364a573a19n@googlegroups.com>
 <688E575D-C370-4D7D-A6DB-11E0B56710B1@sprovoost.nl>
Subject: Re: [bitcoindev] Unbreaking testnet4
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_113040_143961308.1742373796070"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_113040_143961308.1742373796070
Content-Type: multipart/alternative; 
	boundary="----=_Part_113041_938972227.1742373796070"

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

It seems you are right. However, this rule is based on block timestamps,=20
which gives me another idea: what about simply invalidating a block, if the=
=20
block time difference is bigger than 20 minutes? Because that's what ASIC=
=20
miners would want to do anyway, to reorg a long chain of CPU-mined blocks:=
=20
if the difficulty is 12345678, and you can see hundreds of blocks with=20
difficulty 1, then a single block with difficulty 12345678 will reorg all=
=20
of these CPU-mined blocks in a single shot.

By the way: if we are entering a hard-fork territory, and if testnet4 coins=
=20
are traded, then what about switching to testnet5 with new rules instead?

And also, in case of any forks, there is a question, how many miners will=
=20
actually support new changes. Because in case of new timewarp rules, we saw=
=20
hundreds of blocks being reorged, because some ASIC miners didn't upgrade=
=20
their code: https://github.com/bitcoin/bitcoin/issues/30786

And even when mempool.space upgraded their code, a few weeks after that, I=
=20
could still see some ASIC nodes in the wild, which were mining on the wrong=
=20
branch, and with just a CPU, it was possible to fork them once every 2016=
=20
blocks, for a few hundred blocks.

=C5=9Broda, 19 marca 2025 o 08:59:26 UTC+1 Sjors Provoost napisa=C5=82(a):

>
>
> > Op 19 mrt 2025, om 08:01 heeft Garlo Nicon <garlo...@gmail.com> het=20
> volgende geschreven:
> >=20
> > > I propose to fix this by removing the difficulty reset rule from=20
> testnet4 through a flag day hard fork on 2026-01-01.
> >=20
> > 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.
>
> Unfortunately it's a hard-fork.
>
> > So, I assume if you change "fPowAllowMinDifficultyBlocks" from "true" t=
o=20
> "false", when block time will be greater than unix time "1767225600", the=
n=20
> you will get a valid soft-fork.
>
>
> The fPowAllowMinDifficultyBlocks rule says that after 20 minutes the new=
=20
> block MUST have difficulty 1. A block with the real difficulty will be=20
> rejected.
>
> This is because in general the block nBits value, which announces how muc=
h=20
> work the block has, must have an exact value. It can't be higher.
>
> In validation.cpp we have this:
>
> if (block.nBits !=3D GetNextWorkRequired(pindexPrev, &block,=20
> consensusParams))
> return state.Invalid(BlockValidationResult::BLOCK_INVALID_HEADER,=20
> "bad-diffbits", "incorrect proof of work");
>
> Inside GetNextWorkRequired there is the testnet exception rule, which=20
> Antoine proposes to drop:
>
> if (params.fPowAllowMinDifficultyBlocks) {
> // Special difficulty rule for testnet:
> // If the new block's timestamp is more than 2* 10 minutes
> // then allow mining of a min-difficulty block.
> if (pblock->GetBlockTime() > pindexLast->GetBlockTime() +=20
> params.nPowTargetSpacing*2)
> return nProofOfWorkLimit;
> else
> ... (same difficulty as last block, unless it's a retarget)
>
> The code comment is misleading, "allow" should be "require".
>
> - Sjors

--=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/=
66e51750-56d3-4fc7-b55b-eb838c07adb4n%40googlegroups.com.

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

It seems you are right. However, this rule is based on block timestamps, wh=
ich gives me another idea: what about simply invalidating a block, if the b=
lock time difference is bigger than 20 minutes? Because that's what ASIC mi=
ners would want to do anyway, to reorg a long chain of CPU-mined blocks: if=
 the difficulty is 12345678, and you can see hundreds of blocks with diffic=
ulty 1, then a single block with difficulty 12345678 will reorg all of thes=
e CPU-mined blocks in a single shot.<br /><br />By the way: if we are enter=
ing a hard-fork territory, and if testnet4 coins are traded, then what abou=
t switching to testnet5 with new rules instead?<br /><br />And also, in cas=
e of any forks, there is a question, how many miners will actually support =
new changes. Because in case of new timewarp rules, we saw hundreds of bloc=
ks being reorged, because some ASIC miners didn't upgrade their code: https=
://github.com/bitcoin/bitcoin/issues/30786<br /><br />And even when mempool=
.space upgraded their code, a few weeks after that, I could still see some =
ASIC nodes in the wild, which were mining on the wrong branch, and with jus=
t a CPU, it was possible to fork them once every 2016 blocks, for a few hun=
dred blocks.<br /><br /><div class=3D"gmail_quote"><div dir=3D"auto" class=
=3D"gmail_attr">=C5=9Broda, 19 marca 2025 o=C2=A008:59:26 UTC+1 Sjors Provo=
ost napisa=C5=82(a):<br/></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left=
: 1ex;">
<br>
<br>&gt; Op 19 mrt 2025, om 08:01 heeft Garlo Nicon &lt;<a href data-email-=
masked rel=3D"nofollow">garlo...@gmail.com</a>&gt; het volgende geschreven:
<br>&gt;=20
<br>&gt; &gt; I propose to fix this by removing the difficulty reset rule f=
rom testnet4 through a flag day hard fork on 2026-01-01.
<br>&gt;=20
<br>&gt; You can do that in a soft-fork way. Just rejecting blocks with dif=
ficulty=3D1, and requiring always a block with the true network difficulty,=
 is a valid soft-fork.
<br>
<br>Unfortunately it&#39;s a hard-fork.
<br>
<br>&gt; So, I assume if you change &quot;fPowAllowMinDifficultyBlocks&quot=
; from &quot;true&quot; to &quot;false&quot;, when block time will be great=
er than unix time &quot;1767225600&quot;, then you will get a valid soft-fo=
rk.
<br>
<br>
<br>The fPowAllowMinDifficultyBlocks rule says that after 20 minutes the ne=
w block MUST have difficulty 1.  A block with the real difficulty will be r=
ejected.
<br>
<br>This is because in general the block nBits value, which announces how m=
uch work the block has, must have an exact value. It can&#39;t be higher.
<br>
<br>In validation.cpp we have this:
<br>
<br>if (block.nBits !=3D GetNextWorkRequired(pindexPrev, &amp;block, consen=
susParams))
<br>    return state.Invalid(BlockValidationResult::BLOCK_INVALID_HEADER, &=
quot;bad-diffbits&quot;, &quot;incorrect proof of work&quot;);
<br>
<br>Inside GetNextWorkRequired there is the testnet exception rule, which A=
ntoine proposes to drop:
<br>
<br> if (params.fPowAllowMinDifficultyBlocks) {
<br>    // Special difficulty rule for testnet:
<br>    // If the new block&#39;s timestamp is more than 2* 10 minutes
<br>    // then allow mining of a min-difficulty block.
<br>    if (pblock-&gt;GetBlockTime() &gt; pindexLast-&gt;GetBlockTime() + =
params.nPowTargetSpacing*2)
<br>        return nProofOfWorkLimit;
<br>    else
<br>       ... (same difficulty as last block, unless it&#39;s a retarget)
<br>
<br>The code comment is misleading, &quot;allow&quot; should be &quot;requi=
re&quot;.
<br>
<br>- Sjors</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/66e51750-56d3-4fc7-b55b-eb838c07adb4n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/66e51750-56d3-4fc7-b55b-eb838c07adb4n%40googlegroups.com</a>.<br />

------=_Part_113041_938972227.1742373796070--

------=_Part_113040_143961308.1742373796070--