ADR-012 — No timewarp rule; pin nMinimumChainWork, assumevalid and checkpoints

• Status: Accepted
• Date: 2026-10-09
• Related: ADR-010 (2-minute blocks, 60-block retarget), bug-bounty 2026-10-09

findings #4 (timewarp) and #6 (no minimum chain work), infra audit 2026-10-09 (C1, M1).

Context

Bug-bounty finding #4 proposed a Bitcoin "consensus-cleanup" style timewarp rule: the first block of each difficulty period may not be timestamped more than 600 s before the last block of the previous period, activating at mainnet height 20000. A draft was written into the core tree. The infra audit (C1) reviewed it against the actual retarget code and found it to be a no-op that also schedules a hard fork.

Analysis

The classic Bitcoin timewarp exists because Bitcoin's retarget window is off by one: it measures the time between block H-2016 and block H-1, so consecutive windows do not share an endpoint. A majority miner can push the last block of a period far into the future and start the next period in the past; the gap between periods is never measured, so the error accumulates without bound and difficulty collapses.

MoonBite inherits Litecoin's fix (src/pow.cpp, "Code courtesy of Art Forz"): after the first retarget the window goes back the full period — DifficultyAdjustmentInterval() = 60 blocks — so period *k* is measured from block H-61 to H-1, and period *k+1* from H-1 to H+59. Consecutive windows share their endpoint. Consequences:

• The measured timespans telescope: the sum of all window timespans equals

the time between the first and the last sampled block. A timestamp pushed backward at one boundary shortens the next window by exactly as much as it lengthened the previous one. There is no un-measured gap to exploit.

• Each window's adjustment is clamped to 4× / 0.25× (Bitcoin/Litecoin rule),

and the median-time-past rule plus the 2-hour future-time bound limit how far any single timestamp can be moved. The residual attacker freedom is a transient easing of at most about 2× in one window, which is paid back in the next window. The "33× faster collapse" claimed in bounty #4 does not hold under a full-period window.

• The draft rule constrained block H % 60 == 0, which is not a window

endpoint in this retarget (the endpoints are H-61 and H-1 relative to the block being mined). It therefore removed zero attacker freedom.

• Worse, an honest miner with roughly +1 h of clock skew followed by an honest

block with a correct clock would trip the 600 s rule at a period boundary, splitting upgraded from non-upgraded nodes. Activating it at height 20000 would have been a scheduled hard fork with no security benefit.

Decision

1. No timewarp rule is added. The validation.cpp rule, the Consensus::Params::nTimeWarpFixHeight field and all chainparams settings for it are dropped. The retarget stays exactly as ADR-010 defines it. 2. Pin a minimum chain work, an assumevalid block and buried checkpoints (bounty #6 / audit M1). Previously all three were zero / genesis-only, so a fresh node would accept and RandomX-verify arbitrarily long floor-difficulty header chains from any peer. Values were read from a live seed via read-only RPC on 2026-10-09 (tip 12656):

Parameter	Value
nMinimumChainWork	0x…aa9c1b51 (chainwork at height 12000)
defaultAssumeValid	b0b48cbf1cf1666c861c359a1b7abe72f141e794662c6f8dc72261596c58d82e (height 12500)
checkpoints	{12000, 67b4f7d0af4fa721a4a9f00d09838d4324dd598d930a25c22480b67459d76b14}, {12500, b0b48cbf…}

Both heights are below the deepest observed live fork point (12579), so no honest node can be stalled by them. These values are policy, not consensus: a node that lacks them still follows the same chain, it just does more work to reject junk during initial sync.

Consequences

• No hard fork is scheduled. Nodes on the previous release remain fully

compatible with this one.

• Every release should re-bump nMinimumChainWork / defaultAssumeValid /

checkpoints to a recent buried height, as Bitcoin and Litecoin do.

• If the retarget is ever changed to a non-overlapping window, this analysis

must be redone and a real timewarp rule (constraining the actual window endpoints) considered at that time.