AIP-22: dated addition of 2026-09-27, the public verifier's early refusals exit 1 on Windows (were 127)

aips/AIP-22.md

@@ -285,6 +285,8 @@ Two refinements to the text above, recorded rather than silently applied: the Me
 
 **2026-09-27, three records.** (1) *The re-proposal repair of 2026-09-25 runs on testnet 28001; the public verifier and this text followed it a day late.* The six nodes of chain 28001 have judged headers by the corrected section 5 since 2026-09-26: the Nethermind-derived validator from 05:15Z, the five Besu-derived nodes one at a time after it (from 2026-09-27 00:00-00:11Z on a later distribution that keeps the rule). The record of 2026-09-25 put the public verifier and this text in the same hour as that deployment; they did not go then. Until this publication, step 6 of the published `aere-node/tools/verify-anchor.mjs` still required every proposer seal to be the coinbase's, so a re-proposed header inside the window it checks would have been reported as a failure of the chain. Measured over headers 3,473,624 to 3,611,791 of chain 28001 (from before the deployment to this record: 138,168 headers, 31 of them finalized above round 0): one was re-proposed and sealed by someone other than its builder, block 3,508,874 (2026-09-26 09:58:40Z, 3,325 transactions, prepared by the validator of row 2 and finalized at round 2 under the seal of row 0, that round's proposer), admitted by every node. Judged through a local proxy that makes it the tip, the verifier published until today fails it ("proposer seal index 0 is id 0xa0a5..., but the coinbase is 0xe7e6..."), so whoever ran it in the seconds that block stayed in its window was told the chain had failed; the verifier published now names it as a re-proposal and passes. It is also the first real re-proposed header sealed by someone other than its coinbase, which the record of 2026-09-25 listed as not measured. Published now: the verifier with the corrected step 6; the 21 offline cases of 2026-09-25 pass on the published file, and ten planted defects each turn them red; as a stranger, 20 of 20 anchors and 20 of 20 proposer seals on 28001, 20 of 20 anchors on 2800. The tool now sets its exit code at the end instead of calling `process.exit()`: on Windows, exiting while its HTTP sockets were closing could abort Node with a code that is neither 0, 1 nor 2 (two of the 21 offline cases on the first run); its early refusals still exit through `process.exit(1)` and can show the same code there, with the reason printed as before. The check that the nodes run the repair now also requires the served verifier to carry it. (2) *Conformance corpus.* Published in `aere-research/aips/aip22-conformance/`: eight of the nine kinds of section 9, every vector with the verdict of both clients and, for a refusal, the text each wrote. The certificate with a surplus scheme was the kind no node had produced (on 28001 SLH-DSA-SHA2-128s is required only on its 128-block grid, and no anchor of the 32-block grid carries it): its valid form carries a real SLH-DSA-SHA2-128s seal over `M(parent)` of anchor 3,288,320, made on 2026-09-27 by the key of the validator holding row 0 of the v3 epoch in force, on that validator's host with the node's own classes, after a real Falcon-512 seal of the same certificate was checked to verify over the same `M`. Both clients admit it, and refuse it with one byte of that seal changed, each for the reason that the seal does not verify: a surplus seal is verified and counted, never ignored (section 2). (3) *The classical-only fork, recorded.* The behaviour section 4 rule 4 names was measured on the rehearsal network 28099 (one validator V; an attacker X holding V's ECDSA key and no post-quantum key; readers linked only to X until the fork stops). On 2026-09-23 a Besu-derived reader followed X's fork for 26 blocks, which stopped at the block before the next anchor because X cannot certify it, and moved to the anchored chain (+27/-26) in the second it was linked to V; with the anchor rule disarmed on the reader and on X, the fork crossed the anchor height and the reader stayed on it. On 2026-09-24, on the chain rebuilt with `H_fin` = 600, readers of both clients followed a 24-block fork that stopped at the block before the anchor, and both moved to the anchored chain when linked to V; with the anchor unarmed (the Nethermind-derived client has no disarm switch; its anchor rule left unconfigured is the equivalent), both stayed on the fork. So the Nethermind-derived reader under attack, not measured in the stage 4 record, was measured the next day. The static vector section 9 names is not yet in the corpus; a head rule for validators fed such a fork (it needs N >= 4) is not measured.
 
+**2026-09-27, later the same day, the public verifier's early refusals.** The record above says they still called `process.exit(1)`. They no longer do: measured before the change, an early refusal after a network request exited 127 on Windows in eight of eight runs, so the caller saw neither the chain's verdict nor the tool's; after it, 1 in three of three. Any other uncaught error still ends the run as a failure at once. The published file changed; on it the 21 offline cases pass again, the planted defects of the general negative control and of the proposer-seal proof are each refused, and the stranger runs on both chains are as above.
+
 ## Errata
 
 - 2026-09-24, Backwards Compatibility: the text said that ECDSA-quorum light clients need another path "after `H_fin`". Read in their guest program (`verify_finality` in the QBFT finality crate of the ZK light client), they stop earlier, at `H_id`, because the set they match seals against becomes a list of `id`s there. Corrected in place; nothing else in the section changes.