FUD ledger sweep, round 2: spec 06 rows restated, M20 exposure dated, the sweep's status-update section and the morning findings

Spec 06 rows O-3.1, O-3.14, O-5.9 and O-5.11 carry the sweep's evidence (fix row 124 done). M20: the devnet's pruning
point leaves genesis between DAA 108,000 and 151,200, about 14:00 UTC 5 October to 01:00 UTC 6 October, after which a
fresh node rejects the honest pruning proof under the stub. The ledger ends with the sweep's status-update section;
the review file carries draft counts and the three findings.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/fud-fixes.md

@@ -281,7 +281,7 @@ Added by `docs/review/ledger-sweep-2026-10-05.md`, which holds what ran, what di
 | 121 | M21 | k = 18 is Kaspa's table value; `calculate_ghostdag_k` gives k 5 at the cloud devnet's measured p99 of 0.67 s and k 55 at a 20-s bound, and proof-bearing bodies are unmeasured | Run O-2.2 with bodies of the size design 5.4 implies, take the p99 propagation, re-derive k with the fork's function (the table is in the ledger entry) (3 h) | consensus engineer | before testnet | no |
 | 122 | X29 | The live node's gRPC listens on every interface (`igneumd` on `*:26610`, read-only check 5 October); the file modes are fixed | `--rpclisten=127.0.0.1:26610`; PC 2 through a tunnel or its own node (0.5 h) | app owner, the project lead | now | no |
 | 123 | M14, F14 | O-3.14 (the finality simulation with the DAA in the loop under both forms of W2) has no DAA model inside `finality_v2.py`; the chain-model result (no amplification under either controller) stands in for it | Add a lagging retarget to `finality_v2.py` (Kaspa's sampled window and rule v2), run the 50x pulse under both W2 forms, log the day the renter crosses a third (4 h) | cryptographer (sim) | before testnet | no |
-| 124 | F1, O-3.1 | Spec 06 row O-3.1 still says "not yet in `sim/`" and the ledger's launch-month arithmetic was in prose only | Restate O-3.1, O-3.14, O-3.15, O-5.9 and O-5.11 in spec 06 with tonight's evidence (the min_daa rule is implemented and measured; K, I and the economy scenarios ran; the budget grid ran) (0.5 h) | Claude (spec) | now | no |
+| 124 | F1, O-3.1 | Spec 06 row O-3.1 still said "not yet in `sim/`" and the ledger's launch-month arithmetic was in prose only | Done in the sweep (5 October 2026): rows O-3.1, O-3.14, O-5.9 and O-5.11 of spec 06 carry tonight's evidence (O-3.15 was already marked decided) | Claude (spec) | done | no |
 | 125 | X14 | Only hashing concentration can be computed from what the observer keeps; signing, proving and aggregation need certificate and proof-record extracts | The observer stores signer bitmaps per certificate and prover keys per proof record; a nightly top-1/3/10 table on the live page (3 h) | app owner (observer) | before testnet | no |
 | 126 | E12 | The devnet half of O-5.9 (profit-only prover clients, `f_p` and `B_p` paths) | Phase 4 devnet run as the ledger entry states (4 h) | execution engineer | before testnet | no |
 

docs/fud-ledger.md

@@ -29,7 +29,7 @@ Evidence locations referenced below: `docs/bench-log.md`, `proto-metal/TESTS.md`
 ### M1. The program space is tiny
 "Eleven integer ops, 64 instructions, 8 iterations, a splitmix register init. That is not RandomX. RandomX leans on a superscalar out-of-order CPU with floating point and branches. Yours is a sea of 32-bit ALUs and a memory bus. A chip for that is a weekend."
 
-Status: Open, experiment scheduled.
+Status: Open, experiment scheduled. Sweep (5 October 2026): nothing runnable; the bounty, the public benchmark and a chip design are M22's decisions and hardware. The nearest number stays M16's arithmetic.
 
 Answer: Correct that the arithmetic is simple on purpose. Integer only, because floating point rounds differently per vendor and would split the chain (design doc, hostile review table, row 2). The defence is not the ALU work. It is random 4-byte reads over a dataset larger than any on-chip cache: the RTX 5090 runs the same program 5.8x faster when the dataset fits in its 96 MiB L2 (1,352 Mhash/s at 64 MiB against 229 at 1 GiB, bench-log, RTX 5090 sweep). A chip has to buy the same gigabytes of memory and loses the same latency. The honest target for a chip's gain is under 2x and it is a target, not a measurement. The experiment that tests it is the standing bounty for any chip design beating a GPU by more than 2x, live with the public benchmark in January 2027 (design doc, decisions table, row 1). Until a bounty has gone unclaimed for years the claim is a target.
 
@@ -347,7 +347,7 @@ Evidence: design doc "Proving speed on consumer GPUs" risk item and Finality v2
 ### P9. Shard griefing
 "Claim a shard with a small bond and never prove it. Repeat. Finality waits on you."
 
-Status: Answered by design, parameters open.
+Status: Answered by design, parameters open. Sweep (5 October 2026): the parameters (O-5.6) are phase 4 devnet work; the economy simulator's lever study found the claim timeout a market parameter and recommends starting the devnet at 120 s (`docs/analysis/economy-2026-10-04.md` section 6).
 
 Answer: The bond is slashed and the shard reopens; the proving fee rises until someone proves it (security model table, "Prover cartel withholding proofs"). The open parameters are the bond size, the timeout, and whether an un-proven block delays only the proof (it does; execution and the 30-second lock do not wait for the proof). Set in phase 4.
 
@@ -1109,7 +1109,7 @@ Evidence: `docs/analysis/weak-program-census-2026-10-03.md` sections 7 and 9. Re
 ### M20. Pruning proofs are checked with the kHeavyHash stub
 "Wait thirty hours, start a fresh node, and watch it reject the honest pruning proof: `validate.rs:192` runs kHeavyHash on headers mined under the lottery, which pass with probability 2^-28. And if you loosen that, I forge levels with an ASIC that already exists."
 
-Status: Open, acknowledged, fix named. Sweep (5 October 2026): still the stub on `devnet-v4` (`consensus/src/processes/pruning_proof/validate.rs:192` calls `calc_block_level_check_pow`; `apply.rs:74, 200` and `mod.rs:207` call `calc_block_level`). The test, a fresh node syncing a chain past its pruning depth, needs a network older than that depth; a fresh node against the live devnet is outside this sweep's rules, so it was not run. Fix row in `docs/fud-fixes.md` section 2.5.
+Status: Open, acknowledged, fix named. Sweep (5 October 2026): still the stub on `devnet-v4` (`consensus/src/processes/pruning_proof/validate.rs:192` calls `calc_block_level_check_pow`; `apply.rs:74, 200` and `mod.rs:207` call `calc_block_level`). The test, a fresh node syncing a chain past its pruning depth, needs a network older than that depth; a fresh node against the live devnet is outside this sweep's rules, so it was not run. When it bites: the devnet's pruning depth is `PRUNING_DURATION` 108,000 DAA (`consensus/core/src/config/constants.rs:94`; the derived lower bound is 63,398), and the pruning point first leaves genesis once a finality point sits a full pruning depth below the tip, DAA 108,000 to 151,200, which at 1.05 DAA/s from DAA 33,000 at 17:37 UTC on 4 October falls between about 14:00 UTC on 5 October and 01:00 UTC on 6 October (approximate). From then on a fresh node receives a pruning proof and the stub rejects the honest headers with probability about 1 - 2^-28 each. Fix row in `docs/fud-fixes.md` section 2.5.
 
 Answer: Correct. `consensus/src/processes/pruning_proof/validate.rs:192` calls `calc_block_level_check_pow`, which runs the stub, and `apply.rs` and `mod.rs` call `calc_block_level` the same way; `docs/fork-divergence.md` records that seeds must be threaded through pruning-proof validation before a pruning network. The devnet will pass its pruning depth (108,000 blocks, sooner after tonight's overshoot) and a fresh node will show it. Fix: derive the epoch and day for proof headers from the proof's own headers (fork map a4, O-2.5) and remove the stub from the proof path.
 
@@ -1833,3 +1833,14 @@ Evidence: the commits above. Experiment: `curl https://igneum.network/api/live`
 - **M13** (Macs mine too). Extended: the ratio is measured, 26.7 / 124, about a fifth, and the litepaper (`:420`) still carries no ratio; the app shows no projected earnings, which for a devnet is the right outcome. Review id R4.7.6.
 - **E5** (the client dev fee). Still open on the homepage; see L9.
 - **D2** (the app share). The "Why build here" text is applied at `site/litepaper.html:355` and states the number; two gaps noted under E17.
+
+## Status updates, 5 October 2026 (ledger sweep, night of 4 to 5 October)
+
+`docs/review/ledger-sweep-2026-10-05.md` holds the runs, the commands and the running table. Every Open, Proposed, Unmeasured or pending entry was read against its experiment line; the status lines above carry the evidence inline, marked "Sweep (5 October 2026)" where a note was added and "Was:" where the status changed. Items owned by the other two night branches (F23, F24, G12, X18, the flood memory growth; the base-fee floor, testnet parameters, G13, G14, public text) were left to them.
+
+- **Moved to Fixed or Rolled out, from evidence that already existed and had not reached the ledger:** M15 (cheap checks before the PoW engine, merged and live), M17 (hot swap, measured on the live devnet across three vendors), M19 (the census cells filled, 16 loads a Definition), M24 (rule v2 activated at DAA 33,000), P20 (the buffered save confirmed on the third run), X16 (the evidence page exists), G11 (the spec is public).
+- **Moved to Answered with evidence:** F1 (the first-month gate implemented and measured; the launch month is arithmetic now), F7 (reorg depth p50 1, p99 3, max 5 on a 12-node, 5-region network), F19 (bought keys are worth their blocks; scenario K at both floors), E12 (the simulation half), E15 (the security-budget model: the floor is crossed in year 7, 11 or never by price, and no fee level moves it).
+- **Fix built on a branch, pending merge or rollout:** M26, M27, X21 (`miner-reliability` `aea5ac6d`, with the app half on `release-0.3.5`), F22 (rule v3, fast-time network), part of X22.
+- **Open with new evidence and a fix row (fud-fixes section 2.5):** M20 (the stub is still in the pruning-proof path on `devnet-v4`; it goes live the moment the devnet passes its pruning depth), M21 (the k table from the fork's own function), M28, X20, P15, X29 (half fixed: file modes), X14 (hashing concentration measured), M14 and F14 (no amplification in the chain model; the finality-with-DAA run still owed).
+- **Open, needs hardware, a person or the devnet:** M1, M11 (a rig), M16 (the 5090), M22, M25, X19 (the node line; `faketime`), X23 to X28 (the relay owner and PC 1; the token is rotated, the run-task binding is not), E13, E14, E16, E17 (the draw lines), F16, F20 (the devnet test), C4 (module off), P3, P14, P16, P17, P21, P22, X13, X15, X17, G10, L1 to L5, L8, D5, D6.
+- **Nothing became worse.** Two things are closer than they look: M20 becomes a live failure for every fresh node once the devnet's pruning point leaves genesis, which at the devnet's 1.05 DAA/s (DAA 33,000 at 17:37 UTC on 4 October) is between DAA 108,000 (`PRUNING_DURATION`, about 14:00 UTC on 5 October) and DAA 151,200 (the first finality point a full pruning depth below the tip, about 01:00 UTC on 6 October), approximate; X23's operational half (a run task on the PCs needs only the relay token) is unchanged after the rotation.

docs/spec/06-open-items.md

@@ -49,7 +49,7 @@ An item closes when its measurement is in `docs/bench-log.md` or its decision is
 
 | Id | Item | What closes it | Gate |
 |---|---|---|---|
-| O-3.1 | The first month: no weight exists; an attacker producing 75% of blocks from day 2 crosses 2/3 on day 9 (ledger F1). C5 says first hour; this specification proposes first 30 days | Launch-month simulation (not yet in `sim/`); decision; litepaper states the rule either way | 3 |
+| O-3.1 | The first month: no weight exists; an attacker producing 75% of blocks from day 2 crosses 2/3 on day 9 (ledger F1). C5 says first hour; this specification proposes first 30 days | Launch-month simulation (not yet in `sim/`); decision; litepaper states the rule either way. Sweep 5 October 2026: the gate is implemented (`min_daa = weight_window`, fin-fixes, merged into devnet-v4) and measured on the fork (harness s5 before and after, `docs/bench-log.md` "finality fixes F17 and F1"); the launch month under the gate is arithmetic in `docs/review/ledger-sweep-2026-10-05.md` (no lock before day 30; on day 30 an attacker with share s of blocks from day k holds s (31 - k) / 30, so 75% from day 2 holds 72.5% and locks alone, 51% from day 1 cannot; the lock-alone threshold is 69% from day 2). What is left is the decision to keep the gate at the full window, which the ledger (F1) recommends | 3 |
 | O-3.2 | Checkpoint depth d = 60 is a placeholder (ledger F7) | Devnet with regional latency records the reorg-depth distribution at each block rate; set d so a vote split at one index is rare | 3 |
 | O-3.3 | Parameters of the block reading of participation (rule closed 3 October 2026, section 3.3 Q2 and 3.4.1; ledger F3): the per-block vote bound and the carriage window, and the simulation ran with the narrower cert reading | Add vote carriage in blocks and a hostile aggregator to `finality_v2.py`; re-run A, C, D and F1 under the block reading; set the per-block vote bound and confirm the carriage window of 240 indices | 3 |
 | O-3.4 | Certificate grace value; must be at least 3x the worst honest one-way delay (section 3.3, Q4) | Measure one-way delays on the devnet across regions; set grace | 3 |
@@ -62,7 +62,7 @@ An item closes when its measurement is in `docs/bench-log.md` or its decision is
 | O-3.11 | Key succession (W5): replay protection and what happens if both keys mine after the message | Specify the message (old key, new key, DAA score, signature) and that blocks naming the old key after inclusion earn nothing | 3 |
 | O-3.12 | Vote message and certificate wire formats, aggregation rules, bitmap size at 10^4 keys | Specify with the P2P layer | 3 |
 | O-3.13 | `finality_active` flag semantics and exchange guidance (section 3.9) are Designed and untested | Devnet stall test; exchange guidance reviewed by an operator | 3, 4 |
-| O-3.14 | Finality simulation with the DAA in the loop under a pulsed rental (ledger M14 and F14, round 3): every run of `sim/results_v2.md` assumed a perfect retarget, and the devnet of 3 October 2026 showed DAA time running 2.9x the wall clock for 17 minutes after a hashrate step | `finality_v2.py` with Kaspa's sampled DAA and the controller chosen at gate 2 (section 2.3) in the loop, a 50x renter pulsing two minutes in every hour, under both forms of W2 and Q1 (DAA-score blocks as simulated; median-time buckets as specified in section 3.1 and 3.3), reporting the day the renter crosses a third and the chain's block rate meanwhile; logged in `docs/bench-log.md`; confirms or reverts the median-time form | 3 |
+| O-3.14 | Finality simulation with the DAA in the loop under a pulsed rental (ledger M14 and F14, round 3): every run of `sim/results_v2.md` assumed a perfect retarget, and the devnet of 3 October 2026 showed DAA time running 2.9x the wall clock for 17 minutes after a hashrate step | `finality_v2.py` with Kaspa's sampled DAA and the controller chosen at gate 2 (section 2.3) in the loop, a 50x renter pulsing two minutes in every hour, under both forms of W2 and Q1 (DAA-score blocks as simulated; median-time buckets as specified in section 3.1 and 3.3), reporting the day the renter crosses a third and the chain's block rate meanwhile; logged in `docs/bench-log.md`; confirms or reverts the median-time form. Sweep 5 October 2026: the chain model has run (`sim/difficulty/attacks` scenario 2: a 50x pulse earns 3.7% of the base's blocks per hash under the Igneum rule and 85% under Kaspa's, weight per hash 0.26 and 0.98, never above 1) and the fork agrees (harness s5, weight share over block share 0.999). The DAA inside `finality_v2.py` under both W2 forms is still not written (fud-fixes row 123) | 3 |
 | O-3.15 | Vote keys with history can be bought, borrowed or stolen; every scenario in `sim/results_v2.md` models a renter who must mine (ledger F19, external review 3 October 2026) | `finality_v2.py` scenario: k% of weight changes hands at day 0 against the same k% arriving as fresh hashrate, for k in 20, 34 and 40, plus a 40/40/20 partition row under the active-set rules and the floor; report time to a conflicting lock; decide whether W5 makes the successor re-earn and whether weight decays when a key's block profile breaks | 3 |
 | O-3.16 | What holds during a finality pause: the seed pipeline from uncertified checkpoint blocks (O-4.3, section 4.3), the survival of pre-pause locks (3.5) and `finality_active` false (3.9) are three texts and no statement (ledger F20) | Decide O-4.3 (this specification recommends uncertified-allowed); write the four pause guarantees into 3.7; devnet with a 45% silent set through 3 epoch boundaries: program advances on schedule, no seed fork, pre-pause locks survive the heal | 3 |
 
@@ -92,9 +92,9 @@ An item closes when its measurement is in `docs/bench-log.md` or its decision is
 | O-5.6 | External job bond size and claim timeout (ledger P9); shards carry no bond since the sortition rule of section 7.2 | Set on the phase 4 devnet | 4 |
 | O-5.7 | The provers' proportion of the 80% tip share (section 5.2) | Defined by the chunked proving protocol | phase 2 |
 | O-5.8 | Developer registration format at deployment and the re-registration transaction (section 5.2) | Execution-layer specification | decision, execution engineer |
-| O-5.9 | Mining against proving under shocks: external proving pays 10x, the IGN price falls, a large operator leaves, assignments go unfulfilled, clients maximise profit (ledger E12); design R8 covers the fee switch only and has not run | R8 simulation extended with the five shocks, then the phase 4 devnet with profit-only prover clients: backlog depth, time to clear, `f_p` and `B_p` paths, income per card | 4 |
+| O-5.9 | Mining against proving under shocks: external proving pays 10x, the IGN price falls, a large operator leaves, assignments go unfulfilled, clients maximise profit (ledger E12); design R8 covers the fee switch only and has not run | R8 simulation extended with the five shocks, then the phase 4 devnet with profit-only prover clients: backlog depth, time to clear, `f_p` and `B_p` paths, income per card. Sweep 5 October 2026: the simulation half ran in `sim/economy` (scenarios b, d, e: external 10x with a 70% price fall, the 20% operator leaving, a 30% operator never fulfilling; no backlog, every block proven within 60 s, hash trough 82% and 75%); the devnet half with profit-only clients is fud-fixes row 126 | 4 |
 | O-5.10 | No single figure shows every payment route (emission, base fee, priority fee, external jobs at launch and after the bridge, the client dev fee) with currency, recipient, fee and burn (ledger E13) | Draw it, one route per row, in the litepaper Economics section and the customer brief; operator revenue never summed with protocol revenue | decision, execution engineer; before public repo |
-| O-5.11 | Security budget through halvings with low fees and no external demand at a flat IGN price (ledger E15) | Model of emission per 2.5 through year 12 against a fee grid and an income-per-card hashrate response; payments to miners and provers reported apart from the burn; the failing year and price stated in the litepaper | before mainnet, simulation |
+| O-5.11 | Security budget through halvings with low fees and no external demand at a flat IGN price (ledger E15) | Model of emission per 2.5 through year 12 against a fee grid and an income-per-card hashrate response; payments to miners and provers reported apart from the burn; the failing year and price stated in the litepaper. Sweep 5 October 2026: ran as `docs/analysis/security-budget.md` (3 October) plus `sim/economy/security_budget.py` (fee grid, falling and rising paths, hashrate response): the USD 1,000,000 miner floor is crossed in year 7 at USD 0.005, year 11 at USD 0.02, never within 14 years at USD 0.10; no fee level in the grid moves the year; at the year-7 crossing a 51% attacker matches the fleet the budget pays for at USD 1,369 of electricity a day. The litepaper sentence is public text | before mainnet, simulation |
 
 ## 6.6 Sections 7 and 8, execution and client security