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