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