public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Sjors Provoost <sjors@sprovoost•nl>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Cc: Garlo Nicon <garlonicon@gmail•com>
Subject: Re: [bitcoindev] Unbreaking testnet4
Date: Wed, 19 Mar 2025 08:56:52 +0100	[thread overview]
Message-ID: <688E575D-C370-4D7D-A6DB-11E0B56710B1@sprovoost.nl> (raw)
In-Reply-To: <f0cace2b-d734-4b36-b8a1-d4364a573a19n@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.


  reply	other threads:[~2025-03-19  7:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-18 14:29 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-19  7:01 ` [bitcoindev] " Garlo Nicon
2025-03-19  7:56   ` Sjors Provoost [this message]
2025-03-19  8:43     ` [bitcoindev] " Garlo Nicon
2025-03-19  8:32 ` Sjors Provoost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=688E575D-C370-4D7D-A6DB-11E0B56710B1@sprovoost.nl \
    --to=sjors@sprovoost$(echo .)nl \
    --cc=bitcoindev@googlegroups.com \
    --cc=garlonicon@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox