From 36bb74452488d636873cedafed5838d767c3d7fe Mon Sep 17 00:00:00 2001 From: igneum-labs <337424239+igneum-labs@users.noreply.github.com> Date: Sun, 4 Oct 2026 14:41:42 +0000 Subject: [PATCH] Ledger: F22 placed after F20 Co-Authored-By: Claude Fable 5.1 --- docs/fud-ledger.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/fud-ledger.md b/docs/fud-ledger.md index 5b520c864..7226265ff 100644 --- a/docs/fud-ledger.md +++ b/docs/fud-ledger.md @@ -26,15 +26,6 @@ Evidence locations referenced below: `docs/bench-log.md`, `proto-metal/TESTS.md` ## 1. Mining and ASIC claims -### F22. Certificates carry 8 to 10 of 12 votes on a healthy network, so locks sit a hair above the floor -"Two of your cloud checkpoints locked at 66.8% against a 66.7% floor with every node connected. One slow aggregator and finality pauses." - -Status: Open, found by the team (4 October 2026, 12-node cloud devnet, second partition run). - -Answer: True as measured. With all 12 miners connected the certificates carried 8 to 10 of 12 votes (66.7 to 89% of total weight at 14:00 UTC); checkpoints 437 and 439 locked at 66.8%. The missing votes are late votes that miss the aggregation window, not absent voters. Experiment: measure vote arrival against the aggregator's cut-off on the cloud network (inter-region RTT up to 289 ms) and on the devnet; candidates are a longer aggregation window, a second aggregation round that folds late votes into the certificate before it is carried, or counting a vote that arrives after the certificate toward the next checkpoint's presence. Owner: finality. - -Evidence: `infra/cloud-devnet/results/2026-10-04/partition-sin-20261004-140305/partition.md`; bench-log "Hetzner partition and hash-step". - ### 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." @@ -1339,6 +1330,15 @@ Answer: Correct on the gap. Spec 4.3 proposes that the seed checkpoint may be th Evidence: spec 4.3 (O-4.3), 3.3.1, 3.5, 3.7 item 2, 3.9. Experiment: O-3.16. Review: external, point 2. +### F22. Certificates carry 8 to 10 of 12 votes on a healthy network, so locks sit a hair above the floor +"Two of your cloud checkpoints locked at 66.8% against a 66.7% floor with every node connected. One slow aggregator and finality pauses." + +Status: Open, found by the team (4 October 2026, 12-node cloud devnet, second partition run). + +Answer: True as measured. With all 12 miners connected the certificates carried 8 to 10 of 12 votes (66.7 to 89% of total weight at 14:00 UTC); checkpoints 437 and 439 locked at 66.8%. The missing votes are late votes that miss the aggregation window, not absent voters. Experiment: measure vote arrival against the aggregator's cut-off on the cloud network (inter-region RTT up to 289 ms) and on the devnet; candidates are a longer aggregation window, a second aggregation round that folds late votes into the certificate before it is carried, or counting a vote that arrives after the certificate toward the next checkpoint's presence. Owner: finality. + +Evidence: `infra/cloud-devnet/results/2026-10-04/partition-sin-20261004-140305/partition.md`; bench-log "Hetzner partition and hash-step". + ### P16. The proving gate can be passed by shrinking the shard "'A mid-range GPU proves a shard in under 20 s.' Your own R2 says: if missed, halve the shard and re-measure. That is the trap. Fix the workload first, measure the whole journey, and have strangers reproduce it."