Fixing Bitcoin: The Post-Quantum Migration Technical Roadmap

Introduction

The previous article in this series mapped Bitcoin’s quantum attack surface: 6.7 million BTC with exposed public keys, 1.7 million in permanently vulnerable P2PK scripts, and a Taproot upgrade that reintroduced the very exposure model that SegWit had resolved. The natural question is: what exactly needs to be built to fix it?

The answer is not a single patch. It is a coordinated set of changes spanning Bitcoin’s consensus layer, transaction format, signature verification logic, address encoding, UTXO migration mechanism, and P2P network parameters. Some of these changes can be deployed as a backward-compatible soft fork. Others require the Bitcoin community to reach consensus on questions that have historically been divisive: how large should witness data be, how long should the migration window last, and what happens to coins that are not migrated in time.

This article walks through the engineering roadmap from bottom to top: the new output type (BIP-360), the signature algorithm tradeoffs, the witness economics, the migration mechanics (BIP-361), and the emergency escape hatches that protect against a timeline that moves faster than consensus. Where working implementations exist, I reference them. Where open questions remain, I flag them.

BIP-360: Pay-to-Merkle-Root (P2MR)

The foundation of Bitcoin’s post-quantum migration is a new output type that eliminates public key exposure on-chain. BIP-360, published in February 2026 and merged into Bitcoin’s official BIP repository, proposes Pay-to-Merkle-Root (P2MR) as that foundation.

P2MR is structurally similar to Taproot (P2TR) with one critical removal: the key-path spend. Taproot allows two ways to spend an output. The key path reveals the tweaked public key on-chain and requires a single Schnorr signature. The script path reveals only the specific branch of a Merkle tree that satisfies the spending condition. The key path is faster and cheaper, but it permanently exposes the public key to quantum attack from the moment the output is created.

P2MR removes the key path entirely. The output commits only to the Merkle root of the script tree. No public key appears on-chain at creation time. When spending, the user reveals only the relevant script branch, a control block proving inclusion in the Merkle tree, and the signatures satisfying that branch’s conditions. The public key (now a post-quantum key) is exposed only at spend time and only within the witness data.

Technical Implementation

BIP-360 defines P2MR as a SegWit version 2 output, using bc1z address encoding via bech32m. The version number is significant: Bitcoin’s script versioning system (introduced in SegWit and extended in Taproot) was designed to allow new witness programs without hard forks. Version 0 powers P2WPKH and P2WSH. Version 1 powers P2TR. Version 2 is the next available slot, and P2MR claims it.

The BTQ Technologies testnet implementation (Bitcoin Quantum testnet v0.3.0, released March 2026) provides the first functional validation of this design. The implementation includes full P2MR consensus validation (Merkle root commitment verification, control block validation), five ML-DSA (Dilithium) signature opcodes enabled within the P2MR tapscript context, and end-to-end wallet tooling for creating and spending P2MR transactions. The testnet has attracted over 50 miners and processed more than 100,000 blocks.

The implementation confirms several properties that matter for the broader Bitcoin ecosystem. P2MR maintains compatibility with scripting constructs that underpin Lightning, BitVM, Ark, multisignature setups, and timelocks. The SegWit witness discount applies to P2MR witness data, which is critical for managing the fee impact of larger post-quantum signatures. The testnet uses one-minute block spacing to accelerate iteration, but the consensus rules are designed for Bitcoin’s standard ten-minute target.

What P2MR Does Not Solve

P2MR eliminates the at-rest attack vector by keeping public keys off-chain until spend time. When combined with post-quantum signature verification in its script leaves, it also eliminates the on-spend vector: the key exposed in the mempool during a spending transaction is a post-quantum key that a CRQC running Shor’s algorithm cannot break. However, P2MR does not protect legacy hash-protected addresses (like P2WPKH) from on-spend attacks when their owners eventually spend from those addresses to migrate. The migration transaction itself exposes the classical public key in the mempool, creating a race window until the funds arrive in the new P2MR output.

Defenses against on-spend attacks require additional mechanisms: private mempools (where transactions are submitted directly to miners rather than broadcast publicly), commit-reveal schemes (where the spending commitment is recorded in one block and the full transaction revealed in a later block), and faster block confirmation (which is not adjustable on Bitcoin’s base layer). P2MR addresses the more tractable problem, which is also the larger one in terms of total exposed value.

