From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Antoine Poinsot <darosior@protonmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Unbreaking testnet4
Date: Mon, 7 Sep 2026 16:44:19 +0200 [thread overview]
Message-ID: <CAKaEYh+d3vpzZ85YVrasPt4QunGeNpd8nequ-DRd8d5m2ShTJg@mail.gmail.com> (raw)
In-Reply-To: <hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 6212 bytes --]
On Tue, Mar 18, 2025 at 10:24 PM 'Antoine Poinsot' via Bitcoin Development
Mailing List <bitcoindev@googlegroups.com> wrote:
> Hi,
>
> Testnet4 was rolled out a year ago to address the shortcomings of
> testnet3. One of those shortcomings was the difficulty reset creating
> havoc. [0] In spite of this a similar rule was adopted for testnet4. [1] As
> a result, testnet4 is similarly creating havoc. [2]
>
> The goal of testnet is to mimic the Bitcoin mainnet. This is why it is
> useful to have in addition to a more control testing environment such as
> Signet.
>
> The given rationale for a difficulty reset was to let developers
> occasionally mine blocks on their laptop. But you cannot have your cake and
> eat it too: either the network is permissionless (PoW) or you assign
> identities and privileges to some (Signet). By trying to do both at the
> same time testnet4 created a loophole for abuse. As a result it failed on
> both count: it neither mimics mainnet nor allows developers to mine active
> blocks on their laptop.
>
> I propose to fix this by removing the difficulty reset rule from testnet4
> through a flag day hard fork on 2026-01-01. I picked a date well in the
> future to minimize disruption. This leaves enough time for a patch to be
> reviewed, merged, included in the next major Bitcoin Core release,
> backported to previous releases and adopted by the infrastructure running
> on testnet4. That should be enough for a test network.
>
> Let me know what you think,
> Antoine
>
Coming back to this thread because there is a small, targeted fix within
testnet4 itself, and I think the mechanism is worth stating plainly.
Testnet4 has two interacting time windows:
a) the difficulty exception, relative to the parent: a min-difficulty block
is allowed once its timestamp is more than 20 minutes past the parent's
(pow.cpp, nPowTargetSpacing * 2);
b) the future limit, relative to the clock: a header is rejected if its
timestamp is more than 2 hours ahead of the node's time (chain.h,
MAX_FUTURE_BLOCK_TIME, global to every chain).
(a) was added for testnet. (b) was inherited from mainnet, where there is
no (a). The second allows the first to be chained: a miner stamps the
parent plus 20 minutes, then that plus 20 minutes, and so on until the
clock limit stops them. With the parent near wall time, two hours over
twenty minutes is why the spoofed blocks Sjors described arrive in bursts
of five or six and then stop until real time catches up.
So the minimal fix is to reduce the wall-clock allowance to one exception
interval. There are two obvious ways to align the scales:
* Raise the exception to 2 hours: one min-difficulty block per two hours of
silence. That is close to no exception at all, and throws away the one
thing the exception is for.
* Lower the future limit to 20 minutes on testnet4: when the parent is near
wall time, a min-difficulty block can be at most one window ahead of the
clock, and the current five-or-six-block bursts collapse to one block ahead.
The second is the one to pick. Its exact scope: the room for a burst is
(now + future_limit - parent_time) / 20 min
so after a long period without blocks a burst is still possible, because
the exception is parent-relative rather than clock-relative. What the
change removes is the steady-state case, several blocks ahead from a parent
near wall time, which is the behaviour this thread is about. It does not
prevent competing one-block forks at minimum difficulty, and a miner can
still produce a min-difficulty block every 20 minutes of real time. It
keeps CPU-mineable blocks.
Mechanically it means making MAX_FUTURE_BLOCK_TIME a chain parameter and
setting it to 20 minutes for testnet4; mainnet and signet keep two hours.
It tightens acceptance in the soft-fork direction: at any given node time,
an upgraded node accepts a subset of the headers an old node accepts.
Unlike an ordinary consensus soft fork the rule is wall-clock-dependent: a
header rejected as too far in the future becomes acceptable as time catches
up.
The failure mode is an un-upgraded miner stamping more than 20 minutes
ahead and producing headers upgraded nodes do not yet accept. Such a branch
carries negligible chainwork and should be reorganised away once hash rate
on the compatible branch passes it, but pools should upgrade together. A
20-minute clock tolerance is ample for a testnet; the two-hour figure dates
from early Bitcoin and mainnet has no reason to touch it.
In one line: testnet4's 20-minute parent-relative exception can currently
be chained through a two-hour wall-clock allowance. Reducing that allowance
to one interval removes the five-or-six-block steady-state bursts while
preserving the exception itself.
Melvin
>
> [0]
> https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw@mail.gmail.com
> [1]
> https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki#rule-specification
> [2] https://fork.observer - pick the network on the top right corner
>
> --
> 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/hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU%3D%40protonmail.com
> <https://groups.google.com/d/msgid/bitcoindev/hU75DurC5XToqizyA-vOKmVtmzd3uZGDKOyXuE_ogE6eQ8tPCrvX__S08fG_nrW5CjH6IUx7EPrq8KwM5KFy9ltbFBJZQCHR2ThoimRbMqU%3D%40protonmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAKaEYh%2Bd3vpzZ85YVrasPt4QunGeNpd8nequ-DRd8d5m2ShTJg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 8020 bytes --]
prev parent reply other threads:[~2026-09-07 15:45 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 14:29 [bitcoindev] Unbreaking testnet4 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-18 21:34 ` Melvin Carvalho
2025-03-19 7:01 ` [bitcoindev] " Garlo Nicon
2025-03-19 7:56 ` [bitcoindev] " Sjors Provoost
2025-03-19 8:43 ` Garlo Nicon
2025-03-19 8:32 ` Sjors Provoost
2025-03-19 9:11 ` Melvin Carvalho
2025-03-19 17:03 ` bitcoin-dev-ml.void867 via Bitcoin Development Mailing List
2025-03-20 18:58 ` Melvin Carvalho
2025-03-21 21:20 ` Murch
2025-03-24 7:00 ` Garlo Nicon
2025-03-31 7:32 ` Saint Wenhao
2025-03-24 12:25 ` Murch
2025-03-24 13:57 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-27 11:44 ` Saint Wenhao
2025-04-27 22:49 ` Jameson Lopp
2025-04-28 6:11 ` Saint Wenhao
2025-04-28 10:45 ` Jameson Lopp
2025-04-28 11:59 ` 'emsit' via Bitcoin Development Mailing List
2025-04-28 12:47 ` Sjors Provoost
2025-04-28 13:33 ` Saint Wenhao
2025-04-28 18:15 ` Saint Wenhao
2025-04-28 18:50 ` Sjors Provoost
[not found] ` <20250428110655.D4A1C7C0AE9@smtp.postman.i2p>
2025-04-28 11:48 ` pithosian
2025-12-25 7:21 ` Saint Wenhao
2025-05-05 22:25 ` [bitcoindev] " Greg Maxwell
2025-05-06 11:48 ` Saint Wenhao
2025-05-09 13:07 ` Garlo Nicon
2025-05-12 5:21 ` Anthony Towns
2025-05-17 5:11 ` Saint Wenhao
2025-07-05 4:31 ` Garlo Nicon
[not found] ` <20250512110323.B14F27C0B49@smtp.postman.i2p>
2025-05-12 12:05 ` pithosian
2025-05-12 18:17 ` Saint Wenhao
[not found] ` <20250512181809.5705B7C114F@smtp.postman.i2p>
2025-05-12 20:19 ` pithosian
2026-09-07 14:44 ` Melvin Carvalho [this message]
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=CAKaEYh+d3vpzZ85YVrasPt4QunGeNpd8nequ-DRd8d5m2ShTJg@mail.gmail.com \
--to=melvincarvalho@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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