diff --git a/SPEC.md b/SPEC.md index f5281fa..cd7bb55 100644 --- a/SPEC.md +++ b/SPEC.md @@ -464,10 +464,17 @@ Falcon key can rewrite at most the tail since the last anchor, so fork depth <= block 20,746,736 (about 20 seconds at the measured rhythm; <= 128 blocks, about 75 seconds, from block 17,225,968 to block 20,746,736; <= 32 blocks, about 16 seconds, before that); rewriting anything below an anchor changes that anchor's parent hash, forces the anchor to be reproduced, and reproducing it requires Falcon signatures the adversary does not have. -Added 2026-10-01 (AIP-22 erratum of that date; derived, not exercised): the certificate's seals carry no -round, so if the validators had also sealed, at the height of the last anchor's parent, a block in a -round that did not decide it, those honest seals can certify an anchor over that block, and the -rewrite can reach the anchor's parent, one block deeper than the bound above. +Added 2026-10-01 (AIP-22 erratum of that date): the certificate's seals carry no round, so an anchor +can be certified over the undecided sibling of the decided block, with honest validators' seals, if +at the height of the last anchor's parent the validators sealed that sibling in rounds that did not +decide it (an adversary that controls the order of messages across three round changes at that +height can bring that about); the rewrite can then reach the anchor's parent, one block deeper than +the bound above. Before stage 5 of AIP-22 (not activated on chain 2800) forging the headers takes a +quorum of classical keys, which this adversary holds and a single validator does not; from stage 5 +the anchor's header needs its proposer's Falcon-512 seal, which this adversary lacks and a single +validator has. Measured in a test fixture with the production rules; not exercised on any network. +With a repair in code, not yet deployed, no node takes the anchor's parent as decided from such a +certificate, only its grandparent, the block both siblings share. History below H remains protected by ECDSA alone, permanently (source: `anchor/consensus/common/.../PqAnchorConfig.java`, interval javadoc; `anchor/README.md`). @@ -980,7 +987,8 @@ implementation exists to compare against]. - The EIP-4788 (Cancun) beacon-roots system call targets a contract with no code on chain 2800, so it is a per-block no-op that Besu reports at ERROR level in its log; state is unaffected. A client must not treat the empty beacon-roots contract as an error in its own sync - [MEASURED 2026-08-07, finding D-153 in the repository's findings register; not restated in any + [MEASURED 2026-08-07, a dated finding in the operator repository's findings register (the empty + beacon-roots contract and its per-block ERROR line); not restated in any bundle file, see section 9, G8]. --- @@ -1087,7 +1095,8 @@ step `13034000:3` reads "enforced since 2026-08-14" in prose: the step was confi the effective minimum was held at 1 by the ceiling until the window's end (source: `anchor/README.md`; `PqAnchorLapse.java`). -**D6. Correction of 2026-08-19 (repository finding D-235): `aere.falcon.forkBlock=14050000` armed a +**D6. Correction of 2026-08-19 (a finding of the operator repository's register: the per-block Falcon +quorum described as blocking was not enforced): `aere.falcon.forkBlock=14050000` armed a RETIRED rule and changed no enforcement.** The fleet was configured on 2026-08-15 with that value, intended as a per-block blocking Falcon quorum, and public material said so. In the shipped code the rule it arms (`FalconSealValidationRule`) retires at the anchor activation height 13,014,000 in @@ -1142,19 +1151,19 @@ are the authoritative in-protocol trace of the expansion (source: `registries/RE --- -**D8. The COMMIT seal message under an armed anchor (found 2026-09-02, D-311).** A verifier of the +**D8. The COMMIT seal message under an armed anchor (found 2026-09-02 on the public testnet).** A verifier of the COMMIT enforcement that checks the seal over the ECDSA committed-seal hash refuses EVERY commit as soon as the anchor is armed, because the emitter signs the anchor form (section 2.6). The shipped client before 2026-09-02 had exactly this divergence between its emitter and its verifier; it was found on the public testnet 28001 at the first enforcement height (the chain stopped at block 999), fixed by deriving both sides from one function, proven with unit and plumbing tests, a rehearsal with the anchor armed, and the testnet itself, and the fleet was moved to the fixed -build on 2026-09-02 (image `d311-20260902`, version `26.4.0-aere.1-d203201-wt95fac2d7`). A +build on 2026-09-02 (version `26.4.0-aere.1-d203201-wt95fac2d7`). A third-party client implementing COMMIT enforcement MUST verify over the anchor form whenever -`height + 1 >= aere.pq.anchorBlock` (source: `testnet-public/D-311-DOVADA-2026-09-02.md`, -`deploy/validators/d311-2026-09-02/SURSA.md`). +`height + 1 >= aere.pq.anchorBlock` (source, in the operator repository: the testnet proof of +2026-09-02 and the source record of the fixed build). -**D9. Osaka header fields under QBFT (found 2026-09-02, D-322).** On an AERE QBFT chain with the Osaka +**D9. Osaka header fields under QBFT (found 2026-09-02 on the public testnet).** On an AERE QBFT chain with the Osaka fork active from genesis (the public testnet 28001: `osakaTime=0`, `futureEipsTime=0`), Besu writes the EIP-7928 block access list hash (`balHash`) and the EIP-7843 `slotNumber` ONLY in block 0; every later block omits both fields (measured on blocks 1 and 47744 through `eth_getBlockByNumber`). A second client that @@ -1195,7 +1204,7 @@ the gap as real rather than assume. - **G7. The `0x100` P-256 (RIP-7951) input/output format.** Live and classical, upstream Besu; not specified in this bundle. - **G8. The EIP-4788 no-code observation** (section 6.5) rests on a dated repository finding - (D-153, 2026-08-07), not on a bundle file; a bundle-resident statement (or a fixture proving the + (2026-08-07, in the operator repository's findings register), not on a bundle file; a bundle-resident statement (or a fixture proving the no-op) does not exist yet. - **G9. Whether a certificate reused by an adversary for its one permitted fork block passes eligibility in every corner case** was argued from code and never executed as a run (source: diff --git a/anchor/README.md b/anchor/README.md index 96ed676..c74c413 100644 --- a/anchor/README.md +++ b/anchor/README.md @@ -70,9 +70,11 @@ anchor itself; and a message without a valid seal is REFUSED from blocks 17,250, heights were set on all nine validators on 2026-09-05 and take effect as the chain reaches them; until each height passes, that message type is still accepted without a seal. What a quantum adversary cannot do at any height is rewrite history past the last anchor without also forging -Falcon-512 and SLH-DSA-SHA2-128s signatures (added 2026-10-01, AIP-22 erratum of that date: except at -the height of the last anchor's parent, if the validators had also sealed there a block in a round -that did not decide it; derived, not exercised). None of this has been audited by a third party. +Falcon-512 and SLH-DSA-SHA2-128s signatures (added 2026-10-01, AIP-22 erratum of that date: except the +last anchor's parent while headers carry ECDSA seals, before stage 5 of AIP-22, since an anchor can be +certified, with honest validators' seals, over the undecided sibling of the decided block; measured +in a test fixture with the production rules, not exercised on any network; SPEC.md, interval +section). None of this has been audited by a third party. The threat it addresses is not "harvest now, decrypt later". A signature is public; there is nothing to harvest. The threat is **retroactive rewriting**: validator keys recovered later can be used to