igneum/docs/analysis/cryptanalysis/report-acceptance-rule.md
igneum-labs ce8759bcef adv-accept report: base rate over 29,032 accepted programs; partial live logs copied
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-10-07 19:46:58 +00:00

41 KiB

Report: adversarial pass on the program acceptance rule (class v4 sub-version 3)

internal adversarial pass, not an independent review

  • Target commit: 017e703764 (class v4 sub-version 3, object byte 7).
  • Crate built: igneum-pow at the frozen commit (this worktree's igneum-pow/ is reset to it; build/master diverged by 635 deletions and is not used). Harness: tools/attack/adv-accept (depends on igneum-pow by path).
  • Re-base (19:3x BST): build/master moved to 7a7caa34 whose igneum-pow IS the frozen object; merged at 8748e955ceb48be5a6cbf7f8718a4884d3de9828; git diff --quiet 017e7037 HEAD -- igneum-pow prints IDENTICAL. Nothing measured here was on a stale tree: igneum-pow/ had been reset to the frozen object before the first build.
  • Binary sha256 (first build, box 2): e3d35f4464937f91aac0648e2ee7134f33c85c7aa314b87b33f91059dedc6682 (adv-accept single-binary build); the two-binary build (adv-accept, adv-live = the unmodified f8 harness) sha256 is logged per box in the run sections below.
  • Boxes: igneum-build-1 (CPU-bound sweeps, by the coordinator's order) and igneum-build-2 (shard 0, already there). nice 10 on every idle core, the capacity layer's yield (run-box.sh). Logs under /srv/builds/igneum-wt-adv-accept/adv/ on each box (spared from the checkout clean by .igneum-scratch-spare; the first 10k log on box 2 was wiped by a rebuild before the spare existed and is void anyway: old labels, old binary).
  • Lane scope since 19:2x BST: THE BYPASS (Q1, Q2, Q5). Q3 is lane adv-accept-3's, Q4 lane adv-accept-2's.
  • Seed space: the attack-pass F8 label space (program k = seed_words("igneum-attack-f8/program/k"), era ".../era/k"), so adv-live warps --program k measures the live hot set of exactly the program the sweep reports.
  • rustc 1.99.0 both sides. First results by 8 October 2026 18:00 UTC. GPU: not available, so any per-card hash-rate confirmation of a gain is BLOCKED and said so.
  • Box-hours spent so far: about 0.1 (one 7 s build, three short runs). Budget 8.

Draw-path validation (must pass before any claim)

The shared devnet epoch-0 class v4 program drawn through Epoch::chain_program(ProgramClass::V4) has program id a785001687d8688a at attempt 1 (class mx8-erad810f22d+sh256x27), which matches the frozen pack proto-cuda/packs-ca3-v4/v4-devnet-epoch0/program.json and the brief. So my draw path is the chain's. Command: adv-accept derive-check on box 2. Devnet 3 epoch-0 (id fce15bf61030be57) derive check is owed once I copy its program.json read-only from build-1.

Status board

Q Method Known-failed shape (must fire) Gate Result Status
Q1 Steering/hot set: the chain's class v4 draw over the F8 label space (shards of 100k seeds; 19:27 BST to 19:4x BST under the SIGSTOP yield, since 19:4x BST nice 10 on cores 8-95, no yield), the stand-in per-site ratio at 256 units as the proxy, the live hot set by the unmodified f8 harness (adv-live) on the lowest-ratio seeds and on a consecutive-seed census adv-live const-item plant FLAGGED (21.8x, X_1% +6.49); clean control 0.9996x PASS X_f >= f flags a hot set; gain = implied on-die SRAM copy size 23,319 accepted programs drawn; seed 100767 flags the hot-set test at 2^24 nonces (X_0.1% +0.155%, 2.05x) under class v4 AND under class v5 with the state leaves (+0.155%, 2.05x, the same eight hot items); 12 lowest stand-in-ratio seeds live: 5 beyond the f8 1.2x gate, 7 within; 11 random: 1 beyond; hot set 1 of 22 at 2^24; gain 1.002x (1 MB copy serves 0.31% of loads) FINDING, bounded: a program-dataflow distinguisher (site 6, a near-zero source under the 1% (c') limit) that survives the class v5 dataset; not an exploitable bypass; the 256-unit selector is weak (7 of 12 false positives); shards and 23 live rows re-queued in the lease pool
Q2 Stand-in gap: a validated mirror runs the rule's own units on the closed form and on the live dataset; per-site ratio at 2^20 and the (c) metrics compared zero-dataset plant: live 0.9733 REJECT against closed accept (fired) any false accept that reads a hot set on the live set 54 programs: max per-site gap 0.0004 (the 2^20 sampling noise), mean min-ratio gap 0.00002, 0 verdict disagreements, (c) metrics agree to 0.019 of 128 BOUND
Q3 Handed to lane adv-accept-3 (unspawned); row 90 (exhaustion census: per-part rejections, cap, last resort) claimed by this lane, owner adv-accept-3 forced-exhaust plant must hit the cap and print the last-resort program P(exhaust) bounded; last resort characterised attempts census over 20k seeds RUNNING (box 2); plant RUNNING RUNNING (owner adv-accept-3, unspawned)
Q4 Handed to lane adv-accept-2 HANDED OVER
Q5 Generator distinguishers over accepted programs: lossy last write, register-set collapse, the per-site ratio tail against the 0.98 floor the five lowest-ratio seeds reproduce as live tail programs (done); F8 p15/p18/p19/p56 reproduction owed a structural shape that lowers the live distinct-item count first 864: lossy last write in 83%, 0 register collapse, min ratio 0.9986 at 256 units; at 2^20 the tail reaches 0.9832 (floor 0.98) RUNNING
Q6 Fixed (c) sample grindability; live-size invariance of the (c) verdict BOUND unless something fires not started PENDING

