S256 LWMA Fork Transition Rehearsal

Run 2026-09-02 · local, isolated regtest, realistic difficulty floor · scaled-down rehearsal of mainnet's real height-17,500 AuxPoW/LWMA hard fork

Why this test: S256 mainnet is currently at block ~16,883 — roughly 600 blocks (~8–9 days) away from its real AuxPoW+LWMA activation at height 17,500. This rehearsal exercises the exact same code path (chain identity, activation gating, and LwmaCalculateNextWorkRequired) on an isolated local chain, scaled down to a tractable size, with a realistic starting difficulty, to check the transition and LWMA's hashrate-adaptation behavior before it happens for real.

Scenario

Three simulated miners mine from genesis at a realistic starting difficulty (S256 testnet's own real, committed floor — 256× easier than difficulty-1, not an artificial regtest default). The classic-DAA-to-LWMA fork is scaled from mainnet's real height 17,500 down to height 96 — the smallest fork height at which LWMA's own N=96-block window has a full, real, pre-fork-timestamped history immediately available, exactly mirroring mainnet's actual situation. After the fork, miner count is varied to observe LWMA's reaction, with the recovery phase extended so the full round-trip is visible within LWMA's 96-block window:

Phase 1 · heights 1–95

Pre-fork

Classic DAA, on-target pace

Phase 2 · heights 96–155

3 miners

LWMA baseline, ~4% above target

Phase 3 · heights 156–205

2 miners

One miner drops out — genuinely below target

Phase 4 · heights 206–375

3 miners

Dropped miner returns

Result: difficulty over the full run

pre-fork (classic DAA) baseline (3 miners) drop (2 miners) recovery (3 miners)

Reading the result

Pre-fork (height 0–95): flat, then one small classic-DAA step at the height-72 interval boundary (1e00ffff → 1e00fc72, ~1.4% tighter) — a mild, on-target adjustment, exactly matching hand-calculated expectations for blocks arriving right on schedule.
Fork transition (height 96): clean, no crash, no stall, no consensus error. LWMA's own bootstrap guard (height < N) means the block at the activation height itself still uses the pre-fork floor, and real per-block computation starts one block later (97).
Baseline, 3 miners (97→155): gentle, steady tightening — the simulated pace (1150s) was only slightly faster than the 1200s target, so LWMA responds with a correspondingly gentle, proportional adjustment rather than a dramatic one.
Drop to 2 miners (156→~165): a clear, fast ease — blocks now genuinely arriving slower than target (1725s vs. 1200s), and LWMA drops difficulty all the way back to the chain's easiest floor within about 10 blocks.
Drop to 2 miners (~165→255): pinned at the floor for an extended stretch, including roughly the first 50 blocks after the 3rd miner already returned (height 206+). This is real LWMA inertia, not a bug: with the window mostly full of "slow" blocks, it takes a sustained run of "fast" ones before the weighted average tips back over.
Recovery, 3 miners (from ~height 275 onward): once enough fast blocks accumulate in the 96-block window, difficulty turns and tightens steadily and continuously through the end of the run — a clean, unambiguous recovery.

Bottom line: LWMA activates cleanly at the fork, eases quickly and decisively when hashrate drops, and recovers cleanly once enough evidence of the higher hashrate accumulates in its window — with a realistic, expected lag before that recovery becomes visible, not instability. 375 blocks, zero crashes, zero stalled/rejected blocks, zero consensus errors.

Methodology

Regtest, with a temporary consensus test-patch (fPowNoRetargeting=false; activation heights set to 96; powLimit set to S256 testnet's own real, already-committed value — 256× easier than difficulty-1, not regtest's own unrealistic default). setmocktime (regtest-only) gave each block a controlled, phase-appropriate timestamp, while every block's proof-of-work was still genuinely solved and validated through real RPC calls (generatetoaddress, real block acceptance, real LwmaCalculateNextWorkRequired execution) rather than a unit-test mock. The test-only patch is local to this rehearsal and is not part of any real chain's consensus rules.

Earlier attempts and what they found (click to expand)

Two issues turned up before this run, both worth keeping on record:

Real competitive CPU mining on testnet (first attempt): mining the pre-fork phase in ~4–5 real seconds/block instead of the real 1200s target made LWMA see an "impossibly fast" history the instant it activated, spiking required difficulty ~250× — correct LWMA behavior, but an artifact of compressing the test's own timeline, not reproducible on mainnet (whose real pre-fork blocks are already paced at ~20 minutes).
Regtest's own default powLimit (second attempt, the "spike" a reader spotted in the very first version of this report): regtest's real default is deliberately enormous, ~255 bits — essentially the ceiling of a 256-bit integer. At the one classic-DAA interval boundary the pre-fork phase crossed, the retarget formula's multiplication (oldTarget × actualTimespan) overflowed that fixed-width type and silently wrapped around, producing a difficulty spike of roughly 43,700× that had nothing to do with LWMA, S256, or the fork itself. Confirmed by calling the actual compiled retarget function directly with the exact recorded block times and reproducing the identical (wrapped) result. This run instead uses a realistic powLimit (~232 bits, S256 testnet's own value) with over 20 bits of headroom — comfortably safe, and the same margin any real chain has by design.

Checkpoints

Height	Phase	nBits	Relative difficulty
0	genesis	1e00ffff	3.906e-03
71	pre-fork	1e00ffff	3.906e-03
72	pre-fork	1e00fc72	3.961e-03
95	pre-fork	1e00fc72	3.961e-03
96	fork block	1e00ffff	3.906e-03
120	baseline (3)	1e00f9a0	4.006e-03
155	baseline (3)	1e00f1a3	4.138e-03
156	drop (2)	1e00f169	4.142e-03
165	drop (2)	1e00ffff	3.906e-03
205	drop (2)	1e00ffff	3.906e-03
206	recovery (3)	1e00ffff	3.906e-03
256	recovery (3)	1e00ffff	3.906e-03
296	recovery (3)	1e00f47d	4.090e-03
336	recovery (3)	1e00ee14	4.200e-03
375	recovery (3)	1e00e5ac	4.354e-03

"Relative difficulty" is expressed against real Bitcoin's difficulty-1 reference (nBits 1d00ffff = 1.0); the values here are all in the 256×-easier floor's own range, hence the small numbers throughout — only the trend across rows matters.

Related evidence

Separately, this build's daemon completed a full real sync of the live S256 mainnet chain (genesis through height 16,883, against real network peers) with zero errors, warnings, or reorgs — confirming the consensus code is sound on the real chain right up to (but not yet through) the real fork. This rehearsal is the complementary piece: what happens at and after the fork, which the real chain hasn't reached yet.