Appendix D: Solutions for Chapter 37

This page collects solutions and editorial notes for the exercises in Chapter 37: Layer-1 signature migration: Bitcoin and Ethereum. Compute 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 l1_migration package under solutions/ch37-l1-signature-migration. From a clone of the companion repository, pytest tests/ch37 runs its suite. Appendix C has the setup.

Exercise 1

Worked solution. Bitcoin block weight under ML-DSA-65 at the chapter’s running-example values. The future PQ-signature soft fork is modeled as P2WPKH-style commit-then-reveal, so the spend witness carries both the public key and the signature:

$$\text{tx weight} = \text{overhead} + \text{pk bytes} + \text{sig bytes} = 380 + 1952 + 3309 = 5641 \text{ weight units.}$$

Per-block transaction throughput:

$$\left\lfloor \frac{4{,}000{,}000}{5641} \right\rfloor = 709 \text{ transactions per block.}$$

The Taproot key-path baseline (tweaked public key in scriptPubKey, witness = one 64-byte BIP-340 Schnorr signature (Wuille et al., 2020)) yields:

$$\left\lfloor \frac{4{,}000{,}000}{380 + 64} \right\rfloor = \left\lfloor \frac{4{,}000{,}000}{444} \right\rfloor = 9009 \text{ transactions per block.}$$

The throughput tax is the ratio:

$$\frac{709}{9009} \approx 0.0787, \quad \text{so ML-DSA-65 retains about 7.9 percent of the baseline.}$$

The 12.7-fold reduction is consistent with the chapter’s narrative. The dominant cost components on the ML-DSA-65 side are the per-tx public-key reveal and the signature size in witness. The per-tx overhead is small relative to either. The ratio itself is nonetheless sensitive to the overhead choice, because the overhead dominates the small classical denominator: moving it from 380 to 200 weight units would inflate the ratio to 20.7, which is why the chapter derives 380 from BIP-141’s serialization rather than treating the constant as a free parameter.

Exercise 2

Worked solution. Two composite designs over the FIPS 204 / FIPS 205 sizes from the chapter package.

Ed25519+ML-DSA-65 (the chapter reference):

• Composite signature: $64 + 3309 = 3373$ bytes.
• Composite public key: $32 + 1952 = 1984$ bytes.
• Larger component signature: $\max(64, 3309) = 3309$ bytes.
• Overhead vs the larger component alone: $3373 - 3309 = 64$ bytes.
• Multiplicative ratio: $3373 / 3309 \approx 1.019$, so about 1.9 percent overhead.
• Verification work: one Ed25519 verify plus one ML-DSA-65 verify. Under illustrative reference-implementation timings around 50 microseconds for Ed25519 and 150 microseconds for ML-DSA-65 (illustrative figures only, since actual timings depend on the implementation, the CPU, the parameter set, and constant-time hardening), the composite is roughly 33 percent slower than ML-DSA-65 alone: $(50 + 150) / 150 \approx 1.33$. Those two constants are round numbers chosen so the arithmetic is legible, and they encode a ranking the measurements do not support: on SUPERCOP’s amd64-hertz an Ed25519 verification and a Dilithium3 verification are within a few percent of each other, about 3 percent on the snapshot this book records, so a measured deployment lands nearer 2x than 1.33x (Bernstein & Lange, 2026).

Ed25519+SLH-DSA-128s (the hash-only alternative):

• Composite signature: $64 + 7856 = 7920$ bytes.
• Composite public key: $32 + 32 = 64$ bytes.
• Larger component signature: $\max(64, 7856) = 7856$ bytes.
• Overhead vs the larger component alone: $7920 - 7856 = 64$ bytes.
• Multiplicative ratio: $7920 / 7856 \approx 1.008$, so about 0.8 percent overhead.
• Verification work: one Ed25519 verify plus one SLH-DSA-128s verify. Under illustrative reference-implementation timings around 50 microseconds for Ed25519 and 3 milliseconds for SLH-DSA-128s (the actual SLH-DSA verification cost depends on the hash function, the parameter set, and the implementation), the composite is roughly 1.7 percent slower than SLH-DSA-128s alone: $(50 + 3000) / 3000 \approx 1.017$.

