Delivery-date: Wed, 19 Mar 2025 00:59:32 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of sjors@sprovoost.nl designates 202.12.124.156 as permitted sender) client-ip=202.12.124.156;
Feedback-ID: ie5e042df:Fastmail
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
Subject: Re: [bitcoindev] Unbreaking testnet4
From: Sjors Provoost <sjors@sprovoost.nl>
In-Reply-To: <f0cace2b-d734-4b36-b8a1-d4364a573a19n@googlegroups.com>
Date: Wed, 19 Mar 2025 08:56:52 +0100
Cc: Garlo Nicon <garlonicon@gmail.com>
Message-Id: <688E575D-C370-4D7D-A6DB-11E0B56710B1@sprovoost.nl>
References: <hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU=@protonmail.com>
 <f0cace2b-d734-4b36-b8a1-d4364a573a19n@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


> Op 19 mrt 2025, om 08:01 heeft Garlo Nicon <garlonicon@gmail.com> 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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/688E575D-C370-4D7D-A6DB-11E0B56710B1%40sprovoost.nl.