diff --git a/docs/design/class-v5-stored-state.md b/docs/design/class-v5-stored-state.md index 3103e7b0a..e8647b8fa 100644 --- a/docs/design/class-v5-stored-state.md +++ b/docs/design/class-v5-stored-state.md @@ -4,7 +4,7 @@ ## 0. Progress (kept current for the coordinator) -Clock rule for this page: every time is UK time (BST tonight, UTC+1). The build boxes print CEST (UTC+2) and the harness and miner logs print UTC; both are converted here. Lines written before 23:3x UK from a box clock were corrected by the Mac's completion times (the freeze suite 21:52, the known-failed readings 20:24 and 22:01, the era reading 23:2x). +Clock rule for this page: every time is UK time (UK time tonight, UTC+1). The build boxes print CEST (UTC+2) and the harness and miner logs print UTC; both are converted here. Lines written before 23:3x UK from a box clock were corrected by the Mac's completion times (the freeze suite 21:52, the known-failed readings 20:24 and 22:01, the era reading 23:2x). | Time (UK) | State | |---|---| @@ -305,7 +305,7 @@ Two fixes were on the table, with the rule that the one with the lower rejection The rule taken: `MIN_DISTINCT_RATIO_V5 = 0.995` (igneum-pow `accept.rs`, ab6f980b), applied by `check_indices_v5` on the ratio pass's own run when the candidate's class has the state flag: `site_index_stats` keeps every site's sorted word indices once (the distinct count, the colliding pairs, the most read index with its count), `distinct_ratio_on` names a site under 0.98 as (c'') first, then `hot_item_pass` names a site under 0.995 as (c''') `Reject::HotItemSite` with the ratio and the most read index. No class v4 verdict moves (the key is the state flag), no new sample is drawn, and the per-candidate cost is the sort (c'') already paid plus one linear pass. The exemplar is refused at attempt 2 under class v5; the class v5 draw moves to the next attempt; the class v4 draw still lands on it. The known-failed test `class_v5_hot_set_rule_known_failed_seed_100767` holds all of that and the genesis draws of both classes clearing the floor. The census test `v5_hot_census` (ignored; run by hand on a box) reads over 4,600 seeds of the f8 label space the class v4 accepted programs' minimum-site spread, the count under floors 0.98, 0.99, 0.995, 0.998 and 0.999, the attempts histogram of the class v4 and class v5 draws and the seeds whose v5 draw lands on another attempt: the clean rejection rate and the retried-draw cost of the number. Its reading goes in this section when it lands. -The census paragraph in the form of the crypto lane's attempts census of sub-version 3 (per-candidate rejection 0.68, (a') 83.3 percent of rejections, 0 exhaustions, P(256) 8e-44): class v5's own, over 1,000 seeds of the f8 label space through the chain draw (`v5_attempts_census`, box 2, 23:4x BST, `docs/design/class-v5-harness/v5-attempts-census-1000.log`): 3,219 candidates, 2,219 rejected, per-candidate rejection 0.6893, accepted attempt mean 2.219, 0 exhaustions, P(256 consecutive rejections) 4.4e-42. First failing part per rejected candidate: (a') unfresh source 1,850 (83.4 percent of rejections, 57.5 percent of candidates); (a) stale load 237 (10.7 percent); (b) no injecting write 66 (3.0 percent); (c'') low-entropy site 26 (1.2 percent); (c''') hot-item site 23 (1.0 percent of rejections, 0.7 percent of candidates: the floor's own share, one candidate in 140); (c) saturated 9, constant bit 7, distinct addresses 1 (0.7 percent together); (c') none at first failure. So the rule's cost is class v4's: (c''') adds 0.7 percent to the per-candidate rejection and 0.045 to the accepted attempt mean. +The census paragraph in the form of the crypto lane's attempts census of sub-version 3 (per-candidate rejection 0.68, (a') 83.3 percent of rejections, 0 exhaustions, P(256) 8e-44): class v5's own, over 1,000 seeds of the f8 label space through the chain draw (`v5_attempts_census`, box 2, 23:4x UK, `docs/design/class-v5-harness/v5-attempts-census-1000.log`): 3,219 candidates, 2,219 rejected, per-candidate rejection 0.6893, accepted attempt mean 2.219, 0 exhaustions, P(256 consecutive rejections) 4.4e-42. First failing part per rejected candidate: (a') unfresh source 1,850 (83.4 percent of rejections, 57.5 percent of candidates); (a) stale load 237 (10.7 percent); (b) no injecting write 66 (3.0 percent); (c'') low-entropy site 26 (1.2 percent); (c''') hot-item site 23 (1.0 percent of rejections, 0.7 percent of candidates: the floor's own share, one candidate in 140); (c) saturated 9, constant bit 7, distinct addresses 1 (0.7 percent together); (c') none at first failure. So the rule's cost is class v4's: (c''') adds 0.7 percent to the per-candidate rejection and 0.045 to the accepted attempt mean. The exemplar under class v5 itself (adv-accept, 20:36 UK, logs/adv-accept/v5-exemplar.log on branch adv-accept): the same base program and era drawn as generator 5 (id 2fd83dbae09c366d under 25c8063f, before (c''')), the dataset keyed by the Devnet 3 v5 pack's state stream (11 records, root 7e37a9fb...a311), the unmodified f8 census at 2^24 sequential nonces on day 20730, 589 warps checked against Epoch::hash_warp with 0 mismatches: hot-set test X_f +0.15514 percent at f = 0.1 percent (X/f 1.55, a hot set) against +0.15503 under class v4; top 0.1 percent share 2.0462x against 2.0455x; the same eight hottest items (0x000000 with 29,722 reads, then the other multiples of 2^19); site 6 carries 3.358 percent of its reads into the hot set against 3.350. The state leaf changes every dataset word and the hot set does not move by a part in a thousand: the concentration is the program's register dataflow at site 6 plus the era stride, and any dataset keyed through the same load address inherits it. That is why the floor on the index statistic (which the state does not touch) is the right instrument, and why class v5's dataset gives no cover. @@ -317,4 +317,4 @@ The census reading (box 2, 48 pool cores under lease class v5, 20:42 to 21:03 UK The five programs main named, read by adv-accept at the acceptance's own 2^20 sample (21:35 UK, logs gap-five-d20733.log and gap-five-d20730.log on branch adv-accept): seed 4346 (bbb38e847011c354, 2.24x live) minimum site 2 at 0.9840 and seed 5245 (beaad44840bb9e4e, 1.86x live) site 8 at 0.9831, both refused by the floor; Devnet 3's epoch-0 class v4 program fce15bf61030be57 at site 0 (instruction 3, source r6) 0.9992 (live 0.9993), adv-cache-2's era-fixed-20 (11f9f955b21d56c9) site 11 at 0.9997 and era-drawn-2 (7ceb797d31eedb3e) site 13 at 0.9992: at or above the floor, the residual. Three further hot sets of adv-accept's refused: 106924 at 0.9821, 107022 at 0.9877, and 1738 (33ece54e2df5ea44, attempt 4, X at 0.1 percent +0.102 percent, 1.68x over the window model) at site 13 0.9868 (live 0.9870; log gap-hot3.log), and 170 (53a02a7c9c9b86f3, attempt 4, X at 0.1 percent +0.143 percent, 2.02x) at site 2 0.9880 (live 0.9877; log gap-hot4.log), and 122960 (4be7393ab6c84802, attempt 0, X at 0.1 percent +0.111 percent, 1.54x, the hottest item 0x81ad88 from an all-ones source at site 12, saturated-source share 0.353 percent under the (c') 1 percent) at site 12 0.9824 (live 0.9822, 1.31 percent of the site's reads on indices read 8 or more times; log gap-122960.log), so every live hot set by X_f at or above f adv-accept found (eight, minimum sites 0.9821 to 0.9919) is refused, and of its nine deepest stand-in seeds read live at 2^24 (gap-newlow5.log, gap-deep4.log) six clean programs are refused too (130488 at 0.9898, 19921 at 0.9912, 600738 at 0.9934, 148927 at 0.9814, 150347 at 0.9896, 34501 at 0.9929; top 0.1 percent share 0.9998x to 1.0028x live), one clean passes (602822 at 0.9951) and 29307 at 0.9912 is refused beyond the gate (1.29x): the floor's statistic at 2^20 is usually a thin spread on the live set, not a hot set, which is the 2.4 percent clean rejection's population, and a floor cannot move up to the mild residuals without refusing most clean programs; the three mild concentrations it misses are worth about 1.0004x to a chip. The record's sentence (the defender's ruling, 21:4x UK): the freeze commit CLOSES THE HOT-SET HALF of the class and NOT the class: the floor refuses every program whose live hot set passes X_f at or above f that any lane measured (seven of adv-accept's, 0.9821 to 0.9919 at the minimum site, and 4346, 5245), and misses the three milder concentrations (top 0.1 percent share 1.26x to 1.45x of control, 0.03 to 0.1 percent of a hash's reads each, the shadow block's last write to the load's source register as the mechanism: a mul, a mulhi, a sub), Devnet 3's own first program among them, whose site-0 product low-bit law moves the distinct count by 0.08 percent: inside the clean population's spread at 2^20 (adv-accept's clean 1st percentile about 0.9993 on 29,032 programs), so no floor that keeps the clean rejection rate near 2.4 percent reaches it; the residual's prevalence is 3 of 432 load sites in adv-cache-2's census and its chip gain under 1.001x; its lever is a value-level source test at live scale or a per-site hot-item test, not a ratio, routed to the next class as a named item. Devnet 3's first class v5 program therefore draws the same (e5a4ac5978462156, attempt 0; the (c''') CLI on build-1 at 21:08 UK confirms). The residual's chip value: a hot table serving 0.1 percent of one site's reads is 1/16 of that over the program's loads, under the 1.067x bound of AP-F8-1 by two orders; its instrument, if main wants it closed, is a shadow-block draw rule (the last write before a load's source may not be a mul, mulhi or sub of the same register: a rule in the draw, not the acceptance), owed as a named row below, not tonight's object. -Main's sentence on the record (23:4x BST), verbatim: "eight of eight hot sets refused; the diffuse era-stride excess, bounded under 0.1 percent of a hash's reads per site, is not caught by the floor and is the next class's test." The reading under it. What the floor does not reach, named (corrected 23:3x UK by the era reading below; the first form of this sentence put the bound at "a top-0.1-percent share under about 1.3x", which was the wrong instrument's number): the distinct-index count at 2^20 reads concentration on FEW word indices (adv-accept's hot sets put about 3 percent of a site's reads on 512 indices, the multiples of 2^19, so the collision count moves by thousands and the ratio falls to 0.98 to 0.992), not a diffuse excess over the top 0.1 percent of items (16,384 items, 262,144 word indices: a 1.5x share there is about +0.08 percent of a site's reads spread over them, moving the distinct count by a few hundred, inside the clean spread). The era reading (box 2, 23:2x UK, `class-v5-harness/v5-listed-adv-cache-2-full.log`; adv-cache-2's census programs at their table attempts, igneum-pow 73daadc2): 0 of 29 refused, every class v5 draw on the class v4 attempt; the six over 1.2x read era-drawn-2 (1.2657x) site 13 0.9992, era-drawn-10 (1.2257x, R 22) site 7 0.9995, era-drawn-15 (1.5115x) site 14 0.9965, era-drawn-17 (1.2139x, R 11) site 0 0.9996, era-drawn-20 (1.2234x, R 29) site 11 0.9996, era-fixed-20 (1.2624x, devnet era) site 11 0.9997; the seven in the 1.04x to 1.2x band 0.9986 to 0.9998; the clean ones 0.9999 to 1.0000; the devnet-era controls of the biased pairs 0.9996 to 0.9999. So the floor closes the few-item hot-set class (eight of eight) and none of the era-stride diffuse class (a product's biased low bits placed into the index by the era's stride rotation R; hidden on the devnet by R = 29); that class is the next class's row: the per-site item-share test at live scale, or a draw rule on R and the shadow block's last write to a load's source. Its chip value is bounded by its own diffuseness: a hot table of the top 0.1 percent of items (1 MiB) serves 1.5 x 0.16 percent of one site's reads, 1/16 of that over the program's loads, about 1.0024x at the worst site read, under the AP-F8-1 bound by an order; the full 61-row reading (23:5x BST, `class-v5-harness/v5-listed-adv-cache-2-full.log`: the two real programs, 27 drawn-era, 32 devnet-era) reads 0 of 61 refused, every class v5 draw on the class v4 attempt; era-drawn-28 (1.7451x, R 15, the worst of adv-cache-2's census) reads site 15 at 0.9969 and era-drawn-25 (1.3571x, R 21) site 11 at 0.9994, both over the floor, so the diffuse class's worst member sits 0.0019 over the line while the few-item hot sets sit 0.003 to 0.013 under it; adv-accept's eight live hot sets sat at stride rotations 28, 19, 29, 29, 29, 11, 30, 10, so the two classes overlap in R and differ in shape, not in era. +Main's sentence on the record (23:4x UK), verbatim: "eight of eight hot sets refused; the diffuse era-stride excess, bounded under 0.1 percent of a hash's reads per site, is not caught by the floor and is the next class's test." The reading under it. What the floor does not reach, named (corrected 23:3x UK by the era reading below; the first form of this sentence put the bound at "a top-0.1-percent share under about 1.3x", which was the wrong instrument's number): the distinct-index count at 2^20 reads concentration on FEW word indices (adv-accept's hot sets put about 3 percent of a site's reads on 512 indices, the multiples of 2^19, so the collision count moves by thousands and the ratio falls to 0.98 to 0.992), not a diffuse excess over the top 0.1 percent of items (16,384 items, 262,144 word indices: a 1.5x share there is about +0.08 percent of a site's reads spread over them, moving the distinct count by a few hundred, inside the clean spread). The era reading (box 2, 23:2x UK, `class-v5-harness/v5-listed-adv-cache-2-full.log`; adv-cache-2's census programs at their table attempts, igneum-pow 73daadc2): 0 of 29 refused, every class v5 draw on the class v4 attempt; the six over 1.2x read era-drawn-2 (1.2657x) site 13 0.9992, era-drawn-10 (1.2257x, R 22) site 7 0.9995, era-drawn-15 (1.5115x) site 14 0.9965, era-drawn-17 (1.2139x, R 11) site 0 0.9996, era-drawn-20 (1.2234x, R 29) site 11 0.9996, era-fixed-20 (1.2624x, devnet era) site 11 0.9997; the seven in the 1.04x to 1.2x band 0.9986 to 0.9998; the clean ones 0.9999 to 1.0000; the devnet-era controls of the biased pairs 0.9996 to 0.9999. So the floor closes the few-item hot-set class (eight of eight) and none of the era-stride diffuse class (a product's biased low bits placed into the index by the era's stride rotation R; hidden on the devnet by R = 29); that class is the next class's row: the per-site item-share test at live scale, or a draw rule on R and the shadow block's last write to a load's source. Its chip value is bounded by its own diffuseness: a hot table of the top 0.1 percent of items (1 MiB) serves 1.5 x 0.16 percent of one site's reads, 1/16 of that over the program's loads, about 1.0024x at the worst site read, under the AP-F8-1 bound by an order; the full 61-row reading (23:5x UK, `class-v5-harness/v5-listed-adv-cache-2-full.log`: the two real programs, 27 drawn-era, 32 devnet-era) reads 0 of 61 refused, every class v5 draw on the class v4 attempt; era-drawn-28 (1.7451x, R 15, the worst of adv-cache-2's census) reads site 15 at 0.9969 and era-drawn-25 (1.3571x, R 21) site 11 at 0.9994, both over the floor, so the diffuse class's worst member sits 0.0019 over the line while the few-item hot sets sit 0.003 to 0.013 under it; adv-accept's eight live hot sets sat at stride rotations 28, 19, 29, 29, 29, 11, 30, 10, so the two classes overlap in R and differ in shape, not in era. diff --git a/docs/fud-ledger.md b/docs/fud-ledger.md index ee283fcba..5f0fae04f 100644 --- a/docs/fud-ledger.md +++ b/docs/fud-ledger.md @@ -1845,7 +1845,7 @@ The founder's decision of 4 October 2026: the total-weight floor of Q3 is 2/3, n ### M24. Your two-lane controller oscillates for an hour when a second miner joins mid-epoch "Watched your devnet this morning. The second 5090 came in at 10:12 and the difficulty never settled: 102M to 164M for forty minutes, 54 to 81 blocks a minute, three or four clamp steps stacked inside a second. Your fast lane and your slow lane disagree by a hair under the trigger and the rule flips between them every two minutes. One card joining is the mildest event a chain can see." -Status: Rolled out (4 October 2026, 18:37 BST): rule v2 activated on the live devnet at DAA 33,000 by the height switch after a 12-node cloud rehearsal (settle 157 to 272 s, no swing); node 1, the seed, the observer and the three app machines crossed the height on one chain with no fork and no restart of the chain (`docs/bench-log.md`, "difficulty rule v2 activated"). Still owed: the first v2 measurement on the devnet's own two-large-miner regime once PC 2 is back from proving. Was: Fix built, pending rollout (4 October 2026). +Status: Rolled out (4 October 2026, 18:37 UK): rule v2 activated on the live devnet at DAA 33,000 by the height switch after a 12-node cloud rehearsal (settle 157 to 272 s, no swing); node 1, the seed, the observer and the three app machines crossed the height on one chain with no fork and no restart of the chain (`docs/bench-log.md`, "difficulty rule v2 activated"). Still owed: the first v2 measurement on the devnet's own two-large-miner regime once PC 2 is back from proving. Was: Fix built, pending rollout (4 October 2026). Answer: Correct, measured on the live chain and reproduced in the simulator (`docs/analysis/difficulty-2026-10-04-oscillation.md`). The cause is the reference lane: spec 2.3 of 3 October gave it the whole epoch, so a hash-rate step inside an epoch left it polluted by the pre-step blocks for the rest of the hour; the short lane read the true rate 11 to 25% above it, the 25% trigger flipped between the two on the short lane's noise, and the per-block clamps turned every flip into a ramp (3% a block up, 10% a block down). The DAG replay (`sim/difficulty/sim.py --live`, miners on two nodes with `igneum-miner`'s template staleness, GHOSTDAG, the rule as the node runs it) reproduces the record: std of log difficulty 0.115 against 0.134, 4.3 peaks of 1.31x against 4 of 1.37x, 104M to 169M against 102M to 164M, 54 to 77 blocks a minute against 54 to 81. The brief's five candidates (longer short lane, 3% ease clamp, one clamp per DAA second, hysteresis, median of three) each leave it between 0.09 and 0.13 because none of them cleans the reference lane. Rule v2 caps the reference lane at the newest 600 DAA score of the epoch (the epoch lane only; Kaspa's sampled window is not consulted): 0.026 with 0 lane flips and the target on the true level (142.6M against 139M) on all three seeds; the chain-only simulator agrees (0.14 to 0.19 against 0.02 to 0.08). Cost on the synthetic set (seed 7): steady std of the block rate 0.049 against 0.038 (blocks per minute CV unchanged, 0.130 against 0.135), the 50x step-up settles in 65.5 s against 61.7 s, the 50x step-down 753 s against 629 s, hops slightly faster, the polluted window's overshoot halved. Under attack (`attacks.py`, seeds 7 to 9): the greedy hopper gains one more point (at most +2.5% against +1.5%), the forger's drift falls to within 1% (worst seed 1.5% against 2.7%), the pulsed rental, the epoch games and the polluted window are unchanged, the 50x step-down is 8% slower and the steady estimate a quarter noisier. Built behind a height switch, `difficulty_v2_activation_daa` (a consensus parameter, default never, set by the override file), so the devnet moves to v2 at a chosen DAA score on the same chain. The epoch boundary itself clears the pollution, which the live chain showed at 11:02 UTC (DAA 7,200: within 1.3% per minute from 11:07 with no flips, the hash rate having also stepped down there). @@ -1995,7 +1995,7 @@ Fix (5 October 2026, night): the remaining points. The GET that acks: `GET inbox ### G12. The PoW schedule comes from the environment on every network, including mainnet "Your mainnet gate refuses the override file. It does not refuse `IGNEUM_POW_EPOCH_BLOCKS`. A node without a file installs the schedule from the environment and `Params.pow_epoch_blocks` is never consulted." -Status: Fixed (rolled out 5 October 2026, 0.3.5: fork 20139145 = `finality-fixes` 6aa69a45 + `fud-consensus` 977db931 + `m20-pruning` d35b00cf + the miner branches, cut 07:33 BST, `docs/plans/release-0.3.5.md` 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, `docs/plans/release-0.3.6.md` 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch `fud-consensus`, local worktree `vendor/igneum-node-fud`, no remote; main repo branch `fud-consensus`). Was: Open (4 October 2026). +Status: Fixed (rolled out 5 October 2026, 0.3.5: fork 20139145 = `finality-fixes` 6aa69a45 + `fud-consensus` 977db931 + `m20-pruning` d35b00cf + the miner branches, cut 07:33 UK, `docs/plans/release-0.3.5.md` 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, `docs/plans/release-0.3.6.md` 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch `fud-consensus`, local worktree `vendor/igneum-node-fud`, no remote; main repo branch `fud-consensus`). Was: Open (4 October 2026). Sweep (5 October 2026, evening): measurement line: every node on the line prints `Consensus params digest: f10a4eab...` at start (node logs of PC 1, PC 2, the Mac, Sam's Mac and the US laptop, 5 October 2026, the digest with difficulty 33,000 and proving 84,100), and the environment variables have no reader left in the miner (`IGNEUM_POW_DAY_MS` moved into the template, M25 confirmed the day-mismatch rejection on 5 October). No mainnet node has been started; the mainnet refusal line is covered by the unit test `env_pow_schedule_is_devnet_and_simnet_only` only. @@ -2031,9 +2031,9 @@ Fix (5 October 2026, night): `TZ=UTC` in every commit path the tooling owns: `to ### X18. Two nodes with two override files connect, and only some mismatches fork "Your handshake compares the network name and nothing else. A PoW or difficulty mismatch forks and bans; a `finality` mismatch is a WARN; `rollout-v2.sh` throws the finality block away when it writes the file; the app rewrites the packaged file on every start." -Status: Fixed (rolled out 5 October 2026, 0.3.5: fork 20139145 = `finality-fixes` 6aa69a45 + `fud-consensus` 977db931 + `m20-pruning` d35b00cf + the miner branches, cut 07:33 BST, `docs/plans/release-0.3.5.md` 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, `docs/plans/release-0.3.6.md` 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch `fud-consensus`, main repo branch `fud-consensus`). Was: Open (4 October 2026). +Status: Fixed (rolled out 5 October 2026, 0.3.5: fork 20139145 = `finality-fixes` 6aa69a45 + `fud-consensus` 977db931 + `m20-pruning` d35b00cf + the miner branches, cut 07:33 UK, `docs/plans/release-0.3.5.md` 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, `docs/plans/release-0.3.6.md` 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch `fud-consensus`, main repo branch `fud-consensus`). Was: Open (4 October 2026). -Sweep (5 October 2026, evening): measurement line, live: the digest refused a real mismatch the morning it shipped. A hand node restarted early with another `proving_v0_activation_daa` was refused by every peer for 20 minutes (bench-log "live devnet: the first shards proven"); the node logs carry 115 `consensus params digest mismatch` lines on PC 1, 46 on PC 2 and 56 on the Mac between 08:15 and 08:35 BST on 5 October 2026 (`Refusing peer ...: consensus params digest mismatch, local f10a4eab... remote a6da35e8...`), none since. Still open from this entry: the digest-less allowance on devnet and simnet (to remove), `rollout-v2.sh` still writes the file as two fields (R4.1.12). +Sweep (5 October 2026, evening): measurement line, live: the digest refused a real mismatch the morning it shipped. A hand node restarted early with another `proving_v0_activation_daa` was refused by every peer for 20 minutes (bench-log "live devnet: the first shards proven"); the node logs carry 115 `consensus params digest mismatch` lines on PC 1, 46 on PC 2 and 56 on the Mac between 08:15 and 08:35 UK on 5 October 2026 (`Refusing peer ...: consensus params digest mismatch, local f10a4eab... remote a6da35e8...`), none since. Still open from this entry: the digest-less allowance on devnet and simnet (to remove), `rollout-v2.sh` still writes the file as two fields (R4.1.12). The fix: `Params::consensus_digest()` (BLAKE2b-256, domain `IgneumParamsDigest`, every consensus field in a fixed tagged order: genesis, difficulty, mass and lane limits, blockrate, crescendo, the ten finality fields, the PoW schedule, the three activation heights; not the dead `timestamp_deviation_tolerance`, not seeders or ports; spec 2.8 lists it). The version message carries it (`paramsDigest`, field 11); `initialize_connection` refuses a peer whose digest differs with `ProtocolError::ParamsDigestMismatch` and one WARN naming both digests before any flow is registered, so a finality-only mismatch, which used to connect and WARN "names N voters" after the fact, never connects. A peer with no digest (an older build) is refused on mainnet and testnet and let in with a WARN on devnet and simnet while the devnet rolls (an allowance to remove afterwards). The node prints its digest at start. Unit test `consensus_digest_covers_every_consensus_field_and_nothing_else`. Measured (`docs/bench-log.md`, "round-4 consensus items", digest run; `tools/finality-attacks/fud.mjs digest`, fast time, ports 29400+): a listener on the shared fast-time override and a dialler whose finality block differs by one DAA second of window: the dialler was refused at the handshake on both sides ("Refusing peer ...: consensus params digest mismatch, local 4bf7... remote 7a40..." on the listener, the reject message on the dialler), 0 peers after 25 s on both; a third node on the shared override connected in 1 s. Control on the finality-fixes build 6aa69a45: the mismatched dialler connected (1 peer, no line). `rollout-v2.sh` still rewrites the file as two fields and the app still rewrites the packaged file (R4.1.12): with the digest both now fail loudly at the handshake instead of forking; the merge fix for the script is not done tonight. @@ -2044,7 +2044,7 @@ Evidence: the files above. Experiment: two nodes on different files; the handsha ### F23. The equivocation ban is node-local, so honest nodes refuse each other's certificates "Evidence detected from an RPC vote stamps the sink's DAA; evidence carried in a block stamps the carrier's DAA. Two honest nodes hold different `until` for the same key, their voter lists differ by one at every checkpoint between the two expiries, and `voter_count` refuses the other's certificate for good." -Status: Fixed (rolled out 5 October 2026, 0.3.5: fork 20139145 = `finality-fixes` 6aa69a45 + `fud-consensus` 977db931 + `m20-pruning` d35b00cf + the miner branches, cut 07:33 BST, `docs/plans/release-0.3.5.md` 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, `docs/plans/release-0.3.6.md` 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch `fud-consensus`, main repo branch `fud-consensus`). Was: Open (4 October 2026); reproduced by the red team the same evening on the stock s1 scenario (n0 kept the ban until DAA 726 against 239 on n1 and n2, 9 and 3 to 4 certificates refused "names N voters"). +Status: Fixed (rolled out 5 October 2026, 0.3.5: fork 20139145 = `finality-fixes` 6aa69a45 + `fud-consensus` 977db931 + `m20-pruning` d35b00cf + the miner branches, cut 07:33 UK, `docs/plans/release-0.3.5.md` 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, `docs/plans/release-0.3.6.md` 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch `fud-consensus`, main repo branch `fud-consensus`). Was: Open (4 October 2026); reproduced by the red team the same evening on the stock s1 scenario (n0 kept the ban until DAA 726 against 239 on n1 and n2, 9 and 3 to 4 certificates refused "names N voters"). Sweep (5 October 2026, evening): measurement line, live: the persisted finality state converted on the upgrade on every machine (`Finality: state blob of layout 1 read and converted (0 evidence records)` once on PC 1, PC 2, the Mac, Sam's Mac and the US laptop, 5 October 2026), no node lost its locks, and in the 10 hours to 15:45 UTC the node logs of the five app machines carry 0 certificates refused "names N voters", 0 CONFLICTING and 0 EQUIVOCATION lines against 5,243 LOCKED lines (intake query over every `nodelog-*` upload, split per line server-side). No equivocation has happened on the live devnet, so the ban path itself is exercised only by the fast-time run below (`fud.mjs ban`: voter lists agree on three nodes at every index, 0 refusals). @@ -2059,9 +2059,9 @@ Red-team run, 4 October 2026 (evening, the 0.3.4 finality-fixes build with rule ### F24. A checkpoint determination is never revisited "After a reorg deeper than `checkpoint_depth`, the node's record for that index names a block off its chain. Every certificate the network forms for that index is refused as conflicting, with no equivocation anywhere, and the node voted for a block that is not on its chain." -Status: Fixed (rolled out 5 October 2026, 0.3.5: fork 20139145 = `finality-fixes` 6aa69a45 + `fud-consensus` 977db931 + `m20-pruning` d35b00cf + the miner branches, cut 07:33 BST, `docs/plans/release-0.3.5.md` 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, `docs/plans/release-0.3.6.md` 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch `fud-consensus`, main repo branch `fud-consensus`). Was: Open (4 October 2026); extends F7 and C4. +Status: Fixed (rolled out 5 October 2026, 0.3.5: fork 20139145 = `finality-fixes` 6aa69a45 + `fud-consensus` 977db931 + `m20-pruning` d35b00cf + the miner branches, cut 07:33 UK, `docs/plans/release-0.3.5.md` 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, `docs/plans/release-0.3.6.md` 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch `fud-consensus`, main repo branch `fud-consensus`). Was: Open (4 October 2026); extends F7 and C4. -Sweep (5 October 2026, evening): measurement line, live: the re-determination fired on the real devnet and left no hole. Checkpoints 2970 and 2971 were re-determined at 10:56:44 to 10:56:45 BST on 5 October 2026 on PC 1, PC 2 and the Mac at once (`Finality: checkpoint 2971 re-determined: block bb4aa204...` on all three, 7 / 8 / 4 re-determined lines per machine over the day including the first-start ones at indices 704 to 722), with 0 CONFLICTING lines and 0 refusals anywhere in the 10 hours to 15:45 UTC, and the three nodes' later locks agree (the console's last lock #3646 at 15:46 UTC). Before this fix the same event would have logged CONFLICTING for every certificate at the moved index and left the index unlocked on the losing side. +Sweep (5 October 2026, evening): measurement line, live: the re-determination fired on the real devnet and left no hole. Checkpoints 2970 and 2971 were re-determined at 10:56:44 to 10:56:45 UK on 5 October 2026 on PC 1, PC 2 and the Mac at once (`Finality: checkpoint 2971 re-determined: block bb4aa204...` on all three, 7 / 8 / 4 re-determined lines per machine over the day including the first-start ones at indices 704 to 722), with 0 CONFLICTING lines and 0 refusals anywhere in the 10 hours to 15:45 UTC, and the three nodes' later locks agree (the console's last lock #3646 at 15:46 UTC). Before this fix the same event would have logged CONFLICTING for every certificate at the moved index and left the index unlocked on the losing side. The fix: after every virtual change, every unlocked checkpoint record whose block is no longer a chain ancestor of the sink is determined again on the new chain ("re-determined" log line); the certificate held over the old block is dropped, the fold clock restarts. A certificate over a block other than the node's determination at an unlocked index (or at an index not yet determined, up to 64 ahead) is no longer logged CONFLICTING and discarded: it is held pending (4 per index) and verified when a re-determination names its block; a block that cannot be the index's checkpoint on any chain (C1 as a function of the DAG: blue score under the target, or the selected parent's not) is refused outright. CONFLICTING now means what 3.11.4 says: a certificate against a LOCK. The certificate verification itself is unchanged; a locked index is never re-determined (fork choice keeps the chain through it). The node's own keys do not re-vote at a re-determined index (that would be equivocation); the lock there comes from the network's certificate, which is the point. Unit tests `reorg_past_an_unlocked_checkpoint_re_determines_it_and_verifies_the_pending_certificate` and `a_locked_checkpoint_pins_the_chain_and_a_certificate_against_it_conflicts`. Measured (`docs/bench-log.md`, "round-4 consensus items", reorg run; `fud.mjs reorg`, n0 with 30% of the weight cut off for 180 s while the 70% side kept locking, then healed): on the `fud-consensus` build n0 re-determined its own 1 to 2 split indices on the majority chain, verified the pending certificates at determination (2 in the final pass), logged 0 CONFLICTING and 0 refusals, and ended with every index the majority locked locked on the same block (0 disagreeing). Control on the finality-fixes build: n0 refused 3 certificates "is for X, this node's checkpoint is Y" and never locked indices 8 and 9 that the majority locked (the permanent hole of this entry), 0 disagreeing because the hole is not a lock. The final pass also found that a chain which becomes the sink at a lower blue score than the old one (more blue work per block after the split's difficulty drift) re-determined index 9 at a sink below its depth, to a block below the target: fixed the same night (an index the new chain has not reached is un-determined and determined again when it has; unit test `a_shallower_sink_un_determines_the_indices_it_cannot_reach`) and re-run (`reorg-final2`, fork 977db931): the majority locked nothing during the split this time (Poisson again), n0 re-determined its one split index, verified 1 pending certificate at determination, 0 CONFLICTING, 0 refused, 0 disagreeing, no record below its target, every index the majority locked locked on n0 too. The red team's own reproductions on the new build (`tools/finality-attacks/redteam/rtfin.mjs`, fin-attacks miner at 6 blocks/s): `f24c` (3/3 split, 16 s cut) PASS with 0 refusals, 0 CONFLICTING, 0 stuck indices, 0 disagreeing; `f24b` (4/2 split, 24 s cut) FAIL on both builds for a reason outside F24: at 6 blocks/s the DAA score advances 6 a second, so the 24-s cut is 144 DAA, longer than the 120-DAA weight window and the 60-DAA merge depth; the two chains cannot merge at the heal and each side's table holds only its own keys (n1's lone locks read "100.0% of total, 100.0% of the table frozen at lock 39"), which is the partition longer than a window that spec 3.7 item 9 states and F21 conceded, not a reorg. The scenario's "under merge depth" assumes 1 DAA a second. Spec 3.2 C1 and C4, and the 3.10 rows, state the rule. @@ -2211,7 +2211,7 @@ Evidence: the files above. ### M30. A block or transaction flood grows the 0.3.4 node by hundreds of megabytes in a minute "On the 3 October ordering-layer node (no execution layer) the resource-exhaustion scenario grew RSS by 4, 11 and 14 MB and the 50x block flood by 30 MB. On the 0.3.4 build, same harness, same scenarios, same 60 s: template flood +6 MB, submit flood +269 MB, mempool flood +270 MB, block flood 302 to 1,082 MB on both nodes (567 MB at 10 s, 824 MB at 20 s). The harness calls it a pass because its bound is baseline + 512 MB; a peer that keeps going is not bounded by the harness." -Status: Fixed (rolled out 5 October 2026, 0.3.5: fork 20139145 = `finality-fixes` 6aa69a45 + `fud-consensus` 977db931 + `m20-pruning` d35b00cf + the miner branches, cut 07:33 BST, `docs/plans/release-0.3.5.md` 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, `docs/plans/release-0.3.6.md` 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch `fud-memory`, merged into `fud-consensus`; main repo branch `fud-memory`, merged into `fud-consensus`). Was: Open (4 October 2026, red-team run). +Status: Fixed (rolled out 5 October 2026, 0.3.5: fork 20139145 = `finality-fixes` 6aa69a45 + `fud-consensus` 977db931 + `m20-pruning` d35b00cf + the miner branches, cut 07:33 UK, `docs/plans/release-0.3.5.md` 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, `docs/plans/release-0.3.6.md` 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch `fud-memory`, merged into `fud-consensus`; main repo branch `fud-memory`, merged into `fud-consensus`). Was: Open (4 October 2026, red-team run). Sweep (5 October 2026, evening): measurement line, live: cache builds now equal node restarts, not epoch rolls. In the 10 hours to 15:45 UTC on 5 October 2026 the node logs show 5 `PoW cache built` lines on PC 1, 5 on PC 2, 8 on the Mac and 1 on Sam's Mac, each at a node start (the 0.3.5, 0.3.6, 0.3.7 and 0.3.8 restarts and the proving-activation restart), and none at the hourly boundaries: the swaps at DAA 108,000 (14:29 UTC) and 111,600 (15:29 UTC) built no cache on any machine (the last build on PC 1 is the 0.3.8 restart at 13:42 UTC). The 0.3.4 engine built one 256 MiB cache per hourly roll (about 270 MB an hour of growth on the app node). The 30 MB per 1,000 blocks of non-cache growth and the unbounded `ExecState.records` stay as stated. Serious: a single peer at 50 blocks/s or 500 transactions/s is the devnet's own fast-miner event, and a node that grows 13 MB/s under it runs out of memory in minutes on the 2 to 4 GB cloud nodes. @@ -2224,7 +2224,7 @@ Evidence: `/tmp/igneum-redteam-ord/results/s6-exhaustion.json` and `s7-flood.jso ### M31. The 0.3.4 node cannot produce a block template on mainnet, testnet or simnet parameters "`getBlockTemplate` on a `--simnet` node from the finality-fixes build answers every call with `Coinbase payload is above max length (204). Try to shorten the extra data.` and the network never makes a block. The coinbase of this build carries the vote-key reveal, the proof-record section and the finality section; only `DEVNET_PARAMS` was raised to `MAX_COINBASE_PAYLOAD_LEN_WITH_FINALITY` (16,384). `MAINNET_PARAMS`, `TESTNET_PARAMS` and `SIMNET_PARAMS` still carry Kaspa's 204 (`consensus/core/src/config/params.rs:705, 766, 828` against `:900`)." -Status: Fixed (rolled out 5 October 2026, 0.3.5: fork 20139145 = `finality-fixes` 6aa69a45 + `fud-consensus` 977db931 + `m20-pruning` d35b00cf + the miner branches, cut 07:33 BST, `docs/plans/release-0.3.5.md` 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, `docs/plans/release-0.3.6.md` 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch `fud-consensus`). Was: Open (4 October 2026, red-team run). Serious for anything that is not the devnet: a mainnet or testnet genesis on these parameters cannot be mined by a voting miner at all; harmless on the live devnet, whose parameters carry the raise. +Status: Fixed (rolled out 5 October 2026, 0.3.5: fork 20139145 = `finality-fixes` 6aa69a45 + `fud-consensus` 977db931 + `m20-pruning` d35b00cf + the miner branches, cut 07:33 UK, `docs/plans/release-0.3.5.md` 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, `docs/plans/release-0.3.6.md` 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch `fud-consensus`). Was: Open (4 October 2026, red-team run). Serious for anything that is not the devnet: a mainnet or testnet genesis on these parameters cannot be mined by a voting miner at all; harmless on the live devnet, whose parameters carry the raise. Sweep (5 October 2026, evening): measurement line: the unit test `largest_coinbase_fits_on_every_network` passed in every 0.3.5 suite run (`cargo test -p kaspa-consensus-core`, 101 passed on the 0.3.6 fork tip a11455e7 on 5 October 2026, `docs/plans/release-0.3.6.md` 3b) and the testnet identity `igneum-testnet-1` adopted the same morning carries the raised limit with every switch at 0, so the first testnet genesis is mineable by a voting miner; no simnet network has been started since the cut, so the template line on simnet is covered by the test, not a run. @@ -2512,7 +2512,7 @@ Owed (recorded, not run, by the founder's word): G2 (the CPU verifier on 1,024 h Owed (recorded, not run, by the founder's word): G2 (the CPU verifier on 1,024 hashes per card) on the amended stream; G3 (the Metal fuzz, edge, stats and determinism runs) on the amended stream; the hash-rate ladder re-measure on the M5 Max and the RTX 5090 (the amendment changes the base program's source draws, not the op mix or the load count, so the latency-bound rows of `docs/analysis/latency-shadow-2026-10-06.md` are expected to hold within their spread; unmeasured); AMD (the RX 9070 XT, PC 1); the 2019-class verifier core (O-1.14); F8's phase E (the 64-seed dynamic census) on the amended stream, which is the attack-pass lane's and the test of the per-op table. The row reads FIXED-AND-PASSED only after phase E passes against the amended class. -Status: Fixed in part, finding bounded, stated (7 October 2026, night, the Counter ASIC lane's words): class v4 sub-version 3 (igneum-pow 017e7037, the audit-freeze tag) is frozen with the dataflow rule, the shared-operand rule, the 0.98 ratio and the total draw; the in-house pass's F8 re-gate reads 60 of 64 seeds under 1.2x with the four-seed tail accepted by the coordinator as the window model's unattributed residue (no chip consequence); the pass then attributed the class by value (eight live hot sets at 1.54x to 2.24x in the lowest 30 of 29,032 accepted programs, each about 1 MB of items at 0.3 percent of reads, 1.002x to a chip); class v5 (1c420786, frozen 21:53 UK) carries the fix as rule (c'''), the per-site distinct-index floor at 0.995 on the state flag (its census refuses 2.435 percent of accepted programs; seven of seven live hot sets refused at 0.9821 to 0.9919; the eighth's ratio owed tonight), with a named residual (three mild shadow-block-written concentrations at 0.9992 to 0.9997, about 1.0004x, a value-level test in the next class); the record is `docs/plans/counter-asic-3-status.md` section 7c and the class v5 design's section 14. The eighth live hot set (seed 122960, id 4be7393ab6c84802, the deepest found: X_f +0.111 percent, 1.54x the window model, its hottest item at 475,616 reads from an all-ones source) reads minimum site 12 at 0.9824 at the acceptance's own 2^20 sample (live 0.9822), refused by class v5's (c''') floor at 0.995; so the floor refuses eight of eight live hot sets by X_f at or above f found in the tail of 88,051 accepted programs (minimum sites 0.9821 to 0.9919) against 0 hot sets in 20 random programs; what it misses stays the three mild shadow-block-written concentrations at 0.9992 to 0.9997 (Devnet 3's first program among them), about 1.0004x to a chip, the value-level test in the next class (22:41 BST; the logs under `docs/analysis/cryptanalysis/logs/adv-accept/` on branch adv-accept; the v5 design's section 14). The RTX 5080 grid's knee is not in tonight; X37 keeps the 5080's stock premium only. +Status: Fixed in part, finding bounded, stated (7 October 2026, night, the Counter ASIC lane's words): class v4 sub-version 3 (igneum-pow 017e7037, the audit-freeze tag) is frozen with the dataflow rule, the shared-operand rule, the 0.98 ratio and the total draw; the in-house pass's F8 re-gate reads 60 of 64 seeds under 1.2x with the four-seed tail accepted by the coordinator as the window model's unattributed residue (no chip consequence); the pass then attributed the class by value (eight live hot sets at 1.54x to 2.24x in the lowest 30 of 29,032 accepted programs, each about 1 MB of items at 0.3 percent of reads, 1.002x to a chip); class v5 (1c420786, frozen 21:53 UK) carries the fix as rule (c'''), the per-site distinct-index floor at 0.995 on the state flag (its census refuses 2.435 percent of accepted programs; seven of seven live hot sets refused at 0.9821 to 0.9919; the eighth's ratio owed tonight), with a named residual (three mild shadow-block-written concentrations at 0.9992 to 0.9997, about 1.0004x, a value-level test in the next class); the record is `docs/plans/counter-asic-3-status.md` section 7c and the class v5 design's section 14. The eighth live hot set (seed 122960, id 4be7393ab6c84802, the deepest found: X_f +0.111 percent, 1.54x the window model, its hottest item at 475,616 reads from an all-ones source) reads minimum site 12 at 0.9824 at the acceptance's own 2^20 sample (live 0.9822), refused by class v5's (c''') floor at 0.995; so the floor refuses eight of eight live hot sets by X_f at or above f found in the tail of 88,051 accepted programs (minimum sites 0.9821 to 0.9919) against 0 hot sets in 20 random programs; what it misses stays the three mild shadow-block-written concentrations at 0.9992 to 0.9997 (Devnet 3's first program among them), about 1.0004x to a chip, the value-level test in the next class (22:41 UK; the logs under `docs/analysis/cryptanalysis/logs/adv-accept/` on branch adv-accept; the v5 design's section 14). The RTX 5080 grid's knee is not in tonight; X37 keeps the 5080's stock premium only. ### AP-F8-3. The deterministic last-resort program is handed to the chain unchecked, and the rule would refuse 9.0 percent of such programs @@ -2526,7 +2526,7 @@ Status: Fixed in class v5 (8ca66afa, 0.3.25's igneum-pow line); sub-version 3's Finding (7 October 2026, the in-house pass adv-cache-2, report-chained-cache-2.md section 2.3 on branch adv-cache-2, 2^23 nonces per program on day 20730): under drawn eras, 13 of 27 class v4 sub-version 3 programs carry a load site whose top 0.1 percent of items take over 1.04x the window model's share (8 over 1.2x: era-drawn-2 1.2657x, -10 1.2257x, -15 1.5115x, -17 1.2139x, -20 1.2234x, -25 1.3571x, -28 1.7451x, era-fixed-20 1.2624x), against 2 of 32 under the devnet era, and Devnet 3's own epoch-0 program at site 0 reads 1.4492x at 2^26 nonces. The mechanism: a product's biased low bits (the shadow block's last write to the load's source, a mul, mulhi or sub) land at address bits R and up through the era's stride rotation `rotl(x * stride, R)`, inside the 28-bit index unless R is 28 or more; R = 29 on the devnet hid it. Class v5's floor (c''', `MIN_DISTINCT_RATIO_V5 = 0.995` at the 2^20 acceptance sample) was read on the class at 23:2x UK (box 2, class-v5 73daadc2, `docs/design/class-v5-harness/v5-listed-adv-cache-2-full.log`): 0 of 61 programs refused at their table attempts (the two real programs, 27 drawn-era, 32 devnet-era controls), the eight over 1.2x at 0.9965 (era-drawn-15, 1.51x) and 0.9969 (era-drawn-28, 1.75x) to 0.9997, the 1.04x to 1.2x band at 0.9986 to 0.9998, every class v5 draw on the class v4 attempt. -Answer (main's sentence, 7 October 2026, 23:4x BST): "eight of eight hot sets refused; the diffuse era-stride excess, bounded under 0.1 percent of a hash's reads per site, is not caught by the floor and is the next class's test." The reading under it: correct, and a different instrument's class. The distinct-index count at 2^20 reads concentration on FEW word indices (adv-accept's eight live hot sets put about 3 percent of a site's reads on 512 indices, the multiples of 2^19, and read 0.9821 to 0.9919: all eight refused by the floor), not a diffuse excess over the top 0.1 percent of items (16,384 items, 262,144 word indices: era-drawn-15's 1.51x is about +0.08 percent of the site's reads spread over them, a few hundred distinct indices, inside the clean spread of 0.0001). So the floor closes the few-item hot-set class and does not reach this one, and no floor would without refusing most clean programs (section 14 of the class v5 design page). Chip value, bounded by the diffuseness itself: a hot table of the top 0.1 percent of items (1 MiB) serves 1.5 x 0.16 percent of one load site's reads, 1/16 of that over the program's 16 loads, about 1.0024x at the worst site read, under the AP-F8-1 bound of 1.067x by an order; nothing in the chip model's rows moves. The next class's test, named: the per-site item-share test at live scale (the window model's top-0.1-percent share per site over 2^23 or more nonces, which costs seconds per candidate and so cannot sit in the acceptance's millisecond budget), or a draw rule on the era's R range and on the shadow block's last write to a load's source register (a mul, mulhi or sub of the same register), known-failed first on Devnet 3's epoch-0 program (fce15bf61030be57, site 0) and era-drawn-28. +Answer (main's sentence, 7 October 2026, 23:4x UK): "eight of eight hot sets refused; the diffuse era-stride excess, bounded under 0.1 percent of a hash's reads per site, is not caught by the floor and is the next class's test." The reading under it: correct, and a different instrument's class. The distinct-index count at 2^20 reads concentration on FEW word indices (adv-accept's eight live hot sets put about 3 percent of a site's reads on 512 indices, the multiples of 2^19, and read 0.9821 to 0.9919: all eight refused by the floor), not a diffuse excess over the top 0.1 percent of items (16,384 items, 262,144 word indices: era-drawn-15's 1.51x is about +0.08 percent of the site's reads spread over them, a few hundred distinct indices, inside the clean spread of 0.0001). So the floor closes the few-item hot-set class and does not reach this one, and no floor would without refusing most clean programs (section 14 of the class v5 design page). Chip value, bounded by the diffuseness itself: a hot table of the top 0.1 percent of items (1 MiB) serves 1.5 x 0.16 percent of one load site's reads, 1/16 of that over the program's 16 loads, about 1.0024x at the worst site read, under the AP-F8-1 bound of 1.067x by an order; nothing in the chip model's rows moves. The next class's test, named: the per-site item-share test at live scale (the window model's top-0.1-percent share per site over 2^23 or more nonces, which costs seconds per candidate and so cannot sit in the acceptance's millisecond budget), or a draw rule on the era's R range and on the shadow block's last write to a load's source register (a mul, mulhi or sub of the same register), known-failed first on Devnet 3's epoch-0 program (fce15bf61030be57, site 0) and era-drawn-28. Status: Answered with evidence (the miss recorded beside the eight of eight); the lever routed to the next class and CA4; nothing in class v5's frozen object 1c420786 moves. diff --git a/docs/spec/01-lottery-hash.md b/docs/spec/01-lottery-hash.md index fe38d5431..b0e3ed639 100644 --- a/docs/spec/01-lottery-hash.md +++ b/docs/spec/01-lottery-hash.md @@ -208,7 +208,7 @@ A class v5 candidate must pass every part of section 1.4.6 and then (c'''): on t Why 0.995 (the record is `docs/design/class-v5-stored-state.md` section 14 and ledger AP-F8-1): the in-house pass found class v4 sub-version 3 programs that pass every part of 1.4.6 and read a live hot set (the exemplar, seed 100767 of the f8 label space, program `9d68e6286fc817d4`: 3.35 percent of one site's reads on the top 0.1 percent of items, from a `mad` value that is near zero in a value class, mapped by the era stride onto the multiples of 2^19); at the acceptance's own sample that site reads 0.9919, where the window model's spread is 0.0001 and the clean median 0.9999. The census over 4,600 seeds reads 2.435 percent of class v4 accepted programs under 0.995 (their class v5 draw lands on a later attempt; the attempts mean goes 2.174 to 2.248), none under 0.98, and 0 class v5 accepted programs under the floor; every live hot set the pass measured (eight, 0.9821 to 0.9919) is under the floor, and the floor misses the shadow-block-written concentrations at 0.9992 to 0.9997 (worth about 1.0004x to a chip), which no floor reaches without refusing most clean programs. 0.99 would pass the exemplar. -The census paragraph in the form of the crypto lane's attempts census of sub-version 3 (per-candidate rejection 0.68, (a') 83.3 percent of rejections, 0 exhaustions, P(256) 8e-44): class v5's own, over 1,000 seeds of the f8 label space through the chain draw (`v5_attempts_census`, box 2, 23:4x BST, `docs/design/class-v5-harness/v5-attempts-census-1000.log`): 3,219 candidates, 2,219 rejected, per-candidate rejection 0.6893, accepted attempt mean 2.219, 0 exhaustions, P(256 consecutive rejections) 4.4e-42. First failing part per rejected candidate: (a') unfresh source 1,850 (83.4 percent of rejections, 57.5 percent of candidates); (a) stale load 237 (10.7 percent); (b) no injecting write 66 (3.0 percent); (c'') low-entropy site 26 (1.2 percent); (c''') hot-item site 23 (1.0 percent of rejections, 0.7 percent of candidates: the floor's own share, one candidate in 140); (c) saturated 9, constant bit 7, distinct addresses 1 (0.7 percent together); (c') none at first failure. So the rule's cost is class v4's: (c''') adds 0.7 percent to the per-candidate rejection and 0.045 to the accepted attempt mean. +The census paragraph in the form of the crypto lane's attempts census of sub-version 3 (per-candidate rejection 0.68, (a') 83.3 percent of rejections, 0 exhaustions, P(256) 8e-44): class v5's own, over 1,000 seeds of the f8 label space through the chain draw (`v5_attempts_census`, box 2, 23:4x UK, `docs/design/class-v5-harness/v5-attempts-census-1000.log`): 3,219 candidates, 2,219 rejected, per-candidate rejection 0.6893, accepted attempt mean 2.219, 0 exhaustions, P(256 consecutive rejections) 4.4e-42. First failing part per rejected candidate: (a') unfresh source 1,850 (83.4 percent of rejections, 57.5 percent of candidates); (a) stale load 237 (10.7 percent); (b) no injecting write 66 (3.0 percent); (c'') low-entropy site 26 (1.2 percent); (c''') hot-item site 23 (1.0 percent of rejections, 0.7 percent of candidates: the floor's own share, one candidate in 140); (c) saturated 9, constant bit 7, distinct addresses 1 (0.7 percent together); (c') none at first failure. So the rule's cost is class v4's: (c''') adds 0.7 percent to the per-candidate rejection and 0.045 to the accepted attempt mean. Attempts, the cap and the last resort are section 1.4.6's with one difference: class v5's last resort is verified. After `MAX_ATTEMPTS_V4 = 256` refused candidates, from attempt 256 on each candidate is rewritten as class v4's last resort is (every `or`, `mul` and `mulhi` to `xor`), its stale loads re-sourced to the lowest register written since the register's last load, walked to a fixpoint (part (a) by construction; only load sources move), and the result run through the whole rule; the first that passes is the program (`last_resort_v5`, scan of 256 candidates). Past the scan the first repaired candidate stands as drawn (the draw is total); that fallback sits under 1e-300 per epoch seed. Class v4 sub-version 3's last resort is unreachable (4.6e-44 per epoch seed) and unverified against the rule (ledger AP-F8-3); class v5's is verified by `class_v5_last_resort_is_verified_known_failed_adv3_steer_2`. diff --git a/site/ledger.html b/site/ledger.html index 82f0065b6..582f5baf8 100644 --- a/site/ledger.html +++ b/site/ledger.html @@ -1103,7 +1103,7 @@ blockquote{margin:10px 0;padding:10px 14px;border-left:3px solid var(--line-2);c
M24

Your two-lane controller oscillates for an hour when a second miner joins mid-epoch

4 October 2026
Watched your devnet this morning. The second 5090 came in at 10:12 and the difficulty never settled: 102M to 164M for forty minutes, 54 to 81 blocks a minute, three or four clamp steps stacked inside a second. Your fast lane and your slow lane disagree by a hair under the trigger and the rule flips between them every two minutes. One card joining is the mildest event a chain can see.
-
Rolled out 4 October 2026, 18:37 local time): rule v2 activated on the live devnet at DAA 33,000 by the height switch after a 12-node cloud rehearsal (settle 157 to 272 s, no swing); node 1, the seed, the observer and the three app machines crossed the height on one chain with no fork and no restart of the chain (a repository file, "difficulty rule v2 activated"). Still owed: the first v2 measurement on the devnet's own two-large-miner regime once the Windows machine is back from proving. Was: Fix built, pending rollout (4 October 2026).
+
Rolled out 4 October 2026, 18:37 UK): rule v2 activated on the live devnet at DAA 33,000 by the height switch after a 12-node cloud rehearsal (settle 157 to 272 s, no swing); node 1, the seed, the observer and the three app machines crossed the height on one chain with no fork and no restart of the chain (a repository file, "difficulty rule v2 activated"). Still owed: the first v2 measurement on the devnet's own two-large-miner regime once the Windows machine is back from proving. Was: Fix built, pending rollout (4 October 2026).
The answer as first written

