Ledger decisions item 13 (the gate-3 parameters of spec 3.4.2) and the F3, F17 pointers; ledger-tails merged

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

docs/fud-ledger.md

@@ -190,6 +190,7 @@ Evidence: `sim/results.md` table E and "What the simulation cannot tell us"; des
 "The aggregator picks which votes go in the certificate once quorum is reached. A block producer carries the certificate it likes. Drop a rival pool's votes from your bitmaps for two hours and its participation factor falls, your share rises."
 
 Status: Closed by rule (3 October 2026), parameter open. Spec section 3.3 Q2 and 3.4.1: participation is computed from every vote seen in blocks over the presence window (votes are block payload), never from the certificates an aggregator chose; the per-block vote bound is O-3.3. Was: Open, experiment scheduled. Sweep (5 October 2026): the block reading is exercised on the fork by harness s3 (block-carried votes give participation; 35 of 35 locked on each of 3 nodes) and s4 (a producer dropping the finality section from 40% of its blocks adds 0 ms to lock latency, 35 locks), bench-log "finality v2 attack harness"; the per-block vote bound and the hostile-aggregator simulation of O-3.3 were run and proposed in round 2 (5 October 2026, night, below; decision at gate 3). Re-run on the `finality-fixes` build under fast time (5 October 2026, 01:13 UTC, `run.mjs s4 --fast-time`, 2 nodes, 223 s): node B locked 14 checkpoints with a 40% vote-dropping producer, median lock latency 1,042 ms against 1,042 ms for the control, 0 ms added. PASS.
+Decision owner: the project lead (gate 3, the spec 3.4.2 proposals). Decision request: `docs/plans/ledger-decisions.md`, item 13 (6 October 2026, 00:05 UTC).
 
 Answer: This is a new finding from writing this ledger and it is not in the design doc. The participation factor is "observed certified votes over P divided by expected votes". If "observed" means votes present in certificates carried in blocks, then whoever aggregates and whoever produces blocks can shape it. Candidate fixes: participation computed from all votes seen in blocks (votes as transactions, not only certificates), or a certificate must include every valid vote the aggregator received above a size bound, or participation falls only on checkpoints where the key's vote appears in no certificate and no block. Goes to the cryptographer for phase 1 and to the gate 3 simulation.
 
@@ -1288,6 +1289,7 @@ Cross-reference (external review, 3 October 2026, night): what holds during a pa
 "Your launcher runs 8 identities per vendor, each with its own vote key. For the vote that is harmless by design. For shard sortition, which ranks every eligible key and takes 8, it is the whole game: 1% of hashrate holds 259 keys above dust. And a few thousand PCs cross your 8,192-voter switch, whose construction is open."
 
 Status: Rule fixed (3 October 2026): spec 7.2 step 2 draws the 8 assignees by weight (blue blocks drawn uniformly from the window, their keys assigned, with the 1-key-versus-1,000-keys test in O-5.1), and spec 3.1 W6 states that keys are free and weight is the only Sybil-resistant quantity. The client's one-key default (O-3.5) and the bitmap size (O-3.12) are proposed in spec 3.4.2 (round 2, 5 October 2026, night, below), decision at gate 3. P8 stays closed. Was: Open, rule change proposed. Reopens P8.
+Decision owner: the project lead (gate 3, the spec 3.4.2 proposals). Decision request: `docs/plans/ledger-decisions.md`, item 13 (6 October 2026, 00:05 UTC).
 
 Answer: Correct. Spec 7.2 step 2 ranks per key and eligibility is 100 blue blocks in 30 days (0.004% of hashrate at one block a second), so a miner with share s holds up to s x 2,592,000 / 100 keys and the draw of 8 is dominated by whoever splits most. `proto-cuda/windows-miner/start-mining.ps1` derives a key per identity (`MINERS` default 8). O-5.1's acceptance test (fastest prover under 25% of shards) does not catch a splitter, who wins by count. Fix: draw the 8 assignees by weight (8 blue blocks uniformly from the window, take their keys), so splitting changes nothing; the client defaults to one key per operator; specify S2 (O-3.5) and the bitmap size (O-3.12) before the count can cross 8,192.
 

docs/plans/ledger-decisions.md

@@ -52,3 +52,7 @@ Question: whether the node carries the SP1 SDK (the verifier inside consensus) o
 
 Question: whether to buy or borrow a discrete AMD card (M8: bit-exactness and the honest rate on RDNA, the one vendor not yet run), a multi-card mixed-generation rig with ROCm (M11: hourly runtime codegen on the rig a farm runs), and a 12 GB mid-range NVIDIA card (P16: the phase 2 proving gate end to end on the card the gate names). Facts: every other vendor and machine class has run (Apple, NVIDIA discrete, AMD integrated, Intel integrated); the ledger's answers on these three items are honest about the gap and nothing an agent can run on this fleet closes them; the public benchmark in January 2027 will also need them for the leaderboard. Recommendation: one discrete AMD card (a 16 GB RDNA 3 or 4 part, approximate class) and one 12 GB NVIDIA card (a 3060-class part) bought for PC 2 before the public benchmark; the multi-card rig borrowed from a farm operator for a week at the HiveOS package's first test rather than bought. Unblocks: M8 and P16 move to "measurement scheduled <date>"; M11 moves to "rig borrowed <date>".
 
+## 13. F3, F17, X5: the three gate-3 parameters proposed in spec 3.4.2 (round 2)
+
+Question: adopt, at gate 3, the three values the ledger-tails round wrote into `docs/spec/03-finality.md` section 3.4.2 as Proposed. Facts, from the fork's encodings and the live devnet's coinbase sizes (3.4.2 item 1): a vote item is 281 bytes, so a checkpoint's 8,192 votes at the S2 switch are 2.3 MB, 4.6x one block's compute mass, and no per-block bound lets one block carry a checkpoint; spread over the 30 blocks of a checkpoint interval the average is 274 votes per block (15.4% of the mass). The bitmap indexes the canonical voter list at one bit per key: 1,024 bytes at 8,192 voters against a 1 MiB wire bound today. The client defaults to 8 identities per large card, 2 per small, 1 on Apple silicon and integrated GPUs, which is why tonight's fleet runs 4.2 vote keys per machine. The hostile-aggregator simulation (scenario O, 3 seeds) shows the attack works under the certificate reading the simulation used until tonight and does nothing under the block reading spec 3.3 Q2 fixes. Recommendation: (a) the per-block vote bound at the value item 2 proposes, sized so a checkpoint's votes fit in its interval with headroom; (b) the bitmap wire bound at 8,192 bytes (65,536 voters, 8x the switch) in place of 1 MiB; (c) the client default of one vote key per machine (not per card or per identity), with the identity count kept as a worker setting that shares the key. Unblocks: O-3.3, O-3.5 and O-3.12 move from Proposed to Decided; the F17 and X5 Sybil arithmetic then rests on a default that matches the rule.
+