P2MR also does not solve the dormant asset problem. Coins locked in P2PK scripts with lost private keys cannot migrate to P2MR addresses because migration requires the private key. That problem requires a separate policy solution, discussed in the previous article and the governance article later in this series.

Algorithm Selection: ML-DSA, FN-DSA, or SLH-DSA?

BIP-360 defines the output type. It does not prescribe a single post-quantum signature algorithm. The choice of algorithm has profound implications for transaction size, fee economics, verification throughput, and implementation risk. Three NIST-standardized candidates are in contention.

ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium)

ML-DSA is the standards-stable baseline. It is a lattice-based signature scheme with three security levels:

For comparison, a current ECDSA signature is 64-72 bytes with a 33-byte public key. ML-DSA-44 represents a roughly 35x increase in signature size.

ML-DSA’s advantages for Bitcoin: it is FIPS-finalized (August 2024), has undergone years of scrutiny through the NIST standardization process, supports deterministic signing (eliminating nonce-related side-channel vulnerabilities), and verifies faster than ECDSA on ARM hardware (0.14ms vs. 0.88ms at security level 5, according to benchmarks on ARM-based architectures).

The BTQ testnet implementation uses ML-DSA (specifically, the Dilithium variant) for its five P2MR signature opcodes. ML-DSA-44 is the current BIP-360 baseline for the initial migration phase.

FN-DSA (Draft FIPS 206, formerly Falcon)

FN-DSA is the compact alternative. At security level 1 (FN-DSA-512), it produces 897-byte public keys and 666-byte signatures, roughly one-third the size of ML-DSA-44. This size advantage makes FN-DSA significantly more attractive for bandwidth-constrained applications like Lightning Network gossip and on-chain HTLC settlement, where every byte has a direct fee cost.

The tradeoff: FN-DSA is not yet FIPS-finalized. The NIST standardization is in progress but has been slower than ML-DSA due to implementation complexity. Falcon’s signing operation requires sampling from a discrete Gaussian distribution using floating-point arithmetic, which creates side-channel risks that are difficult to mitigate in software implementations. The signing operation itself is computationally heavier than ML-DSA’s, which matters for high-frequency operations like Lightning commitment transaction updates.

For Bitcoin’s base layer (where signing happens relatively infrequently but on-chain size determines fees), FN-DSA’s compact footprint is compelling. For Lightning (where signing happens constantly but on-chain settlement is rare), the tradeoff is more nuanced, as I analyze in the Lightning migration article.

SLH-DSA (FIPS 205, formerly SPHINCS+)

SLH-DSA takes a fundamentally conservative approach: its security rests entirely on hash functions rather than lattice mathematics. If lattice-based assumptions turn out to be weaker than believed (an active area of research, given work on Decoded Quantum Interferometry and related algorithms), SLH-DSA remains secure.

The cost of this conservatism: enormous signatures. SLH-DSA-SHA2-128s produces a 7,856-byte signature. The “fast” variant (SLH-DSA-SHA2-128f) is 17,088 bytes. Higher security levels exceed 49,000 bytes per signature. Public keys are tiny (32-64 bytes), but the signature size renders SLH-DSA impractical as a primary Bitcoin signature algorithm.

SLH-DSA’s role in the Bitcoin ecosystem is as a backup and hedge: if a vulnerability is discovered in lattice-based cryptography, SLH-DSA provides a fallback that does not share the same mathematical foundations. Some hybrid proposals include an SLH-DSA signature alongside ML-DSA to provide defense in depth, at the cost of further increasing witness size.

The Practical Choice

For Bitcoin’s initial PQC migration, ML-DSA-44 is the pragmatic choice: FIPS-finalized, well-studied, reasonable (if large) signature size, fast verification. FN-DSA-512 becomes the preferred upgrade path once FIPS 206 is finalized, offering a roughly 3x reduction in on-chain footprint. SLH-DSA remains the conservative emergency option.

The BIP-360 design accommodates this progression. Because P2MR commits to a Merkle root of scripts rather than to a specific key type, different leaves of the script tree can use different signature algorithms. A single P2MR output could contain an ML-DSA spending path, an FN-DSA spending path, and an SLH-DSA emergency recovery path, with only the path actually used revealed at spend time. This is crypto-agility built into the output structure itself.