The byte overhead of any Ed25519+PQ composite is always 64 bytes, set by the Ed25519 signature size, regardless of the PQ component. The multiplicative ratio decreases as the PQ component grows: a composite with a larger PQ component has proportionally smaller classical overhead. The verification-time overhead behaves the same way: the Ed25519 cost is fixed, so it is a smaller fraction of the total when the PQ verification is slower.

Exercise 3

Editorial note. A defensible answer applies the surface taxonomy from Ch 36 and the candidate framework from Ch 37 to each rollup primitive.

The BLS-over-BLS12-381 operator-key signature on every state-update batch is shor-vulnerable. It is a first-wave migration target. The deployment path is the rollup operator’s smart-contract verifier upgrade, paralleling the Ethereum account-abstraction path: the rollup’s verifier contract on Layer-1 calls the new post-quantum verifier in place of the BLS verifier. A sensible cutover composite is a BLS+ML-DSA-65 design that keeps the BLS assumption beside the lattice one. It gives a legacy verifier nothing: a contract that does not parse the composite encoding cannot verify the BLS half out of it, so a legacy path has to run in parallel during the window (Ch 29’s parallel-chains pattern).

The Ed25519 end-user transaction signatures inside the rollup are also shor-vulnerable. They are first-wave under the surface taxonomy. The deployment path is the rollup’s wallet-deployment problem: end-user wallets ship a post-quantum verifier in their account-abstraction wallet code. A sensible cutover composite is the Ed25519+ML-DSA-65 reference from the chapter, since the rollup user-experience expectations match the Ethereum account-abstraction expectations.

A strong answer notes that the rollup inherits the on-chain verifier surface from the underlying STARK or SNARK construction (Ch 40) and that the on-chain verifier surface migrates on its own timeline regardless of the user-key migration timeline. The rollup operator therefore runs three parallel migrations: operator-key, end-user-key, and on-chain-verifier, each on its own cadence.

Exercise 4

Worked solution. Activation parameters for Strand’s future PQ-signature soft fork (layered on BIP-360 P2MR) under $Z = 9$.

The Mosca window for the transaction surface under the chapter’s running example is $X + Y = 50 + 5 = 55$ years against $Z = 9$. The breach window is therefore 46 years (per Ch 36 Exercise 4), dominated by the holdings whose keys are never rotated. The activation work cannot shorten the breach window for exposed keys whose holders never migrate. It bounds the exposure of every key created after activation.

A defensible activation schedule for Strand:

Parameter	Value	Justification
Soft-fork lock-in block	now + 12 months	Standard BIP-9-style miner-signal window. Gives node operators a year to upgrade their full nodes.
Activation block	now + 18 months	Six months after lock-in. Gives wallet vendors and exchanges the operational ramp to expose PQ-signature addresses to users.
Wallet-rollout target	now + 36 months	First major exchanges and custodial wallets default to PQ-signature addresses for new deposits. Existing addresses remain spendable.
Strand-specific legacy-ECDSA sunset (no new ECDSA outputs)	now + 84 months	Heilman’s seven-year figure, measured from today rather than from activation (see below). After sunset, the Strand chain accepts no new ECDSA outputs; existing ECDSA outputs remain spendable until empty. This sunset is a Strand-specific governance policy. BIP-360 itself imposes no such rule on Bitcoin.
Latest spend of any pre-CRQC ECDSA output	$Z$-day	$Z = 9$ years from chain-tip 2026 (2035). The Mosca breach window for the transaction surface is 46 years. The operator cannot bound the actual breach without retiring all ECDSA outputs before $Z$.

The seven-year sunset window is consistent with Heilman’s planning estimate, and it is a horizon measured from today rather than an offset added after activation. His stages are three years to activation and five more before 90 percent of holders have moved, which he rounds to seven years total. This schedule activates at 18 months instead of three years, so month 84 leaves 66 months of post-activation ramp against his five years. Reading the figure as a post-activation offset is the arithmetic trap in this exercise: month 84 is 66 months after an activation at month 18, so a schedule that claims both a month-84 sunset and a seven-year post-activation offset has measured one row from today and the other from activation. A defensible answer picks one origin and says which. Moving the sunset to month 102 is the other repair, and it costs the comparison against $Z$-day below, because 102 months is 8.5 years against $Z = 9$. The chapter does not require the activation and sunset windows to align. The activation horizon is the upgrade-coordination work; the sunset horizon is the operator-side migration-completion work.

