Counter ASIC 3.0 status: publish 2 live and read back (digest eada4bda on f1ea7a38, the vote open at DAA 223,667); the rehearsal chain ends

docs/plans/counter-asic-3-status.md

@@ -300,6 +300,7 @@ A script never switches the installed app's cards: a POST of enabled false to /a
 | The order, with the shipper's measurement on the 0.3.15 Mac binary (fork f86a33c0, no suffix, no peers) | THE DIGEST MOVES AT PUBLISH 1: on the live thirteen-field file 0.3.15 reads c09c3e48... where 0.3.14 reads b18ed271... (the two v4 fields fold into the digest at never when absent), so publish 1 (binaries only) is itself the one-sweep handshake split and every node moves inside one window there, miners first, the hand nodes and the seeds last; publish 2: the SIXTEEN-field object (the live thirteen plus 0.3.14's exec_restart_state_root, the floor 226,800 from DAA 209,458 at a 19:47Z publish, the window 86,400; digest 2c1162e2... on 0.3.15; the node's lines "Program class v4 from the override file: active from epoch 63 (DAA 226800)" and the 86,400 window at 9,500 bps) only once every node reports 0.3.15; a 0.3.14 node given it exits at parse ("unknown field program_class_v4_activation_daa"), confirmed on the Mac binary as the rehearsal found. The node lane's tests-only fix 791ff22c merges into the release node. MAIN'S RULING (19:0x UTC): publish 1 must not be a handshake split. The node lane adds to ca3-v4-order-fix a digest-compat change: an ABSENT optional field contributes nothing to the digest, so 0.3.15 on the thirteen-field file prints b18ed271... and peers with 0.3.14; the binary rolls out with no window; the sixteen-field file at publish 2 is the one sweep (miners first, the hand nodes and the seeds last, only when every node reports 0.3.15); the sixteen-field digest is re-read on the fixed binary before publish 2. IMPLEMENTED (fork ca3-v4-order-fix 713ef876, with the shipper): the two v4 fields enter the digest only once set, the window's default 0 on every network, the no-file devnet digest back to c562d70e...; the box's suite on 713ef876 kaspa-consensus 98 and consensus-core 111 + 7, 0 failed; pinned in a new test: the thirteen-field live file b18ed271... (0.3.14's value), fourteen fields 23e76936..., sixteen fields (the pin, floor 219,600, window 86,400) 1dddfa55...; the rehearsal unaffected by construction (its object sets both fields, so a15db4f0 on devnet-400 stands); the two harness lines on real nodes both PASS (the fixed Mac binary of 713ef876 against the 0.3.14 binary, 18:58Z, `infra/fast-time/digest-compat.mjs`, the P3 row on ca3-v4-node 38ac2a3): COMPAT, a fixed node and a 0.3.14 node on the live thirteen-field file print one digest and peer; REFUSAL, the fixed node on the sixteen-field file prints another and is refused with the handshake's own "consensus params digest mismatch" line on both sides; on the devnet id the sixteen-field object re-reads 1dddfa55... (the pinned value), the thirteen-field file b18ed271..., no file c562d70e.... The rehearsal's flip (about 19:01Z) and floor (about 19:21Z) are the PASS clock main holds the project lead to |
 | The fork's final tree for 0.3.15 (ca3-v4-order-fix, four commits) | 791ff22c the order-test race (tests only); 713ef876 the digest once-set rule; 17c60367 the signal stamp and read gated on both v4 fields (header version 2 on the live file, 1026 only with publish 2's object); 7961c5f1 a sync request below a pruned node's retention answered as SyncManagerError::BlockBelowRetention to the peer, never an unwrap (the hub's 19:57Z panic: a remote crash vector against every pruned node since the first one). The shipper built 0.3.15 from 7961c5f1 on all three platforms, the digests unchanged, the six-crate suite green. The node-compat gate (ca3-v4-node 4d7e677, `infra/fast-time/node-compat.mjs`, 20:19Z): a mining new node beside a 0.3.14 node on the live object PASS (one digest on five nodes, the new miner's 75 blocks accepted by the old hub, header versions 2 only, 195 blocks on every node including the clean join through the old hub, the old node served from genesis by the new one, the new node restarted and re-synced); the canary binary 713ef876 on the same gate FAILS with the fleet's exact reject lines (the known-failed case). Ledger rows N1 and N2 (security, conceded, dated, with the fixes) in docs/fud-ledger.md. The audit pass landed (fork ca3-v4-deps f8f0f1df from 7961c5f1, Cargo.lock only, the shipper's 0.3.15.1 node change): h2 0.4.20, quinn-proto 0.11.19, rustls 0.23.45, crossbeam-epoch 0.9.21, ruint 1.20.1; cargo audit on the box 6 vulnerabilities and 16 warnings before, 1 and 16 after (the one left tracing-subscriber 0.2.25 pinned through ark-groth16, a major bump, named and not taken); the six-crate suite green on the new lock (99 / 111 + 7 / 20 / 15 / 18 / 33); row P5 on ca3-v4-node 536e084. The receive-side fix f1ea7a38 (fork ca3-v4-order-fix on 7961c5f1, 21:39 UK, to the shipper 21:46 UK; the box line kaspa-consensus 99, consensus-core 111 + 7, rc 0): with the window or the floor absent, a header's version must be exactly 2 (0.3.14's rule), so a 1026 header is refused before the engine with WrongBlockVersion(1026, 2) and never relayed; with publish 2's object both bytes are read as designed; the test inside cheap_checks_run_before_the_pow_engine; the gate re-run with a poisoned peer in the topology (a 713ef876 node mining 1026 blocks into the new node, 20:42 to 20:45Z) PASS: 12 refusals with 0.3.14's exact line, none relayed, the old hub's chain holding version-2 headers only, every clean node at 180; stale blocks on the live devnet: a 0.3.14 node holding them is disconnected by its 0.3.14 peers by their own rule, new nodes are immune, the fleet wipes the poisoned datadirs; ledger N1 extended; the shipper rebuilds once on f1ea7a38. The node lane's further queue (the peer-driven unwrap class with a sync-request fuzz gate, the 7-window signalling rule, the Horizon items, the stale-block nuisance-peer case) reports to main: it is the cut's and the ledger's, not this file's |
 | the project lead's go | given in advance for tonight; publish 1 on the 0.3.15 canary line, publish 2 once every online node and worker reads 0.3.15 |
+| PUBLISH 2 LIVE AND READ BACK (22:43Z, the shipper) | the sixteen-field object (the live thirteen, the exec pin, program_class_v4_activation_daa 831,600, program_class_v4_signal_window_daa 86,400), digest eada4bda8aa8368c2b2c3d17744bc7a70a0ff0e996dad681884d3ac5de1207eb on igneumd/2.1.0-f1ea7a38, on the fleet's 14 standing boxes, both PCs, the hands and the seed; every node prints "active from epoch 231" and the 86,400 window at 9500 bps; THE VOTE OPENED at DAA 223,667. Two facts from the way there: 0.3.15's node gained two gates beyond the signalling fork (the stamp AND the header-version rule both gated on publish 2's object: 17c60367, f1ea7a38) after the live canary found a 0.3.15 node writing version 1026 on the thirteen-field file and then accepting one from a poisoned peer; and the floor sits a week past the publish (831,600) because the floor flips unconditionally on this node (the 0.3.17 P2 rule applied early). The rehearsal chain igneum-devnet-400 ends on this line (the fleet agent told) |
 
 ## 7a. The two fast-forwards to master (decision 5)