Hybrid Signatures During Transition

The CNSA 2.0 framework from the NSA mandates that all networking equipment use post-quantum cryptography by 2030, and explicitly requires hybrid schemes during the transition period. The principle applies to Bitcoin: combining a classical signature (Schnorr or ECDSA) with a post-quantum signature (ML-DSA) ensures that the system remains secure if either primitive is independently compromised.

In practice, a hybrid P2MR spending condition would require the spender to produce both a valid Schnorr signature and a valid ML-DSA signature. The Taproot Merkle tree structure makes this straightforward: a script leaf can contain OP_CHECKSIG for the classical key followed by a post-quantum verification opcode for the ML-DSA key, with both required to spend.

The cost is additive. A hybrid spend would include both a ~64-byte Schnorr signature and a ~2,420-byte ML-DSA-44 signature (plus both public keys) in the witness data. Hybrid mode roughly doubles the already-large PQC witness compared to a PQC-only spend. But this cost applies only during the transition period; once confidence in the post-quantum algorithm is established, the classical component can be deprecated.

Witness Economics: Can Bitcoin Absorb the Bloat?

The witness discount, introduced with SegWit in 2017, counts witness data at one-quarter the weight of non-witness data for the purposes of block size limits. Bitcoin’s block weight limit is 4 million weight units (WU). Non-witness data costs 4 WU per byte; witness data costs 1 WU per byte.

This discount was designed to incentivize moving data into the witness, and it substantially cushions the impact of larger PQC signatures. An ML-DSA-44 signature of 2,420 bytes costs 2,420 WU in the witness, compared to 9,680 WU if it were in non-witness data. A hybrid ML-DSA-44 + Schnorr witness adds roughly 3,800 WU per input, compared to ~110 WU for a current Schnorr-only spend.

The practical consequence: a block that currently holds roughly 2,500-3,000 standard transactions would hold roughly 500-700 PQC transactions at the same weight limit. Throughput drops by a factor of 4-5x. Transaction fees would increase proportionally, assuming demand remains constant.

Whether this throughput reduction is acceptable is a governance question as much as a technical one. The 2017 block size debate, which led to the Bitcoin Cash hard fork, centered on a far smaller parameter change. PQC migration will reopen that debate with higher stakes: the alternative to accepting larger witnesses is remaining vulnerable to quantum attack.

The BTQ testnet explicitly restored the SegWit discount in its implementation, confirming that the P2MR design is engineered to operate within Bitcoin’s existing weight-limit framework rather than requiring a weight-limit increase. Whether the community ultimately adjusts the weight limit to preserve throughput is a separate decision.

BIP-361: The Three-Phase Migration

BIP-361, published in April 2026 by Jameson Lopp and five co-authors including Pierre-Luc Dallaire-Demers and Christian Papathanasiou, proposes a structured sunset of legacy signature types. The proposal is titled “Post Quantum Migration and Legacy Signature Sunset” and builds on BIP-360 as its prerequisite.

Phase A begins approximately three years after BIP-360 activation. The network stops accepting new outputs sent to legacy quantum-vulnerable address types (P2PK, P2PKH, P2SH, P2WPKH, P2WSH, P2TR). All new outputs must use P2MR or another quantum-safe format. Existing legacy UTXOs remain spendable.

Phase B kicks in approximately two years after Phase A (roughly five years after BIP-360 activation). Legacy ECDSA and Schnorr signature verification is disabled at the consensus layer. Coins in addresses that have not migrated to P2MR become frozen: they exist on the ledger but cannot be moved. The total supply that would be affected, as of early 2026, is approximately 6.7 million BTC if no migration occurs during the Phase A window.

Phase C remains under research. It would introduce a zero-knowledge proof recovery mechanism allowing owners of frozen coins to prove they control the original private key (via their BIP-39 seed phrase) without revealing the key on-chain. This proof would authorize a migration transaction to a P2MR address.

Migration Throughput

The critical question: can the Bitcoin network physically process enough migration transactions within the Phase A window?