The activation horizon depends on the operator-side migration ramp in addition to the block parameters above. A faster $Z$ scenario (for example $Z = 5$) does not shift every row: the lock-in and activation rows are set by the critical path from today (specification, review, signaling), and a BIP-9-style window can also fail to lock in. What moves with $Z$ is the sunset row and the room between it and activation. Under $Z = 5$ the 84-month sunset falls two years past $Z$-day, and the operator has to compress the wallet-rollout ramp or accept exposure. The sunset block cannot move later than $Z$-day without breaching the Mosca window for the transaction surface. The strongest defense of the activation parameters is therefore the relationship between the sunset block and $Z$-day, not the absolute calendar dates.

Exercise 5

Editorial note. A defensible mapping pairs each Bitcoin and Ethereum migration phase with a Ch 30 program phase and names the work-stream owner.

Bitcoin’s BIP-360 path sits in first-wave for the transaction surface during the lock-in and activation period (the chain-level work). The work-stream owner is the chain governance forum (the Bitcoin Improvement Proposal process, plus the wallet-vendor working groups that contribute reference implementations). The work shifts to broad-rollout during the wallet-vendor and exchange migration period. The work-stream owners are the wallet vendors, custodial exchanges, and the protocol developer community shipping Bitcoin Core releases. The work closes in end-of-migration with the legacy-ECDSA sunset, and that sunset is a separate proposal rather than a later stage of BIP-360. P2MR changes how outputs commit to spending conditions and imposes no rule on existing ECDSA outputs, so the sunset in Exercise 4 is Strand-specific governance policy standing in for a future, separately approved rule (Ch 41, Exercise 2). The work-stream owner is the chain governance forum again, returning to the BIP process to get that rule drafted, reviewed and activated on its own.

Ethereum’s ERC-4337 path sits in discovery during the wallet-vendor candidate-evaluation period, since each wallet vendor decides on its own signature scheme. It shifts to first-wave as wallet vendors deploy ML-DSA-65 verifiers. The work-stream owner is the wallet vendor (Argent, Safe, the L2 wallet teams). It moves to broad-rollout as users migrate balances from EOA-style ECDSA wallets to smart-contract wallets. The work-stream owner is the user (with strong nudges from the wallet vendor’s UI). It does not close in end-of-migration without an Ethereum-side sunset rule for ECDSA EOAs, which would require a hard fork. Pending such a rule, the Ethereum side runs broad-rollout indefinitely.

A strong answer notes that the two paths run on different cadences. Bitcoin’s soft-fork path forces a coordinated activation block across the network. Ethereum’s account-abstraction path admits a per-wallet timeline; the chain itself does not require a coordinated cutover. The Ch 30 four-phase program applies to both, but the phase-end criteria differ: Bitcoin’s end-of-migration is the legacy sunset; Ethereum’s end-of-migration is the operator-defined target balance migration percentage.

A strong answer also notes that the operator’s CBOM (Ch 25) records two distinct touchpoints for Strand-style chains operating across both Bitcoin and Ethereum bridges: a Bitcoin-side transaction-signature touchpoint and an Ethereum-side transaction-signature touchpoint. The two touchpoints have different migration timelines, different work-stream owners, and different success criteria. The CBOM is the input to the Ch 30 program. The program’s phase-end gates differ per touchpoint.

References

Bernstein, D. J., & Lange, T. (2026). eBACS: ECRYPT Benchmarking of Cryptographic Systems, SUPERCOP results for amd64-hertz (AMD Ryzen 7 7700, Zen 4). eBACS amd64-hertz results, sign, kem and dh pages; supercop-20260831, read 14 September 2026. https://bench.cr.yp.to/results-sign/amd64-hertz.html

Wuille, P., Nick, J., & Ruffing, T. (2020). BIP-340: Schnorr Signatures for secp256k1. Bitcoin Improvement Proposal. https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki