AIP-20: key reuse with the empty ML-DSA context, and a dated correction on consensus enforcement; AIP-22 and README: seals stated as many as the quorum, proving signing, not decision (erratum of 2026-10-01)

README.md

@@ -19,7 +19,7 @@ checkpoint every 32 blocks.** Since block 13,014,000 anchor blocks carry, under
 certificate of validator post-quantum seals (Falcon-512, with SLH-DSA-SHA2-128s as well since
 2026-09-04, at every 128th block since 2026-09-29; every anchor was 128 blocks apart from block
 17,225,968 to block 20,746,736). Since block 20,715,632 (2026-09-29) a node rejects an anchor block
-with fewer than seven valid seals per scheme, the full quorum of the ten validators; the minimum was
+with fewer than seven valid seals per scheme, as many as the quorum of the ten validators (the seals prove those validators signed the block, not that it was decided, per the AIP-22 erratum of 2026-10-01); the minimum was
 three (f+1 of nine, not a quorum) from 2026-08-14 and six from 2026-08-21. That
 checkpoint lives in the aere-node repository (patch 0003 and `anchor/`), not in this one: nothing in
 this repository makes consensus post-quantum, and the chain is not "post-quantum consensus" without

aips/AIP-20.md

@@ -226,8 +226,23 @@ early is safe.
 ## Security Considerations
 
 - **Quantum threat model.** An account authorized only by ML-DSA has no key recoverable by Shor's
-  algorithm. Consensus messages are post-quantum enforced (SPEC 2.6). Node-to-node transport (RLPx)
+  algorithm. This protects the account's authorization, not the chain: consensus is outside this AIP.
-  remains classical; it authenticates peers, not funds, and is out of scope here.
+  Corrected 2026-10-01: an earlier text said here that consensus messages are post-quantum enforced.
+  On chain 2800 they are not: blocks are decided by classical ECDSA commit quorums, anchor blocks
+  carry post-quantum certificates (AIP-22 stages 1 to 3), and per-commit post-quantum enforcement
+  (AIP-22 stage 4) is not active as of that date. Node-to-node transport (RLPx) remains classical; it
+  authenticates peers, not funds, and is out of scope here.
+- **Key reuse and the empty context.** The signature covers the 32-byte `signing_hash` with the
+  empty FIPS 204 context. A key that authorizes a type-`0x50` account MUST NOT be used by a signer
+  that signs caller-supplied 32-byte values with the empty context (a generic "sign this hash"
+  interface): such a signer signs, for whoever supplies the value, a type-`0x50` transaction of that
+  supplier's choosing. A signer for any other purpose uses a different key, or a non-empty context,
+  or signs a message that is itself domain-separated (`@aere/pq-sign` signs the SHA-256 of a fixed
+  domain string, the algorithm and the message digest, which cannot equal a `signing_hash` without a
+  hash collision). Moving type `0x50` to a non-empty context would change the signing hash of every
+  transaction and is a separate, coordinated fork. Added 2026-10-01; measured on that date, the four
+  ML-DSA signing paths in the reference repository each build their own message and none signs a
+  caller-supplied value.
 - **Denial of service.** ML-DSA verification is slower than ECDSA recovery. The cost is paid in gas
   before execution, the pool verifies before storing, and pool admission is subject to the existing
   per-peer limits; the verification cost is bounded and constant per `alg_id`.
@@ -332,7 +347,10 @@ type-0x50 transaction proposed by the Nethermind-derived validator on chain 2800
 
 ## Errata
 
-None.
+- **2026-10-01, Security Considerations.** The sentence "Consensus messages are post-quantum enforced (SPEC 2.6)" was
+  false for chain 2800 and is replaced by the corrected text under "Quantum threat model". Added under "Key reuse and the
+  empty context": a key that authorizes a type-`0x50` account must not be used by a signer that signs caller-supplied
+  32-byte values with the empty context. The transaction format, the signing hash and every vector are unchanged.
 
 ## Post-Acceptance Outcome Record
 

aips/AIP-22.md

@@ -2,7 +2,7 @@
 
 > **Note added 2026-09-30.** Where this document describes chain 2800 "today" (a certificate of at least six of ten seals
 > per scheme every 128th block, validators named by ECDSA addresses), it describes the chain before stages 1 to 3 of this
-> AIP. On chain 2800 stage 1 (at least seven of ten seals per scheme, the full quorum) is active from block 20,715,632,
+> AIP. On chain 2800 stage 1 (at least seven of ten seals per scheme, as many as the quorum) is active from block 20,715,632,
 > stage 2 (Falcon-512 every 32nd block, SLH-DSA every 128th) from block 20,746,736, both on 2026-09-29, and stage 3
 > (post-quantum validator ids in the header and in `qbft_getValidatorsByBlockNumber`) from block 20,836,228, on
 > 2026-09-30. Stages 4 and 5 (per-block post-quantum finality, the header without ECDSA) are not active on chain 2800.

aips/README.md

@@ -67,8 +67,7 @@ describe the decisions behind the live system.
 package for the exact rules and heights):** the anchor certificate under the block
 hash (every 32nd block from 13,014,000, every 128th from 17,225,968 to 20,746,736, every
 32nd again since, with SLH-DSA every 128th; hybrid Falcon-512 + SLH-DSA since 17,047,600;
-at least seven valid seals per scheme of the ten validators, the full quorum, since
+at least seven valid seals per scheme of the ten validators, as many as the quorum, since 20,715,632 (the seals prove those validators signed the block, not that it was decided, per the AIP-22 erratum of 2026-10-01), six from 14,961,456), post-quantum validator ids in consensus since 20,836,228
-20,715,632, six from 14,961,456), post-quantum validator ids in consensus since 20,836,228
 (AIP-22 stages 1 to 3, 2026-09-29 and 2026-09-30), and the per-message Falcon-512 enforcement on every QBFT
 message (heights 17,250,000 to 17,700,000, September 2026). AIP-21's record is live
 on chain 2800 since 2026-09-22; AIP-20 is deployed and armed for 19,900,000.