The Project Eleven report estimated that migrating the full UTXO set at current transaction rates would take several months of dedicated throughput, and potentially years if migration competes with normal transaction volume. The analysis I conducted in a previous conversation suggests the engineering is achievable in 4-6 years at moderate sustained migration rates, assuming migration transactions coexist with normal economic activity.

The three-year Phase A window is designed to provide sufficient runway. Exchanges and custodians, which control a large fraction of vulnerable Bitcoin, would likely migrate early (under regulatory and insurance pressure). Individual holders with modern HD wallets could migrate with a single transaction per wallet. The long tail of small-balance UTXOs and dormant addresses would take longer but represents a smaller fraction of total value.

The Controversy

BIP-361 has generated intense community backlash. Critics call the phased freeze “authoritarian” and “confiscatory,” arguing that it violates Bitcoin’s foundational promise that private key possession equals permanent, unconditional ownership. The BIP-361 authors respond that a quantum attacker stealing dormant coins constitutes theft from the entire network: “Coins stolen by a quantum computer would devalue every other bitcoin. Think of it as theft from everyone.”

Alternative proposals include Dan Robinson’s PACTs (Provable Address-Control Timestamps), which let dormant holders prove key control without moving coins, and Adam Back’s advocacy for voluntary upgrades without forced freezing. Whether BIP-361 activates in its current form, evolves into something softer, or is rejected entirely will depend on the consensus-building process discussed in the governance article.

Commit-Delay-Reveal: Interim On-Spend Protection

While BIP-360/361 work their way through the consensus process, interim measures can reduce exposure to on-spend attacks for hash-protected addresses.

The commit-delay-reveal scheme, proposed in various forms by Stewart et al. (2018) and discussed on the Bitcoin development mailing list, works as follows: the spender first broadcasts a commitment (a hash of the full transaction) without revealing the public key. After a mandatory delay period (measured in blocks), the spender reveals the full transaction including the public key and signature. If a quantum attacker observes the commitment, they cannot extract the public key (because it is hashed). By the time the public key is revealed in the second transaction, the commitment has already been recorded, preventing the attacker from front-running.

The tradeoff is latency. Every transaction takes two confirmations instead of one, adding 10-20 minutes of delay. For normal commercial payments, this may be acceptable. For time-sensitive applications like Lightning channel closures and HTLC settlement, the added delay interacts poorly with existing timelock constraints. The mechanism also increases on-chain footprint (two transactions per payment) at a time when block space is already under pressure from larger PQC signatures.

Commit-delay-reveal is a stopgap, not a solution. It buys time while the PQC soft fork is finalized and activated.

Emergency Escape Hatches

The migration timeline assumes an orderly progression: BIP-360 activation, Phase A voluntary migration, Phase B legacy sunset, eventual Phase C recovery. But what if quantum capability arrives faster than consensus?

Two prototype mechanisms, both released in April 2026, address this scenario.

ZK-STARK Seed-Lifting (Roasbeef/Osuntokun)

On April 8, 2026, Olaoluwa “Roasbeef” Osuntokun, CTO of Lightning Labs, released a working prototype titled “Post-Quantum BIP-86 Recovery via zk-STARK Proof of BIP-32 Seed Knowledge.” The system generates a zk-STARK proof demonstrating that a specific Taproot public key was derived from the user’s master seed via the standard BIP-32/BIP-86 derivation path, without revealing the seed or any private keys.

The technical properties matter. zk-STARKs rely on hash functions and Merkle trees for their soundness guarantees, with no dependence on elliptic curves or discrete logarithms. They are themselves quantum-resistant. An adversary attempting to forge a proof would need to find a colliding BIP-32 seed that produces the same public key, a task that remains computationally infeasible even for quantum computers.

The unoptimized prototype generates a proof in roughly 55 seconds on an Apple Silicon M4 Max MacBook, consuming about 12 GB of RAM and producing a 1.7-1.8 MB proof. Osuntokun reported that lighter variants run in under three seconds. Production versions would produce smaller, aggregatable proofs suitable for on-chain verification.

In a scenario where an emergency soft fork disables key-path spends to prevent quantum theft, this proof would allow legitimate holders to sweep their funds into new P2MR addresses via the script path, even without revealing their classical private keys. The mechanism is specifically designed for the BIP-361 Phase C recovery scenario, but could also serve as an independent rescue mechanism in a more acute emergency.