Correct, measured on the live chain and reproduced in the simulator (a repository file). The cause is the reference lane: spec 2.3 of 3 October gave it the whole epoch, so a hash-rate step inside an epoch left it polluted by the pre-step blocks for the rest of the hour; the short lane read the true rate 11 to 25% above it, the 25% trigger flipped between the two on the short lane's noise, and the per-block clamps turned every flip into a ramp (3% a block up, 10% a block down). The DAG replay (a repository file --live, miners on two nodes with igneum-miner's template staleness, GHOSTDAG, the rule as the node runs it) reproduces the record: std of log difficulty 0.115 against 0.134, 4.3 peaks of 1.31x against 4 of 1.37x, 104M to 169M against 102M to 164M, 54 to 77 blocks a minute against 54 to 81. The brief's five candidates (longer short lane, 3% ease clamp, one clamp per DAA second, hysteresis, median of three) each leave it between 0.09 and 0.13 because none of them cleans the reference lane. Rule v2 caps the reference lane at the newest 600 DAA score of the epoch (the epoch lane only; Kaspa's sampled window is not consulted): 0.026 with 0 lane flips and the target on the true level (142.6M against 139M) on all three seeds; the chain-only simulator agrees (0.14 to 0.19 against 0.02 to 0.08). Cost on the synthetic set (seed 7): steady std of the block rate 0.049 against 0.038 (blocks per minute CV unchanged, 0.130 against 0.135), the 50x step-up settles in 65.5 s against 61.7 s, the 50x step-down 753 s against 629 s, hops slightly faster, the polluted window's overshoot halved. Under attack (attacks.py, seeds 7 to 9): the greedy hopper gains one more point (at most +2.5% against +1.5%), the forger's drift falls to within 1% (worst seed 1.5% against 2.7%), the pulsed rental, the epoch games and the polluted window are unchanged, the 50x step-down is 8% slower and the steady estimate a quarter noisier. Built behind a height switch, difficulty_v2_activation_daa (a consensus parameter, default never, set by the override file), so the devnet moves to v2 at a chosen DAA score on the same chain. The epoch boundary itself clears the pollution, which the live chain showed at 11:02 UTC (DAA 7,200: within 1.3% per minute from 11:07 with no flips, the hash rate having also stepped down there).

