Bet 82 — Post-quantum signature migration (CATASTROPHIC)

The fourth catastrophic falsification in the operating-layer batch. The transition protocol works in principle (70% of receipts remain verifiable across a quantum-break event; Phase 1 frozen-but-settled), but SPHINCS+ signatures cause a 782× bandwidth blowup during the dual-sign window. The federation must use Dilithium (~2.5KB) instead, OR a signature aggregation scheme.

The frame: Ed25519 may not survive 50 years of cryptanalytic + quantum computing progress. Bet 70 (50-year royalty stream) makes a 50-year promise to trainers' estates. Bet 82 tests whether the federation can migrate to post-quantum (PQ) signatures (SPHINCS+, Dilithium) without destroying the audit trail or breaking ledger continuity.

The protocol under test is a three-phase dual-sign migration:

Phase 1 (years 0-3): all receipts signed Ed25519 only.
Phase 2 (years 3-8): all NEW receipts signed BOTH Ed25519 AND a PQ scheme.
Phase 3 (years 8+): Ed25519 broken; receipts in Phase 2+ remain valid via PQ alone; new receipts signed PQ only.

A simulated quantum-break event at year 7 (mid-Phase-2) tests the migration's resilience.

The bet identifies one specific catastrophic problem (bandwidth) and validates the rest of the design.

Background — why post-quantum migration is hard

Cryptographic agility is one of the catalogue's hardest problems. Federation contracts that span 50 years span multiple cryptographic regime changes. Ed25519 today is conjectured-secure; in 2050 it may not be.

The migration is hard because:

Historical receipts in the ledger are signed with the old scheme. Once the old scheme is broken, those receipts can no longer be re-verified by adversarial replay. (Their settlement state is fixed in the ledger but cannot be replayed for audit.)
Transition windows must be longer than the time-horizon for cryptanalytic progress. If quantum break happens before Phase 2 lands, all Phase 1 royalties become un-auditable in the worst sense.
Bandwidth costs of PQ signatures are substantial. SPHINCS+ signatures are ~50 KB, vs Ed25519 ~64 bytes. During Phase 2's dual-sign window, every receipt carries both signatures.

Hypothesis

A three-phase dual-sign migration preserves ≥ 90% of historical receipt verifiability across a quantum-break event, with bandwidth overhead bounded at ≤ 8× during the dual-sign phase.

Pre-registered criteria

STRICT: ≥ 90% of receipts verifiable at year 10; bandwidth peak ≤ 8× base; migration window safe.
LENIENT: ≥ 70% verifiable; bandwidth ≤ 16×.
CATASTROPHIC: < 50% verifiable, OR migration window inadequate (quantum break before Phase 2 lands), OR bandwidth ≥ 50×.

Setup

50,000 receipts written across 10 simulated years (5,000 per year).
Phase boundaries: 0-3 (Ed25519 only), 3-8 (dual sign), 8-10 (PQ only).
Quantum-break event at year 7 (mid-Phase-2).
Signature size: Ed25519 = 64 bytes, SPHINCS+ = 50,000 bytes (rounded from 49,856).
Verification at year 10: count receipts that retain ≥ 1 valid signature.

Result — CATASTROPHIC (bandwidth)

| Metric | Value | |---|---| | Receipts at year 10 verifiable | 70.00% (5/7 phase-coverage) | | Phase 1 verifiable post-quantum | 0.0% (frozen — settlement preserved, audit broken) | | Phase 2 verifiable | 100.0% (dual sigs survive) | | Phase 3 verifiable | 100.0% (PQ only) | | Peak year bandwidth multiplier | 782.25× Ed25519-only baseline (year 3) | | Migration window safe | True (Phase 2 starts year 3, quantum at year 7) | | STRICT | FAIL (bandwidth > 8×, verifiable < 90%) | | LENIENT | FAIL (bandwidth > 16×) | | CATASTROPHIC | TRIGGERED (bandwidth ≥ 50×) |

The verifiability picture is acceptable: 70% verifiable at year 10, with the remaining 30% (Phase 1 receipts) frozen. Their settlement is permanent; only adversarial replay-audit fails. This is a tolerable property — historical settlements aren't being challenged in practice; the loss is theoretical.

The bandwidth picture is not acceptable. 782× Ed25519-only at peak. SPHINCS+ at 50 KB per signature, with one signature per receipt and 5,000 receipts/year, means 250 MB/year per receipt-stream of pure signature data. At federation scale (10K-100K specialists), this is gigabytes-to-terabytes of signature overhead annually.

Why SPHINCS+ specifically fails

SPHINCS+ uses Merkle hash trees with a large public-key + signature size. It has the security advantage of being hash-based (no ring-LWE assumption), but the size makes it impractical for high-volume protocols.