The plant (known-failed shape for the harness itself) fired: planting an or write of a load's source register immediately before the load makes the rule reject with "(a') load at 1 reads r4, not fresh by dataflow in the loop's steady state". So the harness reads the real rule, not a copy. Command: adv-accept plant --seed 0 on box 2.

Q1 and Q5: the accepted-program sweep (RUNNING, sharded)

Ten shards of 100,000 seeds (k = 2..1,000,001 of the F8 label space), each adv-accept sweep --seed-start S --seeds 100000 --threads 96 --ratio-units 256 --out /srv/builds/igneum-wt-adv-accept/adv/sweep-sNN.txt, started through run-box.sh (nice 10, yield to builds, pid/pgid/yield pid files beside the log). Shard 00 (S = 2) on box 2, started 19:27 BST. Shard 01 (S = 100,002) on box 1, started 19:30 BST. Shards 02..09 sit as self-contained scripts in /srv/builds/_adv/accept/queue/ on box 2 (claim by mkdir under claims/), to be run back to back on whichever box has idle cores. Every row is written as it lands, so a partial shard is data.

Live hot set (the measure the chip model prices): adv-live warps --program k --nonces N (the unmodified f8 harness: the day's items derived into a table, the cross-hash item histogram, the hot-set test X_f >= f against the window-model control, the 6-sigma test, library agreement checks). Known-failed shape run first: --plant const-item on program 2 at 10^6 nonces (box 1, 19:30 BST, log adv/live-plant-p2.log) beside its clean control (adv/live-control-p2.log). The plant must be FLAGGED and the control clear before any live number below is trusted.

Seeds: epoch bytes = LE words of seed_words_from_bytes("igneum-attack-f8/program/k"), era bytes of ".../era/k"; each drawn through the chain path generate_era(V4_CLASS, V3_ALLOWED), which runs the full attempt loop and the real acceptance rule.

Per accepted program the sweep records: attempt, program id, the closed-form distinct-item mean per hash (the rule's own (c) metric; 128 is ideal, the rule floor is a mean above 120), the minimum per-site distinct-index ratio at 256 units (the (c'') metric sampled cheaply; the enforced floor is 0.98 at 2^20 units), the saturated-final count and the output-bias max.

This is the closed-form proxy for Q1 and the headroom characterization for Q5. The live-dataset hot set (the memory-hard cache, items derived into a table, the cross-hash histogram with the hot-set test) is the next run and is what the chip model prices; the closed-form distinct mean is a cheap upper bound on how concentrated an accepted program can be on the stand-in.

Numbers land here when the run finishes (first results by 8 October 18:00 UTC).

Results as they land

Tool validation (box 1, 19:30 BST, 10^6 nonces each, about 30 s per run on 32 threads)

Run Hot-set test (window-model control) Top 0.1% share ratio over the window model 6-sigma Verdict
adv-live warps --program 2 --plant const-item (known-failed shape) f 1%: S_f 8.58%, E_f 2.09%, X_f +6.49% (X_f/f 6.49) HOT SET 21.80x (flat control 26.85x) FLAGGED FLAGGED
adv-live warps --program 2 (clean control) f 1%: S_f 2.56%, E_f 2.09%, X_f +0.47% (X_f/f 0.47) no hot set 0.9996x (flat 1.2312x, the window layer) clear PASS

The plant fires and the control is clean, so the live hot-set numbers below are trusted. Logs adv/live-plant-p2.log and adv/live-control-p2.log on box 1.

Sweep shard 01, first 864 accepted programs (box 1, seeds 100,002..., read at 19:33 BST)

Metric Value
Attempt histogram 0..9 273, 191, 134, 90, 59, 38, 34, 12, 7, 11; max 26
Min per-site distinct-index ratio at 256 units 0.9986 (floor 0.98 at 2^20; every row above 0.998)
Programs with a lossy (or/mul/mulhi) last write to an output register 715 of 864 (83%)
Programs writing fewer than 8 registers 0
Last-resort programs 0
Lowest-ratio seeds (live hot set queued) 100211 (0.9986), 100629 (0.9987), 100064, 100767 (0.9988), 100159

Reading: on the stand-in the accepted population sits 0.02 above the 0.98 floor at this sample size; the floor leaves headroom (Q5), and no accepted program in this sample comes near it. Whether any of the lossy-last-write programs concentrate reads on the LIVE set is what the live census answers.

Rule change in the method column (box-hours honesty)

19:27 BST to 19:4x BST: shards ran under the capacity layer's SIGSTOP yield and were paused almost the whole time (a build slot held nearly continuously on both boxes). Ruling at 19:4x BST: yield dropped, every sweep at nice 10 on cores 8-95 (cores 0-7 reserved for release builds, the seed and the observer). Shards 00 and 01 SIGCONTed and re-pinned at 19:4x BST. Box-hours before the ruling: about 0.1 of running time.

Live hot set of the five lowest-ratio shard-01 programs (box 1, 19:37 BST, 10^6 nonces each)

All five pass the rule (they are the chain's accepted programs). Log logs/adv-accept/live-lowratio-s01.log. Columns: the f8 gate (top 0.1% share over the window-model control, gate 1.2x), the hot-set excess X_f at f = 0.1% and 1% (a hot set needs X_f >= f), the windowed 6-sigma test, the hottest item and its traced source.

Seed id attempt closed ratio (256 u) top 0.1% over window model X_0.1% / X_1% 6-sigma (buckets64) hottest item, reads, share, source
100211 d07885a437e237c7 0 0.9986 1.08x +0.026% / +0.049% +42.4 sigma FLAGGED 0x454585, 1238 (0.0010%), site instr 4 reads r0 one-zero-bit, writer load@3
100629 37c849d9741c5994 0 0.9987 1.01x +0.003% / +0.015% +5.6 within 30 reads, none
100064 2442abf9d56f6611 2 0.9988 1.17x +0.044% / +0.189% +77.3 sigma FLAGGED 54 reads; the flag is a 256-item bucket at p43 (iteration 2, site 11, instr 33) holding 0.048% of that position's reads against 0.0061% expected (8x)
100767 9d68e6286fc817d4 2 0.9988 1.34x BEYOND the 1.2x gate +0.087% / +0.138% +68.0 sigma FLAGGED 0x000000, 1677 (0.0013%), site instr 6 reads r6 = zero, writer mad@4; saturated-source share 0.013% at that position (the (c') limit is 1%)
100159 573d650159a8b04e 3 0.9988 1.07x +0.020% / +0.124% +37.5 sigma FLAGGED 37 reads, none
p2 control (19:30 BST) f8 seed 2 0.9996x +0.00% / +0.47% (flat) clear 32 reads

Reading, as an attacker. (1) The stand-in ratio does correlate with live concentration: four of the five lowest-ratio seeds flag the windowed 6-sigma test at 10^6 nonces where the random control is clear, and one sits beyond the f8 gate. (2) The concentration is NOT a hot set a chip can use: the top 0.1% of items (16.7k items, 1 MB) take at most 0.34% of reads against 0.26% expected; the hottest single item takes 0.0013% of reads. An on-die copy of these items saves under 0.1% of DRAM reads: no row of chip-model-v3.md moves. (3) The mechanism is the known one, a near-saturated source (zero, or one bit off all ones) at one site in one iteration, below the (c') 1% limit (0.013% here), so (c') never fires, and the per-site ratio at 0.98 is loose enough (these sit at 0.9986) that (c'') never fires either.

FINDING (bounded): seed 100767 at 2^24 nonces passes the rule and flags the f8 hot-set test (box 1, 19:4x BST)

Reproduce in one command, from the frozen crate (017e7037) with the unmodified f8-uniform harness built as adv-live (tools/attack/adv-accept, cargo build --release):

adv-live warps --program 100767 --nonces 16777216 --threads 32 --diag 1 --validate sample --out <dir>

The program is the chain's class v4 draw for epoch seed bytes = the little-endian words of seed_words_from_bytes("igneum-attack-f8/program/100767") = 74484b391756fc49568cdd716bcfd839a55d31a45633c223c65c7f2ab4617fd4 and era seed bytes = the same of "igneum-attack-f8/era/100767" = 7a65a05391dcd87b8fdaf7f74813aa17c6e13f7c56a03da2aaa6176987ef038b (f8's program_spec(k) for k >= 2; adv-accept gap --seeds 100767 prints the same id), through generate_era(V4_CLASS, V3_ALLOWED): attempt 2, program id 9d68e6286fc817d4, class mx8-era763e5847+sh256x27, day bytes "igneum-day/" || 20730_le64 (f8's default day). The run's log is logs/adv-accept/live-confirm-16m.log in this branch (copied from box 1, /srv/builds/_adv-adv-accept/live-confirm-16m.log); the harness checks its mirror against Epoch::hash_warp on 64 warps plus every 997th (0 mismatches in the log). Accepted by every part of the rule: it is the program try_generate_class returns for the seed (attempt 0 and 1 rejected).

Measure Value Uniform / control
Hot-set test f = 0.1% S_f 0.303%, E_f 0.148%, X_f +0.155%, X_f/f 1.55: HOT SET X_f >= f fires
Hot-set test f = 0.5%, 1% X_f +0.266% (X/f 0.53), +0.325% (0.33): no hot set
Top 0.1% share over the window-model control 2.05x (0.5%: 1.37x, 1%: 1.23x); flat control 2.31x f8 gate 1.2x; population 0.998x to 1.043x (14 random accepted programs, census, 10^6 nonces)
Windowed 6-sigma, 64-item buckets largest bucket +294.8 sigma population +4.4 to +30.6 at 10^6 nonces
Hot items (top 0.1% = 17,034 items, 1.0 MB) 6,579,906 of 2,147,483,648 reads (0.306%) 0.148% expected
Top 8 items 0x000000 (29,355 reads), 0x200000, 0x300000, 0x180000, 0x100000, 0x080000, 0x380000, 0x0c0000: multiples of 2^19, read almost only from site 6 in every iteration
Site attribution site 6 (instr 23, src r6, quarter window) puts 3.35% of its reads into the hot items; site 7 (instr 32, src r0) 0.41%; every other site 0.00 to 0.21% (expected 0.10%)
Site 6 source r6, last written by mad at instr 4; saturated (zero) in 0.0126% of evaluations at that position (the (c') limit is 1%); the hot items are the images of small source values under the era stride

Gain, priced against chip-model-v3.md section 5.7: an on-die copy of the top 0.1% of items (1 MB of SRAM) serves 0.31% of this program's loads instead of 0.15%, so it removes 0.16% of DRAM reads. The f = 1 chip's rate is lanes over latency per read; 0.16% fewer reads is a gain of 1.002x. No row moves. The rule has let through a program with a measurable, attributable hot set, and the hot set is worthless to a chip. The distinguisher is real; the bypass is not exploitable at this size.

The other three lowest-ratio seeds at 2^24 nonces (same log): all BEYOND the f8 1.2x gate on the live set, none a hot set by X_f >= f.

Seed top 0.1% over window model X_0.1% (X/f) 6-sigma hot-set verdict
100211 1.33x +0.066% (0.66) FLAGGED clear
100064 1.63x +0.094% (0.94) FLAGGED clear
100159 1.29x +0.048% (0.48) FLAGGED clear
23 random accepted programs (census, 10^6 nonces) 0.998x to 1.043x, 0 over 1.2x 5 of 14 flagged weakly (+6 to +31)

So the stand-in's per-site ratio, read at 256 units in the sweep, is a working proxy for live concentration: the five lowest of 4,600 all fail the f8 gate on the live set while the population passes it. A seed-steering attacker (lane adv-accept-3's question) has a cheap selector. What it buys is the number above: a 1 MB hot set holding 0.3% of reads.

What a larger search adds: the sweep ranks seeds by the stand-in ratio, and the worst of 4,600 accepted programs gave X_0.1% = 0.155%. If the tail scales as the extreme of the population, 10^6 seeds reach a few times that, still under 1% of reads. The census over consecutive seeds (random accepted programs) says how often the hot-set test fires in the population; that number lands below.

The selector's base rate (sweep rows read at 20:46 BST: 29,032 accepted programs, shards 00, 01, 01b, 02)

The stand-in per-site ratio at 256 units, over every accepted program so far (one row per seed; every seed of the F8 label space yields an accepted program through the chain draw):

Quantile min 0.1% 1% 10% median max
ratio 0.9945 0.9982 0.9993 0.9998 0.9999 1.0000
Threshold Programs under it Tries per hit
ratio < 0.9990 164 of 29,032 1 in 177
ratio < 0.9986 (the five first-confirmed seeds sat here) 58 1 in 501
ratio < 0.9980 23 1 in 1,262
ratio < 0.9970 9 1 in 3,226
ratio < 0.9960 6 1 in 4,839

Over the 29,032: accepted attempt 0..11 = 9,302, 6,315, 4,298, 2,855, 2,029, 1,322, 960, 634, 409, 311, 175, 130; max 26; mean 2.128; last-resort programs 0; a lossy last write to an output register in 24,285 (83.6 percent); register-set collapse 0; mean or count 2.46 per program.

Cost of the selector: one chain draw per try (about 3 s of one core: the accepted attempt's 2^20 ratio pass dominates) plus a 256-unit ratio read (milliseconds), so a seed under 0.9986 costs about 25 core-minutes of grinding, and a seed-steering attacker who can choose among epoch seeds needs about 500 candidate seeds per hit. The five confirmed hits at that threshold all failed the f8 1.2x gate live; the random sample's live failure rate is 0 of 27 so far (census), so the gate-failure rate conditional on the selector is 5 of 5 against 0 of 27 unconditional. The widened rows (20 lowest, 20 random, at 2^24 nonces) turn this into a correlation with its error when they land (live-low20-16m.log on box 1, live-random20-16m.log on box 2).

Attempt histogram over the 16,337 (accepted attempt 0..11): 5,271, 3,602, 2,434, 1,585, 1,110, 740, 521, 368, 211, 166, 100, 72; max 26; mean 2.097; last-resort programs 0. Q5 structure: a lossy last write to an output register in 13,662 (83.6%), register-set collapse 0.

Row 90 (owner adv-accept-3, unspawned; claimed): the attempt loop, the cap and the last resort

Known-failed shape fired (box 2, 19:50 BST, adv-accept attempts --seed-start 2 --seeds 3 --force-exhaust, log adv/attempts-plant.log): with every verdict read as a rejection the loop hits its cap and hands the last-resort program, which the tool prints and re-checks. The three last-resort programs (cap 8 under the plant): every or, mul and mulhi rewritten to xor (op mix xor 17 to 19, load 16, 0 lossy ops, 8 registers written), and the real rule accepts each one as drawn (distinct mean 127.86 to 128.00, 0 saturated, bias max 58 to 66). Reading: the last resort is predictable (a deterministic function of attempt 256's draw) and is NOT weak by the rule's own measures; it is a program with no lossy op at all, which the live hot-set measure has not yet been run on (owed). The 20k-seed census of real attempts (per-part rejections, cap reached, P(exhaust)) is running (attempts-20k.log); its numbers land here.

The defender's question 3: the concentration at the acceptance's own 2^20 sample (box 2, 20:4x BST)

adv-accept gap --seeds 100767,100211,100064,100159,100629,2,3664 (lease 32, log logs/adv-accept/gap-rep8.log when it ends): per site, over the rule's own 4,096 units x 32 lanes x 8 iterations = 2^20 random-nonce evaluations, the share of the site's reads that land on word indices read 8 or more times (a uniform site on a 2^26-word window repeats an index 2 or 3 times at most, so this share is 0.000 percent for a clean site).

Program the low site distinct-index ratio closed / live reads on indices read >= 8 times, closed / live every other site
100767 (the exemplar) site 6 (instr 23, r6) 0.9919 / 0.9920 0.168% / 0.151% 0.000%
100211 site 9 (instr 31) 0.9907 / 0.9908 0.186% / 0.179% 0.000%
100064 min site 0.9832 / 0.9831 under 0.01% at every site
100159 min site 0.9834 / 0.9832 under 0.01% at every site
100629 min site 0.9834 / 0.9834 under 0.01% at every site
2 (control) none under 0.9999 0.000% everywhere
3664 (the lowest 256-unit read, 0.9945) min site 6 at 0.9944 / 0.9943 under 0.01% its 256-unit read was not noise: the 2^20 ratio agrees

All seven done (log logs/adv-accept/gap-rep8.log). Two of the seven carry a site with over 0.1 percent of its reads on heavily repeated indices (100767 site 6, 100211 site 9); the other low-ratio programs reach 0.983 at 2^20 through spread repeats under 0.01 percent per site, a different shape: a site that is slightly less than uniform everywhere rather than one hot image.

So the concentration the sequential 2^24 run shows (site 6 putting 3.35 percent of its reads into the top 0.1 percent of ITEMS, 17k items) appears at the acceptance's own random-nonce sample as 0.17 percent of site 6's reads on heavily repeated WORD indices and a ratio of 0.9919: the two readings agree once items (16 words each, 2^24 of them) are told from words (2^28), and the rule's sample does see it; its floor at 0.98 is set below it.

Q2, the stand-in gap: first bound (box 2, 19:46 BST, adv-accept gap)

Tool: a mirror interpreter with per-site index capture, run on the rule's own base nonces (seed-keyed acceptance stream) with init words = seed words, once on the closed-form dataset and once on the LIVE memory-hard dataset (day 20730, the kit's day). Validation on every program: the mirror's 32 hashes equal the library's hash_warp on 8 units on both datasets, and the mirror's closed-form per-site distinct counts equal the library's distinct_indices_v4 on all 4096 units. Known-failed shape --plant zero-dataset (every live word 0): live min ratio 0.9733, verdict live REJECT against closed accept, live distinct mean 115.99 against 128.00: the tool reports a gap when there is one. Logs adv/gap-plant.log, gap-first.log.

Seed id min per-site ratio closed (2^20) min live (2^20) largest site gap (c) on 64 units: distinct mean, saturated, bias max (closed / live) verdict closed / live
100767 (the finding) 9d68e6286fc817d4 0.9919 0.9920 +0.0002 127.714, 0, 82 / 127.730, 1, 53 accept / accept
2 (control) 8a0047b2eb071ade 0.9999 0.9999 -0.0002 128.000, 1, 56 / 128.000, 0, 57 accept / accept
100211 d07885a437e237c7 0.9907 0.9908 +0.0002 128.000, 0, 61 / 128.000, 0, 57 accept / accept
100064 2442abf9d56f6611 0.9832 0.9831 +0.0002 128.000, 11, 64 / 128.000, 6, 51 accept / accept

Reading. The per-site index distribution is set by the program and the register init, and the dataset words it folds in act as fresh randomness on both sides: the closed form and the live set give the same ratio to 2 parts in 10,000 at 2^20 evaluations, and the same (c) verdicts. No stand-in gap to steer into on these four. Also: the cheap 256-unit proxy did rank real tail programs, and 100064 sits 0.0032 above the 0.98 floor at 2^20, so the floor is live in the population tail, not idle.

Q2 BOUND over 50 consecutive accepted programs (seeds 3..52, box 2, 20:0x BST, adv-accept gap --seeds 3,...,52 --threads 32, log logs/adv-accept/gap-50.log; about 10 s per program):

Measure over 50 programs, 800 site rows, 2^20 evaluations per site Value
Largest closed-vs-live gap in any site's distinct-index ratio 0.0004
Mean of (closed min ratio - live min ratio) 0.00002
Verdict disagreements under the 0.98 floor 0 of 50 (min closed 0.9927, min live 0.9928)
(c) on 64 units: largest closed-vs-live gap in distinct mean per hash 0.019 of 128
(c) saturated finals: sum of (closed - live) over 50 -21 of 16,384 x 50 (noise about the 0 line)
Either side over the saturation limit (164) or the bias limit (136) 0

Bound: on 54 accepted programs the stand-in and the live dataset agree on every verdict and on every per-site ratio to 4 parts in 10,000, which is the sampling noise of a 2^20 draw (one standard deviation of the distinct count is about 90 of 1,040,000, or 0.0001 in the ratio). The threshold-edge disagreements the spec reports (39 in 100,000) are consistent with this spread; a program would have to sit within 0.0004 of the floor for the two sides to disagree, and nothing an attacker chooses moves the live side away from the closed side by more than that, because the words folded in are uniform on both. Steering through the gap is not available. What a longer pass adds: more programs near the floor to count the edge cases, which the sweep's ratio column already locates (rows under 0.9810 at 256 units, then a 2^20 gap read on each).

Widened live confirmation: the 20 lowest and 20 random (RUNNING, 2^24 nonces each)

  • box 1, 19:5x BST: adv-live warps --program k --nonces 16777216 --threads 48 --diag 1 for the 20 lowest stand-in-ratio seeds of the 16,337 (3664, 103378, 105756, 6610, 106474, 4765, 106700, 4346, 5245, 101905, 1605, 1738, 105371, 6842, 838, 3387, 103265, 170, 106924, 107022; ratios 0.9945 to 0.9980), log live-low20-16m.log. This row answers the defender's false-positive question: of the lowest 20 (plus the five already confirmed), how many are NOT beyond 1.2x live.
  • box 2, 19:5x BST: the same at 32 threads for 20 random accepted seeds (4107, 101710, 101886, 6132, 105915, 5133, 1932, 2328, 3665, 101643, 1352, 100521, 106359, 4905, 102519, 101697, 106740, 327, 1180, 101805; ratios 0.9994 to 0.9999), log live-random20-16m.log: the control for the correlation.
Seed stand-in ratio (256 u) live top 0.1% over window model X_0.1% (X/f) hot set
3664 (lowest of 16,337) 0.9945 1.311x BEYOND +0.074% (0.74) clear
103378 0.9960 1.157x within +0.028% (0.28) clear
105756 0.9960 0.9996x within -0.000% (0.00) clear
6610 0.9960 1.062x within +0.010% (0.10) clear
106474 0.9960 0.9996x within -0.000% (0.00) clear
4765 0.9960 1.020x within +0.003% (0.03) clear
106700 0.9960 1.0006x within +0.000% (0.00) clear
1352 (random) 0.9999 1.057x within +0.009% clear
100521 (random) 0.9999 1.153x within +0.025% (0.25) clear
106359 (random) 0.9999 1.0001x within +0.000% clear
4905 (random) 0.9999 1.012x within +0.002% clear
102519 (random) 0.9999 0.9999x within -0.000% clear
4107 (random) 0.9999 1.0004x within +0.000% clear
101710 (random) 0.9998 1.0034x within +0.001% clear
101886 (random) 0.9998 1.0000x within +0.000% clear
6132 (random) 0.9999 0.9996x within -0.000% clear
105915 (random, the lowest ratio of the random 20) 0.9994 1.399x BEYOND +0.065% (0.65) clear
5133 (random) 0.9999 1.0215x within +0.004% clear
1932 (random) 0.9999 1.0024x within +0.000% clear
2328 (random) 0.9999 1.0025x within +0.000% clear
3665 (random) 0.9998 1.0002x within +0.000% clear
101643 (random) 0.9999 1.0017x within +0.000% clear
(17 lowest and 10 random rows land as the runs end, 20:2x BST)

Base rate, corrected at 20:20 BST: at 2^24 nonces the f8 gate fires on random accepted programs too. Of the first 10 random seeds, 1 (105915) is beyond 1.2x at 1.40x, and it is the one with the lowest stand-in ratio of the random set (0.9994 against 0.9998 to 0.9999 for the other nine). So "beyond 1.2x at 2^24" has a base rate near 1 in 10 among accepted programs (the 10^6-nonce census read 0 of 47 beyond because the gate is sharper at 2^24), and the selector's 6 of 8 is an enrichment of about 6x over that base rate, not a clean separation. The hot-set test proper (X_f >= f) has fired on 1 of 18 programs measured at 2^24 (100767).

Reading at 20:25 BST (final for tonight's rows; corrected: 100629 was within at 10^6, 1.011x), honestly: the 256-unit selector is weak. Of the 12 lowest-ratio seeds measured live (100211, 100064, 100767, 100159, 100629, then 3664, 103378, 105756, 6610, 106474, 4765, 106700), 5 are beyond the f8 1.2x gate and 7 are not; the random control is 1 of 11 beyond (105915 at 1.40x). The five that are beyond are four of the first five (256-unit ratios 0.9986 to 0.9988, 2^20 ratios 0.9832 to 0.9919) and 3664 (0.9945); the seven that are not include five that sit LOWER on the 256-unit read (0.9960), which says the 256-unit read is noise-dominated at that level (one standard deviation of a 65,536-evaluation distinct count is about 0.001 in the ratio) and the real selector is the 2^20 ratio the rule itself computes (2.8 s per candidate: 100064's 0.9832, 100211's 0.9907 and 100767's 0.9919 are genuinely low; 3664's 2^20 ratio is in the re-queued gap read). So: selector enrichment about 4.6x over the base rate (42 percent beyond against 9 percent), false-positive rate 7 of 12 on the 256-unit read; the error on both is binomial at n = 12 and n = 11, about plus or minus 14 points. The hot-set test proper (X_f >= f) fired on 1 of 22 programs measured at 2^24 (100767), and on none of the 11 random.

Confirming row for the class v5 acceptance floor (c'''): pre-floor draw against post-floor refusal (box 2, 20:36 BST)

Not a class v5 finding. Does seed 100767 (id 9d68e6286fc817d4 under class v4) still read hot when the dataset is class v5's state-derived one? Tool: tools/attack/adv-accept-v5 (the same f8 harness over the vendored igneum-pow of branch class-v5 at 25c8063f, read-only input, which is the class v5 crate BEFORE commit ab6f980b: it has no per-site floor (c''') yet). Under that pre-floor crate the class v5 draw of the seed lands on attempt 2, id 2fd83dbae09c366d, the same base program and era as the v4 id. Under the frozen class v5 rule (ab6f980b and later) the defender reports the same seed is REFUSED at attempt 2 by the new per-site floor (c'''), which names site 6 at 0.991, and the v5 draw lands on attempt 4, id 734fbb8e3e4cd20f (stated by the class v5 lane; not derived here). So this row measures the pre-floor program on the v5 dataset and shows what the floor was built to refuse: generator 5; the dataset XORs the window's state leaf into every item before the first mixer. State stream: the Devnet 3 v5 pack's state.igsd1 (inputs/v5-dn3-epoch0-state.igsd1, 11 records, root 7e37a9fb...a311, leaves fnv f141bfee2a8b11b0), the only public state stream. Commands, through the lease pool (lease 32, 16 cores taken), log logs/adv-accept/v5-exemplar.log:

adv-live-v5 warps --program 100767 --nonces 1000000 --plant const-item --state <stream>    (known-failed shape)
adv-live-v5 warps --program 100767 --nonces 16777216 --diag 1 --validate sample --state <stream>
Measure class v4 (live-confirm-16m.log) class v5 with the state leaves plant (const-item, 10^6)
Hash agreement with the library's Epoch::hash_warp 0 mismatches 589 warps, 0 mismatches skipped under the plant
Hot-set test f = 0.1% X_f +0.15503%, X/f 1.55, HOT SET X_f +0.15514%, X/f 1.55, HOT SET X_f +6.32%, X/f 63
Top 0.1% share over the window model 2.0455x 2.0462x 25.7x
Windowed 6-sigma, largest 64-item bucket +294.8 +298.3 +332,226
Hot items (top 0.1%) and their reads 17,034 items, 0.3064% of reads 17,086 items, 0.3071% of reads
Top 8 items 0x000000 (29,355), 0x200000, 0x300000, 0x180000, 0x100000, 0x080000, 0x380000, 0x0c0000 the same eight: 0x000000 (29,722), 0x200000, 0x300000, 0x180000, 0x100000, 0x0c0000, 0x080000, 0x380000 0x001234 (the plant)
Site attribution site 6 3.350%, site 7 0.414% site 6 3.358%, site 7 0.415%
Hottest item's traced source site instr 6, r6 = zero, writer mad@4 the same

Reading. The state leaf changes every dataset WORD, and the hot set does not move by a part in a thousand: the concentration is a property of the program's register dataflow at site 6 (r6 reaching zero through the mad at instruction 4 in about 0.013 percent of evaluations, then the era stride mapping small values to items at multiples of 2^19), not of the dataset's values. Any dataset keyed the same way through the same load address function inherits it. So the class v5 change does not touch this finding; what would is a rule on the program (the (c') saturation limit at 1 percent sits 80x above this program's 0.013 percent, and the 0.98 per-site floor sits 0.012 below its 0.9919) or a load address that does not map small sources to a fixed item set. Price unchanged: 1 MB of on-die items serves 0.31 percent of loads, gain 1.002x, no row of chip-model-v3.md moves under either class.

Rule change 19:55 BST (box-hours honesty)

The bounded class became 88 cores per box in total across all lanes: no new sweep starts except under the per-box lock flock /srv/builds/_adv/locks/sweep.lock, one sweep per box at a time; the running shards 00 and 01 finish as they are; my adv-live confirmations and the row-90 census count against the ceiling, so nothing new starts until they end. Shards 02 to 09, the class-v5 check and any re-run go through the lock.

Live hot-set census (RUNNING)

  • box 2, 19:5x BST: adv-live census --programs 2..201 --nonces 1000000 --threads 32 (200 consecutive accepted programs of shard 00's range: the random sample), log adv/live-census-s00-2-201.log.
  • box 1, 19:5x BST: adv-live warps --program k --nonces 1000000 for the five lowest-ratio shard-01 seeds, log adv/live-lowratio-s01.log.

Ledger: the kill of 20:21 BST and the re-queue through the lease

Main's rule (relayed 20:2x BST): no sweep, census or verdict run on a box except through the build-server lane's lease pool <threads> -- cmd (landing within the quarter hour); hand-started binaries killed by their pid files now, not left to finish; release builds and the class v5 suites outrank every sweep tonight.

Run Box Killed at (UK) Reached Lost Re-queue
sweep shard 00 (seeds 3847..) build-2 20:21:20 7,944 rows (plus 3,812 of part 0) the rest of the shard lease pool, from the frontier seed
sweep shard 01 (seeds 104649..) build-1 20:21:13 6,943 rows (plus 4,622 of part 0) the rest of the shard lease pool, from the frontier seed
live census, 10^6 nonces, programs 2..201 build-2 20:21:18 51 programs (32 in the mirror copy, 19 after) programs 53..201 lease pool
20 lowest at 2^24 build-1 20:21:12 6 of 20 14 rows lease pool
20 random at 2^24 build-2 20:21:19 11 of 20 9 rows lease pool
row 90 attempts census, 20k seeds build-2 20:21:17 no summary (prints at the end) the whole run lease pool, with progress lines added first
class v5 exemplar (queue 10), repeated-index read (queue 11) build-2 20:21:52 never ran (waiting on the sweep lock) nothing lease pool

Accepted programs in hand after the kill: 23,319 distinct seeds (11,755 of shard 00 up to seed 11829; 11,564 of shard 01 up to 111630; 138 seeds in flight at the kills are gaps below the frontiers). Every partial row above stays in this report as partial. Box-hours running before the kill: about 2.9.

Re-queue through lease pool (live on both boxes from 20:22 BST; every lease at most 48 cores, --min 16; the pool rule: release builds and the class v5 suites outrank every sweep, and a waiter labelled "v5 gate" or "v5 kit" means finish the shard in hand and release):

Order Run Box Queued (UK) Lease
1 14 remaining lowest-ratio seeds plus 100629, 2^24, --diag 1 build-1 20:25:04 48 / min 16
1 9 remaining random seeds, 2^24 build-2 20:25:11 32 / 16
2 class v5 exemplar: const-item plant at 10^6, then 100767 at 2^24 with --diag 1, state = the Devnet 3 v5 pack's stream build-2 20:25:11 32 / 16
3 repeated-index gap read (seeds 100767, 100211, 100064, 100159, 100629, 2, 3664) build-2 20:25:11 32 / 16
4 row 90 attempts census, 20k seeds (after the rebuild with progress lines) build-1 20:27:12 48 / 16
5 shard 00 from seed 11830 (88,172 seeds); shards 02, 04, 06, 08 build-2 20:2x 32 / 16 each
5 shard 01 from seed 111631 (88,371 seeds); shards 03, 05, 07, 09 build-1 20:2x 32 / 16 each

At 20:25 BST the pool on build-2 had 0 free cores (adv-accept-3 and another lane ahead in the queue); my leases wait their turn. At 20:28 BST: all 15 of my leases wait with 0 free cores on both boxes (build-1: 12 leases of other lanes holding, 10 waiting; build-2: 3 holding, 11 waiting; load 100 and 89). Nothing of mine runs; the lease waits up to 2 h and then gives up, so a lease that never gets cores by 22:25 BST is re-queued again and says so here. The 00:00 BST reading carries the partial rows above if no cores free.

Yield rule widened at 20:3x BST: whenever lease status shows a waiter whose owner is class-v5 or whose label contains "v5" (the v5 census is queued as "class v5 c3 census"), any run of mine HOLDING pool cores is ended by its pgid file and re-queued at the back of the pool (a sweep from its frontier seed, its rows kept; a live chain minus the programs already done). I do this by hand from the status polls; nothing changes while my leases are waiters. Refined at 20:3x BST: the test is by OWNER: yield to a waiter whose owner is class-v5, or whose owner is attack-pass with "v5" in its label; never to a waiter whose owner starts with adv- (so my own "v5-exemplar" label and the sibling lanes' leases are not yield triggers).

Yield executed 20:41 BST on box 2 (the class v5 (c''') census, owner class-v5, 88 cores, waiting since 20:39 behind my leases): ended by pgid file live-random9-16m (6 of 9 done), gap-rep8 (7 of 7 done, nothing lost) and sweep-s02 (2,474 rows kept, frontier 202482); withdrawn by pid the four waiting shards and the re-queues made a moment earlier; box 2 then showed 0 holders and 0 waiters of mine at 20:41:38. By main's order I take no lease on box 2 until the census is confirmed running; the box-2 order then resumes (3 random seeds, shard 02 from 202482, shard 00 from 11830, shards 04/06/08). Build-1 unchanged.

Ranked lease (build-server lane, 20:40 BST, lease sha 5d84d644): classes release > v5 > measure > adv; an adv holder above 32 threads is pre-empted after a higher class has waited 120 s; holders at 32 or fewer never are; waiters started under the old tool are unranked. So at 20:42:52 BST on build-1 I killed my six old waiters by pgid file and re-submitted each once at 32 threads with --min 16 (the 14-seed live chain, row 90, shards 03/05/07/09); the holder sweep-s01b (32 cores, 2,134 rows at that moment) stays. No label of mine contains a promoted word; the "v5-exemplar" tag is retired (its run is complete) and any re-run will be tagged class5-exemplar.

20:44 BST: box 2 shows the class v5 census holding 48 of 88 pool cores since 20:41:55 (10 s after my release). My box-2 queue stays withdrawn until the coordinator's word, then re-submits at 32/16.

Where the pass stands (for the 00:00 BST reading; numbers refreshed as rows land)

Item Reading
Box-hours spent (running time, both boxes, nice 10) about 2.6 at 20:06 BST: two 88-thread shards (3.5 h of wall so far at 50 to 90 percent of a box each under contention), two adv-live confirmation chains, the census, the gap tool, the attempts census; pod-hours 0 (no GPU, no pod)
Q1 bound reached 16,337 accepted programs drawn through the chain path (of the 10^6 planned; shards 02 to 09 queued behind the lock); the lowest 8 by the stand-in proxy measured live at 2^24: 6 of 8 beyond the f8 gate, 1 of 8 a hot set by X_f >= f (seed 100767, +0.155%, gain 1.002x); random control 0 of 31 beyond (27 census at 10^6 plus 4 at 2^24)
Q2 bound reached 54 programs: no stand-in gap above the 2^20 sampling noise, 0 verdict disagreements
Q5 lossy last write in 83.6 percent of accepted programs with no live effect found beyond Q1's; register-set collapse 0; the 0.98 floor is live in the tail (0.9832 at 2^20 seen)
Row 90 (owner adv-accept-3) plant fired (last resort reached, printed, re-checked: accepted, no lossy op); the 20k-seed census of real attempts running
BLOCKED per-card hash-rate confirmation of any gain (no GPU tonight); priced analytically against chip-model-v3.md instead
What a longer pass adds the other 98 percent of the 10^6 seeds (the tail by the 2^20 ratio, not the 256-unit proxy), the live row for every seed under 0.985, the class-v5 row for the exemplar and for the ten worst, and the repeated-index share at the acceptance sample: more rows of the same shape, not a different answer unless a seed reads a hot set over 1 percent of reads, which 16,337 draws did not produce

Running notes

  • Box-hours and commands are logged in each section with the seed, so every claim is reproducible by re-running the exact command on box 2.
  • No cargo on the Mac. Pushes to the build mirror only. Commits as igneum-labs.