Builders

@@ -1184,7 +1184,7 @@ blockquote{margin:10px 0;padding:10px 14px;border-left:3px solid var(--line-2);c
G12

The PoW schedule comes from the environment on every network, including mainnet

5 October 2026
Your mainnet gate refuses the override file. It does not refuse IGNEUM_POW_EPOCH_BLOCKS. A node without a file installs the schedule from the environment and Params.pow_epoch_blocks is never consulted.
-
Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, local worktree a repository file, no remote; main repo branch fud-consensus). Was: Open (4 October 2026).
+
Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 UK, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, local worktree a repository file, no remote; main repo branch fud-consensus). Was: Open (4 October 2026).
@@ -1203,20 +1203,20 @@ blockquote{margin:10px 0;padding:10px 14px;border-left:3px solid var(--line-2);c
X18

Two nodes with two override files connect, and only some mismatches fork

5 October 2026
Your handshake compares the network name and nothing else. A PoW or difficulty mismatch forks and bans; a finality mismatch is a WARN; rollout-v2.sh throws the finality block away when it writes the file; the app rewrites the packaged file on every start.
-
Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, main repo branch fud-consensus). Was: Open (4 October 2026).
+
Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 UK, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, main repo branch fud-consensus). Was: Open (4 October 2026).

Finality and attacks