Alternative: Dilithium (CRYSTALS-Dilithium, NIST-standardised). Signature size ~2.5 KB. That's 50× the Ed25519 size, vs SPHINCS+'s 800×. Dilithium during dual-sign would produce a peak bandwidth multiplier of ~40×, still high but tractable.

Another alternative: signature aggregation. BLS signatures (Boneh-Lynn-Shacham) allow N signatures over the same message to be aggregated into a single signature of constant size. The federation could aggregate per-block signatures (e.g., one aggregate sig per minute or per 1000 receipts), bringing the per-receipt bandwidth back to single-signature size during the dual-sign phase.

A third alternative: lazy migration. Phase 2 dual-signs only the receipts that will need post-quantum verification (i.e., long-horizon receipts like estate-bound royalty); short-horizon receipts (settled within < N years) get Ed25519-only. The ledger would carry a requires_pq flag.

What this validates

The three-phase dual-sign architecture is correct. Phase 2 receipts survive quantum break cleanly; Phase 3 receipts are pure PQ.
The frozen-but-settled property is acceptable. Phase 1 receipts retain their ledger settlement state even when their signatures can no longer be re-verified.
Migration window safety is straightforward. Phase 2 must start at least N years before the estimated quantum-break date; the simulation's 4-year margin (year 3 → year 7) is on the lower end. Recommend 7+ years in production.
Per-phase verification rate is the right metric. It correctly identifies that Phase 1 is the loss; Phases 2-3 are full-strength.

What this does not claim

Real quantum-break timing. The simulation places quantum break at year 7. NIST estimates 10-30 years before practical attacks on Ed25519. The bet's value is not the absolute year but the structural transition properties.
Other PQ schemes (Falcon, Picnic). The simulation uses SPHINCS+ as the worst-case. Better choices (Dilithium, Falcon ~1 KB) reduce bandwidth substantially.
Real ledger replay-audit semantics. The "frozen but settled" framing is a federation policy choice. Other federations might require all historical receipts to remain replay-able indefinitely; that constraint is more demanding.
Cross-federation PQ migration. Bet 86 covers cross-federation receipts under static crypto; cross-federation under PQ-migration is open work.
Hybrid schemes (e.g., PQ + classical with both verifiable separately) — Bet 82's dual-sign is one specific hybrid; alternatives exist.
The Phase 1 frozen population. A federation that has been operating for 5 years before starting Phase 2 will have a larger Phase 1 cohort than the bet's 30%. The economic implications need quantification.

The mandate

RFC-0006 §5 (Post-Quantum Migration) must specify:

Use Dilithium, not SPHINCS+, as the PQ signature scheme. Bandwidth peak ~40× is tolerable; ~800× is not.
Phase 2 dual-sign window must start at least 7 years before the federation's estimated quantum-break date (per NIST guidance, currently 2030-2040).
Phase 1 receipts are frozen-but-settled. Their adversarial-replay audit fails after quantum break, but their ledger settlement is permanent. Federations should disclose this property to participants.
Consider BLS signature aggregation for high-volume protocol layers (bandwidth ledger Bet 67, royalty ledger Bet 68). Per-block aggregation reduces per-receipt PQ overhead.
Lazy migration for short-horizon receipts. Receipts with settlement < N years can remain Ed25519-only if the protocol marks them clearly.

Run command

PYTHONPATH=src python -m experiments.bets.82_post_quantum_migration

Output: experiments/bets/results/82_post_quantum_migration.json records per-phase verifiability, peak bandwidth multiplier, migration-window safety, and the strict/lenient/catastrophic flags.

Bet 64: audit non-repudiation (Merkle commitments). The signature primitive Bet 82 migrates.
Bet 68: royalty correctness (signed receipts). The signing layer Bet 82 must preserve.
Bet 70: 50-year royalty stream. The long-horizon contract that motivates PQ migration.
Bet 86: cross-federation receipts. Composes with PQ-migration for cross-federation interop.
Bet 87: privacy-preserving signatures. Group signatures will need their own PQ migration story.

Why it matters

The federation's 50-year promise (Bet 70's frame) is only credible if the cryptographic substrate holds for 50 years. Bet 82 says the migration is possible but the naive choice (SPHINCS+) is not viable due to bandwidth. The mandate (Dilithium + lazy migration + BLS aggregation) is what makes the 50-year promise tractable.

The methodological lesson: a "yes/no migration is possible" answer is insufficient for protocol design. The catalogue must measure the costs. Bet 82's catastrophic flag fires on bandwidth, not on logic, and the fix is a different PQ scheme — a small but load-bearing design choice.

The catalogue's contribution: forcing the federation to choose its PQ scheme empirically, not blindly default to whatever NIST publishes first.