Subject: Re: [bitcoindev] Unbreaking testnet4

From: Garlo Nicon <[email-masked]>
Date: Wed, 19 Mar 2025 01:43:16 -0700 (PDT)

It seems you are right. However, this rule is based on block timestamps, 
which gives me another idea: what about simply invalidating a block, if the 
block time difference is bigger than 20 minutes? Because that's what ASIC 
miners 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 
difficulty 1, then a single block with difficulty 12345678 will reorg all 
of these CPU-mined blocks in a single shot.

By the way: if we are entering a hard-fork territory, and if testnet4 coins 
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 
actually support new changes. Because in case of new timewarp rules, we saw 
hundreds of blocks being reorged, because some ASIC miners didn't upgrade 
their code: https://github.com/bitcoin/bitcoin/issues/30786

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 just a CPU, it was possible to fork them once every 2016 
blocks, for a few hundred blocks.

środa, 19 marca 2025 o 08:59:26 UTC+1 Sjors Provoost napisał(a):

>
>
> > Op 19 mrt 2025, om 08:01 heeft Garlo Nicon <[email-masked]> het 
> volgende geschreven:
> > 
> > > I propose to fix this by removing the difficulty reset rule from 
> testnet4 through a flag day hard fork on 2026-01-01.
> > 
> > You can do that in a soft-fork way. Just rejecting blocks with 
> difficulty=1, and requiring always a block with the true network 
> difficulty, is a valid soft-fork.
>
> Unfortunately it's a hard-fork.
>
> > So, I assume if you change "fPowAllowMinDifficultyBlocks" from "true" to 
> "false", when block time will be greater than unix time "1767225600", then 
> you will get a valid soft-fork.
>
>
> The fPowAllowMinDifficultyBlocks rule says that after 20 minutes the new 
> block MUST have difficulty 1. A block with the real difficulty will be 
> rejected.
>
> This is because in general the block nBits value, which announces how much 
> work the block has, must have an exact value. It can't be higher.
>
> In validation.cpp we have this:
>
> if (block.nBits != GetNextWorkRequired(pindexPrev, &block, 
> consensusParams))
> return state.Invalid(BlockValidationResult::BLOCK_INVALID_HEADER, 
> "bad-diffbits", "incorrect proof of work");
>
> Inside GetNextWorkRequired there is the testnet exception rule, which 
> 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() + 
> 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

-- 
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 email to [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/66e51750-56d3-4fc7-b55b-eb838c07adb4n%40googlegroups.com.