From: Garlo Nicon <garlonicon@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Unbreaking testnet4
Date: Wed, 19 Mar 2025 01:43:16 -0700 (PDT) [thread overview]
Message-ID: <66e51750-56d3-4fc7-b55b-eb838c07adb4n@googlegroups.com> (raw)
In-Reply-To: <688E575D-C370-4D7D-A6DB-11E0B56710B1@sprovoost.nl>
[-- Attachment #1.1: Type: text/plain, Size: 3474 bytes --]
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 <garlo...@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/66e51750-56d3-4fc7-b55b-eb838c07adb4n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4198 bytes --]
next prev parent reply other threads:[~2025-03-19 9:04 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 ` [bitcoindev] " Sjors Provoost
2025-03-19 8:43 ` Garlo Nicon [this message]
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=66e51750-56d3-4fc7-b55b-eb838c07adb4n@googlegroups.com \
--to=garlonicon@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.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