From 140ce00171665b3f1bd777952d9c418143ed3d40 Mon Sep 17 00:00:00 2001 From: igneum-labs <337424239+igneum-labs@users.noreply.github.com> Date: Wed, 7 Oct 2026 14:07:25 +0000 Subject: [PATCH] attack-pass: AP-F8-3, the acceptance rule never executed the shadow block (the root of the residual classes), found by the hash lane; fixed in sub-version 3 Co-Authored-By: Claude Fable 5.1 --- docs/analysis/attack-pass-2026-10.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/docs/analysis/attack-pass-2026-10.md b/docs/analysis/attack-pass-2026-10.md index 00d205f9f..6bd39c8ee 100644 --- a/docs/analysis/attack-pass-2026-10.md +++ b/docs/analysis/attack-pass-2026-10.md @@ -472,5 +472,26 @@ evidence is the first run's 331,672 seeds with one exhaustion. Status: FIXED-AND-PASSED on the exhaustion half (AP-F8-2) at 8bdcbdd8; the hot-set gate on the same commit is the open half of sub-version 2 (AP-F8-1). +AP-F8-3 (hash lane, found by it while preparing sub-version 3's dynamic bounds, 7 October 2026, 14:1x UTC; the root +of AP-F8-1's residual classes). `accept.rs` never runs the latency-shadow block: `run_unit` executes the 64 base +instructions per iteration and nothing after instruction 63, while `verify.rs` and every kernel run the shadow 27 +times at the end of each iteration. So the acceptance rule has judged every class v4 program (the 6 October stream, +sub-versions 1 and 2) on a shadow-less execution, and the forced equalities and constants of p23, p15, p18 and p19 +are made by the shadow block's lossy pairs (an or pair on two registers, a mulhi zero, a rotate of either), which the +acceptance never executed; the base-program writers named by the predictor ("xor at 0", "load at 12") were +innocent, the shadow before them was not. Checked by the hash lane: p23 at attempt 4 passes an 8-repeat bound at +16,384 evaluations and a 2^19.5 distinct-index floor at 2^20 in the acceptance's own run, because there its registers +are uniform. Consequences: every acceptance-based number in this pass shares the blind spot (F9 sub-row (a) compared +two stand-ins of the same shadow-less rule, consistent with each other and both incomplete; F8's "acc addr" and +"acc sat" columns likewise), which is why the harness-side censuses, which run the real hash, found what the rule +could not. Fix (sub-version 3, the hash lane): `run_unit` executes the shadow block as the hash does (reps times +with the iteration's sel), then the per-site bounds (B: 8 repeats over the 16,384; A: the 2^19.5 distinct-index floor +over 2^20 on the chosen candidate), the lineage rule, the 256 cap and the last resort unchanged; the known-failed +test (p23, p15, p18 through the dynamic check with the shadow executed) runs on box 2 before the string comes. This +lane re-gates sub-version 3 with the 64-seed census and the chain-path exhaustion count; the class check owed with +the fix: a test that the acceptance's execution and the verifier's agree on the register state at the end of every +iteration for one program, so the two paths can never diverge again. +Status: FINDING-OPEN; closes with sub-version 3's re-gate. + Any further finding is logged here and in `docs/fud-ledger.md` with its owning lane (hash and algorithm: fixed in `igneum-pow` behind a test and re-gated; node: the node lane, relay agent) before the row is marked FIXED-AND-PASSED.