`build_consistency_path` returned `vec![old_root, new_root]` — the two values
the operator was already asserting — and `verify` checked that
`audit_path[0] == old_root` and `audit_path.last() == new_root`. That compares a
claim to itself. A log operator serving a split view, two histories sharing no
prefix, produced a "proof" that verified, which is precisely the attack a
consistency proof exists to catch. The verifier's own comment also claimed it
checked that "adjacent pairs hash correctly"; it never did. The in-code note
said a full RFC 6962 §2.1.2 path "is provable as well" — it is, so it is now
what ships.
`subproof` implements §2.1.2 `SUBPROOF(m, D[n], b)` and `verify` implements the
§2.1.3 walk, rebuilding *both* roots from the subtree hashes and comparing. The
old root is recomputed, not re-read, which is the whole difference. Neither root
travels in the path any more, so the forged shape is structurally refused.
The existing `MerkleTree` already used correct RFC 6962 conventions — `0x00`
leaf and `0x01` node prefixes, `largest_power_of_two_lt` splits — and the
inclusion proof was already real, so the proof composes with them unchanged;
all 17 pre-existing tests pass untouched.
Three new tests, each one the old code could not have passed:
- **The forged proof is refused.** A hand-built `[old_root, new_root]` path,
containing no evidence at all, used to verify; it now errors, while the
honest proof for the same transition still verifies.
- **A fork is refused as an extension.** An operator publishes a 3-leaf tree,
then shows an auditor a 5-leaf tree built over a *different* third leaf.
Every hash in that proof is real — only the relationship is a lie. It is
rejected against the published root and accepted against its own, so the
refusal is about the relationship and not a broken prover.
- **Every shape.** All 153 `(m, n)` pairs with 1 ≤ m ≤ n ≤ 17 round-trip:
perfect trees, unbalanced ones, and `m == n`. Each proof is additionally
checked *not* to verify against the neighbouring old root, so a proof binds
one transition rather than a range.
The `audit_path` doc comment said verification "recomputes from the proof's
referenced subtrees", which was aspirational; it is now true, and says which
hashes are in there and that neither root is.
Note this crate still has **zero consumers** — three grep hits, all its own
files — so no JCP decision can yet be given an inclusion proof. That is the
next piece, and it was worth fixing the proof before wiring anything to it.
Third of the "sealed by name / verified not at all" family from the 2026-10-04
sweep: 845e6cc8 (AP2 mandate authority), aa74283e (policy digest), this.
Co-Authored-By: Claude Opus 5 <[email protected]>
bc658ab98b