igneum-network/igneum
1
0
Fork 0
Code Issues Pull requests Releases Activity

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

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-josh 2026-10-07 15:07:25 +01:00
parent dbe9de0978
commit c2203b555a
1 changed files with 21 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
docs/analysis/attack-pass-2026-10.md
View file

@ -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.