release-0.3.20 plan: the sixteen-field interop fact (0.3.17 relays byte-5 headers), the void run's failed checks explained

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-07 11:54:01 +00:00
parent 330d6ad062
commit d8cd4d8e42

View file

@ -379,3 +379,5 @@ igneum-pow: release-0.3.20 carries the hash lane's 8c728ca3 tree at 00249643 (th
Speculative builds on the candidate from the ship worktree, box only, sequential (scratch r0320/build-candidate.sh, started 12:52Z): igneum-pow tests, fleet-native node (target-0320), hive class (target-0320-hive), Windows cross of the node and the app, the app's Linux binary; shas and commit strings at the end. If the pin falls back, the same script runs on 6b94c823. The Mac builds only its own binaries and the DMG, under the lock, after the pin.
**The amended class v4 packs (the hash lane, 15:0x UK), what the fleet reads on the canary.** igneum-pow 8c728ca3, byte-equal to 00249643's tree; program id 1a4230699a6b9c60 (generator 4, class v4, sub-version 1) on every v4 pack; the pre-amendment id c120d7963abdcd96 is the must-differ vector (tests/recheck.rs and the node's kaspa-pow test); the v3 control mx8-devnet-epoch0 id 73bcbfe8ccf988f1 fingerprint 90f794dd556f7a3b unchanged. Fingerprints 2^24 at base 0, equal on Metal, Apple OpenCL and the RTX 5090 (NVRTC 12.8 sm_120): v4-devnet-epoch0 867dbc45cfb36b4d (vectors 756301bf1739a7ee); v4-era-0 2146ecacc8c75a8e; era-1 fe52602393f6d3d4; era-2 3b206471a13912b4; era-3 c3f03c4a5d7333aa; era-4 f1dfd7209f15bb97; era-5 8c194da64fadf31d. Packs at proto-cuda/packs-ca3-v4 on ca3-v4-amend; the eight-pack kit zip sha256 889ec99976d2728b4b5035bfa476032e5b6a13b928968fc45236d5f25084aa39. G1 (d8859522): PC 2 run-ca3-v4-amend-g1-pc2-20261007 09:41Z, the 0.3.17 worker, self-test PASS on all eight packs, every fingerprint equal. The pairing line (igneum-pow 8c728ca3 against the fork's kaspa-pow, `test --release -p kaspa-pow --features igneum-pow`) is in flight on the box; the node lane's own run of the source-rule line on the 0.3.20 fork passed (1a4230699a6b9c60 equal, c120d7963abdcd96 differs, v3 unchanged, object byte 5).
**Interop fact from the void 8097d600 run (the node lane, 15:1x UK):** on the live sixteen-field file plus genesis_bits (one digest on all five nodes, f92a0675), the 5899f603 hub accepted every block the 8097d600 node mined, 235 accepted and 0 rejected, the old node's headers at version 1026 (block version 2, object byte 4) and the new node's at 1282 (byte 5), counts equal on all five at 472 before the restart step. So a 0.3.17 node takes byte-5 headers from a 0.3.20 node and relays them: the amended class's one interop question, answered. The run's four FAILED checks are the binary swap (n1 restarted two seconds before 6a3432a3's build replaced the path) and one harness expectation written for a file without v4 fields (`every_header_version_is_the_block_version`); the clean runs use the thirteen-field object. 6a3432a3's own gates started 13:53 UK, lines about 14:08 UK; the fallback's follow.