Appendix D: Solutions for Chapter 36

This page collects solutions and editorial notes for the exercises in Chapter 36: Quantum threat model for blockchains. Compute and derivation exercises have worked solutions; open-ended exercises have an editorial note describing what a strong answer addresses.

The fuller versions of these routines are in the blockchain_threat package under solutions/ch36-blockchain-threat-model. From a clone of the companion repository, pytest tests/ch36 runs its suite. Appendix C has the setup.

Exercise 1

Worked solution. Mosca’s inequality is $X + Y > Z$, with the exposure window $\max(X + Y - Z, 0)$.

Under the running example $X = 2$, $Y = 1$, $Z = 9$:

$$X + Y = 3, \quad Z = 9, \quad \text{breach} = \max(3 - 9, 0) = 0.$$

The consensus surface does not breach, and the Mosca budget has six years of slack: $Z - (X + Y) = 6$. That is the margin left after allowing for both the migration time and the required protection lifetime, not the gap between finishing migration and $Z$. Migration alone takes $Y = 1$ year, so it would complete eight years before $Z$. NCSC 2035 sets a planning horizon, not a predicted CRQC arrival date.

Under the aggressive early-CRQC scenario $X = 2$, $Y = 1$, $Z = 2$:

$$X + Y = 3, \quad Z = 2, \quad \text{breach} = \max(3 - 2, 0) = 1.$$

The consensus surface breaches by one year. The result is consistent with the chapter’s narrative. The consensus surface inherits the shortest $X$ of any Strand surface (validator-set rotation cadence) and the shortest $Y$ (a hard fork is the active consensus-rule change point). It is therefore the surface with the most slack against $Z$. Even so, an aggressive $Z$ that drops below the surface’s $X + Y$ produces a positive window.

Exercise 2

Worked solution. Apply surface_taxonomy.classify to each:

• STARK verifier contract, SHA-256 in FRI. SHA-256 is hash-quantum-degraded. The verifier is therefore a parameter-bump candidate: the operator swaps SHA-256 for SHA-512 (or extends the Merkle tag size) when the security margin against Brassard-Høyer-Tapp collision search is no longer comfortable.
• Operator-key signature on every state-update batch, Ed25519. Ed25519 is shor-vulnerable (EdDSA over a Shor-reducible group). The operator-key signature is a migration target, in the wave its own Mosca window sets.
• Validator-set signature on operator-key rotations, BLS-BLS12-381. BLS over BLS12-381 is shor-vulnerable. The validator-set signature is also a migration target, in the wave its own window sets.

Mosca’s inequality under $Z = 9$ gives each surface’s window:

Surface	$X$	$Y$	$X+Y$	Window
validator-set signature	8	4	12	3 years
STARK verifier contract	3	2	5	0
operator-key signature	1	2	3	0

Wave assignment:

• Primitive-swap targets: operator-key signature, validator-set signature. Both are Shor-vulnerable, which makes each a migration target without ranking it, since Figure 36.2’s caption says vulnerability class is not migration order.
• First wave: the validator-set signature, whose window is three years although it signs only when the operator key rotates.
• Second wave, which Ch 30’s program calls broad-rollout: the operator-key signature. It signs every batch, but its yearly rotation keeps $X + Y = 3$ inside the migration window.
• Parameter-bump candidate: STARK verifier contract, whose window is zero as well.

The operator’s plan therefore migrates the validator-set signature in the first wave and the operator-key signature in the second, and defers the FRI parameter bump to the next routine verifier-contract upgrade.

Exercise 3

Editorial note. A defensible classification names a primary source per primitive. NIST FIPS 203, 204, and 205 and SP 800-208, which approves the stateful hash-based XMSS and LMS, cover the standardized PQ algorithms. The Bitcoin and Ethereum protocol specifications cover the deployed primitives. A strong answer resists the temptation to put every PQ algorithm into “standardized at NIST” without checking the actual standard.

A strong answer also notes two scoping points. First, not every primitive in the lookup table is deployed on Bitcoin or Ethereum at chain-tip in 2026. EdDSA-Ed25519 is widely deployed but not on Bitcoin Layer-1 transactions. BLS-BLS12-381 is deployed on Ethereum staking but not on Bitcoin. Second, not every NIST-standardized PQ algorithm is appropriate for the on-chain transaction surface. XMSS-MT and LMS carry state-management constraints that fail the BIP-32-style derivation pattern.

Exercise 4

Worked solution. Under $Z = 9$, the chapter’s running example gives the per-surface breach window:

Rank	Surface	$X$	$Y$	$X+Y$	Breach window
1	transaction	50	5	55	46 years
2	wallet	10	4	14	5 years
3	governance	4	3	7	0
4	on-chain verifier	3	2	5	0
5	consensus	2	1	3	0

Rank 1 (transaction) is the dominant migration urgency: $X$ is bounded only by the lifetime of holdings whose keys are never rotated, so the breach window is dominated by the chain’s permanence rather than by $Y$. The dominant cost axis is gas-cost impact (PQ verification cost is a per-transaction tax on every spend).

Rank 2 (wallet) has positive breach window even though $X$ is bounded by seed lifetime, because typical seeds last a decade and the migration time across a custody operator’s full address book is several years. The dominant cost axis is key-rotation friction (every derived address must rotate to a PQ scheme).

Rank 3 (governance) does not breach under $Z = 9$ but is the first surface to start breaching under stricter $Z$. The dominant cost axis is multi-stakeholder coordination (the governance set is the slowest-moving by design).

Ranks 4 and 5 (on-chain verifier and consensus) sit comfortably inside the migration window under $Z = 9$ and are deferred until after the first-wave transaction and wallet migrations land.

Exercise 5

Editorial note. A defensible mapping records each surface as a CBOM touchpoint with its CycloneDX primitive label (Ch 25). The transaction, consensus, wallet and governance surfaces carry signature, the label Ch 25 gives its two signing touchpoints. The on-chain verifier is not a signature surface (Ch 36): its deployed primitive is SHA-256 inside the FRI commitment, so its touchpoint carries hash, with the proof system recorded beside it.

A defensible mapping also pairs each surface with a Ch 30 program phase. Transaction and wallet sit in first-wave, since both breach under $Z = 9$. The on-chain verifier is a parameter-bump candidate whose Mosca window is zero under $Z = 9$, so it sits in broad-rollout with the next routine verifier upgrade. The wallet rollout then runs on every custody operator’s own timeline. Consensus and governance sit in broad-rollout as well, since their rotational $X$ keeps each inside the migration window under $Z = 9$, at $X + Y$ of 3 and 7.

The trap is treating high-profile or high-value surfaces as first-wave when their rotational $X$ keeps them inside the migration window under $Z$ equal to 9. Broad-rollout surfaces have margin against $Z$ that the first-wave surfaces do not.