Quantum Safe Bitcoin (QSB)

The day after Osuntokun’s release, StarkWare researcher Avihu Levy published Quantum Safe Bitcoin (QSB), a transaction-level construction that achieves quantum resistance using hash-based “hash-to-sig” proof-of-work puzzles. The approach uses Lamport-style one-time signatures, which depend only on the preimage resistance of hash functions.

QSB’s key property: it requires no consensus changes. The construction fits within Bitcoin’s existing legacy script limits (201 opcodes, 10,000 bytes) and can be used today, on mainnet, by anyone willing to pay the cost. StarkWare CEO Eli Ben-Sasson called it “huge,” characterizing it as making Bitcoin quantum-safe immediately for users who adopt it.

The cost is non-trivial. QSB transactions require intensive GPU computation for proof generation and are estimated at $75-200 per transaction due to their larger size and computational overhead. For high-value transfers or emergency rescue operations, this cost may be acceptable. For routine payments, it is prohibitive.

QSB and the ZK-STARK seed-lifting approach are complementary. QSB provides proactive quantum resistance that any user can adopt today, at a premium. The ZK-STARK approach provides reactive recovery for funds that may be frozen by a future emergency soft fork. Together, they form a defense-in-depth strategy that reduces the consequences of a timeline surprise.

P2P Network Impact

Larger transactions affect more than block space. The P2P network that propagates transactions and blocks must handle increased data volumes without degrading performance for resource-constrained nodes.

Current Bitcoin transactions average roughly 250-400 bytes. A PQC transaction with an ML-DSA-44 signature (2,420 bytes) and public key (1,312 bytes) in the witness would be roughly 3,900-4,100 bytes including base transaction overhead, a 10-15x increase over current typical transaction sizes. A hybrid (classical + PQC) transaction would be larger still. These larger transactions affect mempool memory usage, compact block relay efficiency (which assumes transactions are already known to the receiving node), and propagation latency across the global network.

Relay policies will need adjustment. Current default mempool size (300 MB) may need to increase. Transaction selection algorithms in block template construction will need to account for the different weight economics of PQC transactions. Compact block relay (BIP-152) should continue to function because the mechanism transmits transaction shortIDs rather than full transactions, but the fallback path (sending full blocks) becomes more expensive.

For lightweight nodes and mobile wallets, the impact is mitigated by the witness discount (witnesses can be pruned by non-archival nodes) and by technologies like Neutrino (BIP-157/158 client-side block filtering). But the increased baseline data load strengthens the argument for maintaining, and potentially increasing, investment in node infrastructure.

The Engineering Timeline

Assembling these components into a realistic timeline:

Already available (2026): BIP-360 draft merged in BIP repository. BTQ testnet with working P2MR implementation. Roasbeef’s ZK-STARK recovery prototype. StarkWare’s QSB for individual quantum-safe transactions. ML-DSA FIPS 204 finalized.

Near-term (2026-2027): BIP-360 review, refinement, and security audits within Bitcoin Core. FN-DSA (FIPS 206) expected to reach final standard. Hardware wallet vendors begin integrating PQ signature support. Exchange and custodian migration planning.

Medium-term (2027-2029): BIP-360 soft fork activation (assuming community consensus, which is the binding uncertainty). Phase A migration begins. Lightning Network transport encryption migrates to hybrid ML-KEM (can happen independently of L1 soft fork). Wallet software defaults to P2MR for new addresses.

Longer-term (2029-2032): Phase A window closes, Phase B legacy sunset (under BIP-361 timeline). Phase C recovery mechanisms deployed. Lightning funding transactions migrate to hybrid P2MR multisig. Full quantum resistance achieved for actively managed Bitcoin.

Never (without policy intervention): Dormant P2PK coins with lost keys. These remain a fixed target for the first CRQC operator. The policy options (digital salvage, bad sidechain, burn, hourglass) are discussed in the vulnerability and governance articles.

This timeline is achievable. Whether it is achieved depends on governance. The next articles examine how Ethereum’s very different architecture shapes its own migration path, and how the Lightning Network compounds Bitcoin’s challenges with structural vulnerabilities of its own.