Appendix D: Solutions for Chapter 41
Solutions and editorial notes for Chapter 41: Governance, hard forks, and migration case studies. 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 governance package under solutions/ch41-governance. From a clone of the companion repository, pytest tests/ch41 runs its suite. Appendix C has the setup.
Exercise 1
Section titled “Exercise 1”Worked solution. Cross-stakeholder activation window in weeks for a stated chain with the following coordination cycles: a 20-week proposal-review window, a 12-week economic-actor lead window, a 6-week validator-set update window, and a 10-week infrastructure-lead window running in parallel.
The activation window sums three components on the critical path: the proposal-review weeks, the economic-actor or client-team lead weeks, and the validator-set update weeks. The infrastructure-lead window runs in parallel and does not stack onto the critical path.
The fractional-year figure:
Compared against the reference Ethereum All Core Devs cycle ( weeks years), the stated chain runs 14 weeks longer. The dominant component of the difference is the proposal-review window (20 versus 12 weeks, a difference of 8 weeks). The economic-actor lead window contributes 4 additional weeks (12 versus 8 weeks). The validator-set update window contributes 2 additional weeks (6 versus 4 weeks). The infrastructure-lead window does not enter the critical-path comparison because it runs in parallel.
The 38-week total fits inside the safe window at the central scenario (, safe window years weeks). It also fits inside the safe window at the narrow scenario (, safe window 3 years weeks). The activation window does not constrain the cadence under any scenario the matrix admits at the Strand anchor. The cadence is set by the governance committee per the third inline block.
Exercise 2
Section titled “Exercise 2”Worked solution. The Bitcoin BIP process for a post-quantum proposal in six stages, with the work-stream owner from the chapter’s stakeholder matrix and a one-line deliverable per stage. The chain hook for the post-quantum proposal is BIP-360 Pay-to-Merkle-Root (P2MR) (Beast et al., 2024), a Draft soft-fork proposal at chain-tip 2026 that mitigates long-exposure quantum risk by removing the Taproot key path. Per the closed Ch 37 framing, P2MR by itself does not introduce a post-quantum signature opcode. ML-DSA and SLH-DSA are named in the BIP as candidates for future work in a separate, not-yet-drafted soft fork.
| Stage | Work-stream owner | Deliverable that closes the stage |
|---|---|---|
| draft on bitcoin-dev | core-development-team | a written proposal posted to the bitcoin-dev mailing list |
| BIP-repository acceptance | core-development-team | a numbered BIP merged into the bitcoin/bips repository at Draft status |
| reference-implementation pull request | core-development-team | a reference implementation pull request against Bitcoin Core or a hard-fork client |
| audit | core-development-team (co-owns with security-audit firm) | an external audit-firm review of the reference implementation |
| economic-actor lead window | mining-pool, exchange, custodian, wallet-vendor teams | release builds staged against a published activation height |
| activation | validator-coordinator (mining-pool ecosystem) | the BIP activates at the named height under the chosen deployment mechanism |
Stage 1 closes when the idea has been discussed on the bitcoin-dev mailing list, which is the precondition BIP 3 sets before an editor will assign a number. Stage 2 closes when the BIP editor merges the proposal at Draft status. The BIP-repository merge is a process gate, not a binding consensus decision. Stage 3 closes when the reference implementation passes the published Bitcoin Core test suite. Stage 4 closes when the audit-firm engagement returns a clean audit report. For a post-quantum BIP, the audit covers both the implementation bugs (validation-cost regressions against block weight and script resource limits, reference-implementation bugs) and the cryptographic claims (the post-quantum signature scheme’s reduction matches the BIP’s claimed security argument). Stage 5 runs the longest at chain-tip 2026 (roughly 26 weeks per Block 2 of the chapter). The lead absorbs mining-pool versionbits signaling, exchange release-build staging, custodian cold-storage signing-path migration, and wallet-vendor address-derivation updates. Stage 6 closes when the chosen deployment mechanism (BIP 9 versionbits, BIP 8, or a soft-fork-specific mechanism) reaches its activation threshold and the new opcode goes live at the named height.
BIP-360 P2MR at chain-tip 2026 sits at Stage 2 (BIP-repository Draft status, v0.12.1 per the closed Ch 37 framing, Layer: Consensus / soft fork). The proposal has not yet activated on mainnet. A defensible answer notes that BIP-360 P2MR by itself is not a post-quantum signature opcode. It only changes how Bitcoin outputs commit to spending conditions. ML-DSA and SLH-DSA are named candidates for future post-quantum signature work in a separate, not-yet-drafted soft-fork proposal. A follow-on BIP for governance-side coordination metadata (the activation choreography itself, not the new opcode) may be a parallel proposal that lands separately from BIP-360.
Exercise 3
Section titled “Exercise 3”Editorial note. A defensible answer applies the three-stakeholder taxonomy to a stated rollup or L2 bridge and decomposes the post-quantum migration into the three work streams.
The reader picks a named system (an L2 rollup such as Starknet or Arbitrum, a cross-chain bridge, or a validator-aggregator service). For each work stream, the answer states the stakeholder-specific cadence and the deliverable.
A defensible answer for an L2 rollup decomposes as follows. The protocol-developer work stream is the rollup core team that ships the verifier-contract upgrade and the rollup-side governance proposal. The cadence is the rollup’s governance-forum proposal-review window, between 4 and 12 weeks depending on the rollup’s governance rules. The validator-operator work stream is the rollup sequencer-and-prover team plus the L1 multisig committee that signs the bridge upgrade. The cadence is the rollup’s L1-commitment cycle plus the multisig-approval threshold turnaround. The infrastructure-service-provider work stream is the rollup-specific block explorer, the rollup-specific bridge UI, and any third-party indexer that surfaces rollup state. The cadence is the infrastructure-lead window from Block 2 of the chapter (roughly 8 weeks at chain-tip 2026). The deliverable is end-user continuity across the activation.
A defensible answer for a cross-chain bridge decomposes differently because the validator-operator work stream is split across two chains. The protocol-developer work stream owns both chain-side proposals. The validator-operator work stream is the union of the source-chain validators and the destination-chain validators. The infrastructure-service-provider work stream is the per-chain explorer and indexer ecosystem plus any cross-chain message-relayer services. The proposal-review and validator-set update components run twice (once per chain). The cross-chain message-relayer service has to upgrade its signature-verification logic at the bridge cutover.
A strong answer notes the candidate set per work stream. The protocol-developer work stream is constrained by the L1’s signature opcode set: an L2 rollup can deploy any post-quantum candidate the L1 verifier accepts; a cross-chain bridge is constrained by the more restrictive of the two L1 opcode sets. The validator-operator work stream is constrained by the consensus-client’s signature primitive set: SLH-DSA-128s rolls cleanly into a multisig because the verifier is hash-only; threshold ML-DSA is research-grade for reasons of production readiness rather than for want of a combiner. Quorus and proposals like it jointly generate one ML-DSA public key and combine off-chain into a signature that verifies under the unmodified FIPS 204 verifier (Bienstock et al., 2025). What is missing is the chain deployment this matrix assumes, interoperable implementations, and the years of cryptanalysis a long-lived governance key warrants (Ch 39). SLH-DSA is the candidate whose threshold combiner is genuinely open. The infrastructure-service-provider work stream is constrained by display and indexing constraints: a longer post-quantum signature size (SLH-DSA-128s at roughly seven kilobytes) breaks fixed-width display assumptions in some explorers and indexers.
Exercise 4
Section titled “Exercise 4”Worked solution. Strand governance-rotation cadence under given the cross-cycle stakeholder coordination tempo from Block 2 of the chapter.
The Strand governance surface from Ch 36 has years and years. Under the signed margin, whose positive part is Ch 36’s exposure window, is:
The safe window is:
The recommended cadence under no breach is governance-trigger: rotate the governance keys at named governance events rather than at a fixed calendar interval. The Mosca-implied rotation interval under no breach is zero. The safe-window field reads six years. The recommendation envelope per the third inline block:
central Z= 9 breach= -2 safe_window= 6 interval= 0 cadence=governance-triggerThe cross-stakeholder coordination tempo from Block 2 of the chapter sits at 46 weeks for the Bitcoin BIP cycle ( years) and at 24 weeks for the Ethereum All Core Devs cycle ( years). Both fit inside the six-year safe window with comfortable margin: the Bitcoin BIP cycle absorbs roughly 15% of the safe window per activation; the Ethereum All Core Devs cycle absorbs roughly 8%. A governance committee that rotates the Strand governance keys once every two to three years uses at most three years of the six-year safe window, leaving three years of margin under the Bitcoin BIP cadence.
The per-stakeholder action that the cadence absorbs without forcing a between-vote rotation is the validator-coordinator’s consensus-rule deploy on the validator-operator work stream. The deploy phase runs roughly four weeks (the validator-set update window in Block 2), which is small relative to both the activation window total and the safe window. The infrastructure-service-provider’s read-side deploy runs in parallel with the client-team release lead time and does not extend the critical path. The protocol-developer work stream’s propose and audit phases (the longest critical-path components on Bitcoin) run inside the proposal-review and economic-actor lead windows, both well below the six-year safe window.
A sensitivity check on the stakeholder coordination tempo: even if the Bitcoin BIP cycle stretches to twice its chain-tip 2026 anchor (92 weeks years) due to extended economic-actor coordination, the cycle still fits inside the six-year safe window. The doubled cycle absorbs roughly 30% of the safe window per activation, which allows two further activations within the six-year horizon. The cadence stays governance-trigger under any reasonable stakeholder coordination tempo at .
Exercise 5
Section titled “Exercise 5”Editorial note. A defensible answer maps the governance migration to the Ch 30 four-phase program (discovery, first wave, broad rollout, end of migration) and names the work-stream owner from the chapter’s stakeholder matrix for each phase.
A defensible answer assigns the four phases as follows. Discovery runs at the protocol-developer work stream (core-development-team owner): the deliverable is a written proposal that names the candidate signature scheme, the activation height, and the rollback path. The gating criterion is rough consensus on the bitcoin-dev mailing list, the eth-magicians forum, or the rollup-side governance forum. First wave runs jointly across all three work streams: the protocol-developer ships a reference implementation; the validator-operator runs the implementation on a public testnet; the infrastructure-service-provider tests end-user breakage of indexers, explorers, wallets, and bridges. The deliverable is a clean testnet run plus an audit-firm report. The gating criterion is the absence of soundness bugs and the absence of reader-visible breakage in any infrastructure surface. Broad rollout runs at the validator-operator and infrastructure-service-provider work streams jointly: the validator set upgrades the consensus client at the activation block, and the read-side surface swaps in parallel. The deliverable is end-user continuity across the activation. The gating criterion is the absence of chain splits, the absence of reorgs caused by validator-set fragmentation, and the absence of broken indexer schemas. End of migration runs at the validator-operator work stream: the deliverable is the deactivation of the legacy Schnorr-secp256k1 verifier opcode. The gating criterion that admits this final phase is two-fold. First, the post-quantum verifier opcode has run cleanly for the full transition window. Ch 40 leaves that window’s length to the operator. Its own worked cadence costs three weeks of wall-clock for the whole five-phase upgrade, transition included. Second, no governance proposal in the same cadence horizon has rolled back to the legacy opcode.
A strong answer notes that the four-phase program does not run cleanly without the cross-stakeholder choreography from Block 2 of the chapter. The cross-cycle activation window is the discovery-plus-first-wave cadence. The validator-set update window is the broad-rollout cadence. The transition window is the end-of-migration cadence. A governance committee that runs the four phases without naming the per-phase work-stream owner, or without quantifying the per-phase cadence, ships a migration that may stall at the broad-rollout phase. The stakeholder matrix is what forces the question of ownership before the phase blocks a group.
A second strong-answer note concerns candidate selection at the discovery phase: see Ch 39 §“Pick the candidate per validator-set byte budget” for the SLH-DSA-128s vs threshold-ML-DSA tradeoff that gates the rollback feasibility question.