F23

The equivocation ban is node-local, so honest nodes refuse each other's certificates

5 October 2026
Evidence detected from an RPC vote stamps the sink's DAA; evidence carried in a block stamps the carrier's DAA. Two honest nodes hold different until for the same key, their voter lists differ by one at every checkpoint between the two expiries, and voter_count refuses the other's certificate for good.
-
Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, main repo branch fud-consensus). Was: Open (4 October 2026); reproduced by the red team the same evening on the stock s1 scenario (n0 kept the ban until DAA 726 against 239 on n1 and n2, 9 and 3 to 4 certificates refused "names N voters").
+
Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 UK, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, main repo branch fud-consensus). Was: Open (4 October 2026); reproduced by the red team the same evening on the stock s1 scenario (n0 kept the ban until DAA 726 against 239 on n1 and n2, 9 and 3 to 4 certificates refused "names N voters").
F24

A checkpoint determination is never revisited

5 October 2026
After a reorg deeper than checkpoint_depth, the node's record for that index names a block off its chain. Every certificate the network forms for that index is refused as conflicting, with no equivocation anywhere, and the node voted for a block that is not on its chain.
-
Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, main repo branch fud-consensus). Was: Open (4 October 2026); extends F7 and C4.
+
Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 UK, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus, main repo branch fud-consensus). Was: Open (4 October 2026); extends F7 and C4.
@@ -1300,13 +1300,13 @@ blockquote{margin:10px 0;padding:10px 14px;border-left:3px solid var(--line-2);c
M30

A block or transaction flood grows the 0.3.4 node by hundreds of megabytes in a minute

5 October 2026
On the 3 October ordering-layer node (no execution layer) the resource-exhaustion scenario grew RSS by 4, 11 and 14 MB and the 50x block flood by 30 MB. On the 0.3.4 build, same harness, same scenarios, same 60 s: template flood +6 MB, submit flood +269 MB, mempool flood +270 MB, block flood 302 to 1,082 MB on both nodes (567 MB at 10 s, 824 MB at 20 s). The harness calls it a pass because its bound is baseline + 512 MB; a peer that keeps going is not bounded by the harness.
-
Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-memory, merged into fud-consensus; main repo branch fud-memory, merged into fud-consensus). Was: Open (4 October 2026, red-team run).
+
Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 UK, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-memory, merged into fud-consensus; main repo branch fud-memory, merged into fud-consensus). Was: Open (4 October 2026, red-team run).
The answer as first written

Measured, cause not yet isolated. What changed between the two builds is the execution layer, which this node links: a repository file keeps every ChainBlockRecord in ExecState.records (:304, :419, pushed and never truncated) plus tx_index and inclusions maps per transaction, and the mempool flood's 14,998 rejected transactions cost 270 MB, so rejected transactions are retained somewhere too. Smallest fix: bound ExecState.records to the record window plus the pruning depth and drop tx_index/inclusions entries with them; discard a rejected transaction's bytes at rejection; then re-run a repository file s6 and s7 and require growth under 50 MB, the 3 October figure.

M31

The 0.3.4 node cannot produce a block template on mainnet, testnet or simnet parameters

5 October 2026
getBlockTemplate on a --simnet node from the finality-fixes build answers every call with Coinbase payload is above max length (204). Try to shorten the extra data. and the network never makes a block. The coinbase of this build carries the vote-key reveal, the proof-record section and the finality section; only DEVNET_PARAMS was raised to MAX_COINBASE_PAYLOAD_LEN_WITH_FINALITY (16,384). MAINNET_PARAMS, TESTNET_PARAMS and SIMNET_PARAMS still carry Kaspa's 204 (consensus/core/src/config/params.rs:705, 766, 828 against :900).
-
Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 local time, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus). Was: Open (4 October 2026, red-team run). Serious for anything that is not the devnet: a mainnet or testnet genesis on these parameters cannot be mined by a voting miner at all; harmless on the live devnet, whose parameters carry the raise.
+
Fixed rolled out 5 October 2026, 0.3.5: fork 20139145 = finality-fixes 6aa69a45 + fud-consensus 977db931 + m20-pruning d35b00cf + the miner branches, cut 07:33 UK, a repository file 1b and 4b; node line 2b6d23ef from 0.3.6 at 09:34 UTC carries the same consensus code; every reachable app machine on the line by 09:32 UTC and the hand nodes and the seed restarted on it for the proving activation at DAA 84,100 the same morning, a repository file 8j, bench-log "live devnet: the first shards proven"). Was: Fix built, pending rollout (4 October 2026, night; node branch fud-consensus). Was: Open (4 October 2026, red-team run). Serious for anything that is not the devnet: a mainnet or testnet genesis on these parameters cannot be mined by a voting miner at all; harmless on the live devnet, whose parameters carry the raise.
The answer as first written

Measured on the execution-layer attack network (a repository file runs --simnet with no override): three nodes up, 0 blocks, every template refused with that line (a repository file row 27). Smallest fix: set max_coinbase_payload_len: MAX_COINBASE_PAYLOAD_LEN_WITH_FINALITY on the three other networks, and add a unit test that builds a coinbase with a key reveal, the maximum record section and a full certificate and checks it under every network's limit. The red-team run worked around it with {"max_coinbase_payload_len": 16384} in an override file.

Economics and the coin