Research/Bitcoin

BIP-361: Bitcoin's Three-Phase Quantum Migration Plan

BIP-361 outlines a three-phase roadmap to migrate Bitcoin away from quantum-vulnerable cryptography before CRQC arrives.

bcMaoOct 23, 2026

In April 2026, Jameson Lopp and five co-authors published BIP-361, titled “Post Quantum Migration and Legacy Signature Sunset.” The draft informational proposal lays out a three-phase roadmap to retire Bitcoin's elliptic-curve cryptography before a cryptographically relevant quantum computer (CRQC) can break it. The plan is straightforward in concept and explosive in practice: after a multi-year migration window, coins that remain in quantum-vulnerable addresses would become unspendable.

No other Bitcoin proposal in recent memory has forced the community to weigh protocol security against property rights so directly. BIP-361 asks whether it is better for coins to be frozen by consensus or stolen by quantum attackers, and the answer divides developers, custodians, and holders alike.

Why Bitcoin Needs a Quantum Migration Plan

Bitcoin's security rests on two cryptographic pillars: SHA-256 hash functions and elliptic-curve digital signatures (ECDSA and Schnorr). Hash functions are believed to be relatively resistant to quantum attack: Grover's algorithm halves the effective security (256-bit becomes 128-bit), which remains computationally infeasible. Signatures are the vulnerability. Shor's algorithm can derive a private key from a public key in polynomial time on a sufficiently powerful quantum computer.

The threat depends on when a CRQC arrives. Current estimates from NIST and academic researchers vary widely, from the early 2030s to beyond 2040. But the risk is not symmetric: attackers using a harvest-now-decrypt-later strategy can record public keys today and crack them whenever quantum hardware becomes available. Every Bitcoin transaction that exposes a public key creates a target with no expiration date.

How Many Coins Are Exposed?

Not all Bitcoin addresses reveal their public keys on-chain. Addresses that use P2PKH, P2SH, or P2WPK without address reuse expose only a hash of the public key: the key itself is revealed only when coins are spent, not when they are received. As long as a user never reuses the address, the public key stays hidden and quantum-safe in practice.

The problem lies with older output types and reused addresses. Early Bitcoin blocks used Pay-to-Public-Key (P2PK) outputs, which store the raw public key directly on-chain. Modern Taproot (P2TR) outputs also expose the public key, since the key-path spend is visible in the output script. Estimates of the total exposed supply vary: analyses cite figures ranging from approximately 1.9 million BTC in P2PK outputs alone to as many as 6.7 million BTC when counting all reused addresses and Taproot outputs. The disagreement reflects different definitions of “quantum vulnerable” and different assumptions about which coins can realistically be migrated by their holders.

The Satoshi question: An estimated 1.1 million BTC mined in Bitcoin's earliest blocks sit in P2PK addresses widely attributed to Satoshi Nakamoto. These coins have never moved. If Satoshi's keys are lost, no one can migrate them, and they become permanent targets for a future quantum attacker, or permanent casualties of a freeze.

BIP-360: The Foundation

BIP-361 cannot function alone. It depends on BIP-360, a companion proposal that introduces a new quantum-resistant output type. Originally called Pay-to-Quantum-Resistant-Hash (P2QRH), BIP-360 provides the same tapscript functionality as Taproot but removes the key-path spend that exposes a public key to quantum attack. The design deploys as a soft fork using a new SegWit witness version.

BIP-360 was merged into the Bitcoin BIP repository in February 2026. It does not itself implement post-quantum signature algorithms: it establishes the address framework that a later soft fork would populate with specific hash-based or lattice-based signature schemes. This separation means the community can agree on address structure now and choose cryptographic algorithms later, as the post-quantum field matures.

BIP-361's Three Phases

The migration plan unfolds in three phases, each measured from the activation block of BIP-360's quantum-resistant address type. The draft proposes deployment via version-bit signaling with a 90% miner threshold, though no activation date has been set.

Phase A: Address Deprecation (Year 3)

Beginning approximately three years (roughly 160,000 blocks) after activation, the network would reject any transaction that sends new coins to quantum-vulnerable address types. Existing holders can still spend from legacy addresses during this phase. The goal is to halt the growth of the vulnerable UTXO set while giving holders time to move funds to quantum-resistant addresses.

Phase A functions as a soft nudge: wallets, exchanges, and custodians would be forced to upgrade their receiving infrastructure, but no one loses access to existing funds. The three-year runway assumes that major exchanges and wallet providers can update their software in that timeframe, following the precedent set by SegWit adoption.

Phase B: Signature Sunset (Year 5)

Two years after Phase A, roughly five years after activation, the network would stop honoring ECDSA and Schnorr signature types from quantum-vulnerable outputs. This is the hard cutoff: any UTXO that has not been moved to a quantum-resistant address becomes effectively frozen. Nodes would reject transactions attempting to spend from these outputs using legacy signatures.

Phase B is where the proposal becomes politically charged. It imposes a deadline after which the network enforces a property restriction that no individual or institution can reverse without another consensus change. Coins held by lost-key addresses, deceased holders without inheritance plans, or organizations that failed to upgrade would become permanently unspendable.

Phase C: Recovery (Timeline Undetermined)

The draft acknowledges that a hard freeze creates permanent casualties and proposes a recovery mechanism using zero-knowledge proofs. Under Phase C, a holder could prove ownership of a frozen UTXO by demonstrating knowledge of the seed phrase or private key without revealing it on-chain. The proof would authorize moving the coins to a quantum-resistant address.

Phase C remains speculative. The cryptographic constructions for seed-based ZK proofs are still under active research. A complication: many early Bitcoin outputs predate hierarchical deterministic wallets and BIP-39 mnemonics, so seed-based ownership proofs would not work for the oldest and most vulnerable coins.

PhaseTimelineActionEffect on Legacy Holders
A~3 years post-activationBlock new sends to vulnerable address typesCan still spend; must migrate receiving addresses
B~5 years post-activationInvalidate ECDSA/Schnorr spends from vulnerable outputsUnmigrated coins frozen
CUndeterminedZK-proof-based recovery of frozen coinsHolders can reclaim funds by proving key knowledge

The Freeze Debate: Frozen vs. Stolen

BIP-361 forces a binary choice that Bitcoin has never confronted at this scale: is it better for vulnerable coins to be frozen by the network or stolen by a quantum attacker? Both outcomes violate core expectations about how Bitcoin works. The debate breaks into two camps, each with coherent arguments.

The Case for Freezing

Proponents argue that a controlled freeze is strictly less harmful than an uncontrolled theft. If a CRQC arrives and the network has not migrated, an attacker could drain millions of BTC from exposed addresses in a matter of hours. The resulting sell pressure and loss of confidence would threaten the entire network, not just the holders of vulnerable coins. A planned migration with a multi-year deadline gives every active holder the opportunity to protect their funds, and Phase C offers a potential path for recovering frozen coins later.

Supporters also note that exchanges, custodians, and ETF issuers holding the majority of reused-address BTC have the technical capacity to migrate well before any deadline. The coins most likely to be frozen are those with lost keys, which are already functionally removed from the supply.

The Case Against Freezing

Critics frame the proposal as a governance action that sets a dangerous precedent. Bitcoin's value proposition rests on the guarantee that no external party can restrict access to funds. If the network can freeze coins to prevent quantum theft, the same mechanism could be repurposed for sanctions compliance, regulatory pressure, or political censorship. The technical capacity to freeze is indistinguishable from the political capacity to freeze.

Tadge Dryja, co-author of the original Lightning Network paper, argued that BIP-361 prematurely couples the introduction of quantum-resistant outputs with the deactivation of legacy outputs. He contends the two decisions should be separated: deploy quantum-safe addresses now, and defer the freeze decision until the threat is imminent. Adam Back, Blockstream CEO, has pushed for optional quantum-resistant upgrades without any mandatory migration deadline.

There is also a philosophical objection: Lopp himself has described BIP-361 as a contingency plan he hopes will never be activated. The proposal exists to start a conversation about timelines and tradeoffs, not to impose a specific outcome. But once a mechanism for freezing coins exists in Bitcoin's codebase, its deployment becomes a political question rather than a technical one.

Lopp's framing: “I don't like this proposal,” Lopp has said of his own BIP. He describes it as a contingency plan: a roadmap the community can adopt if and when a CRQC becomes an imminent rather than theoretical threat.

Counterproposals and Alternatives

BIP-361 is not the only approach under discussion. Several alternatives offer different tradeoffs between urgency and caution.

The Quantum Canary (BitMEX Research)

BitMEX Research proposed a “canary fund” as an alternative trigger mechanism. The concept: create a Bitcoin address whose public key is known but whose private key was generated using a nothing-up-my-sleeve construction, proving that no one knows it. Anyone can donate BTC to this address as a bounty. If the canary address is ever spent from, it proves that a quantum computer capable of breaking elliptic-curve cryptography exists, and the network activates a pre-deployed freeze of all quantum-vulnerable outputs.

The canary approach avoids preemptive freezing: coins remain spendable until an attack is empirically demonstrated. Critics point out the fundamental incentive problem: a quantum-capable actor with access to a bounty of a few hundred BTC would likely prefer to drain multi-billion dollar P2PK addresses silently rather than ring the alarm.

Optional Migration (Adam Back)

Back argues for deploying quantum-resistant address types immediately, without any freeze mechanism. Users who care about quantum security migrate voluntarily. The freeze question gets deferred until quantum computers are closer to reality. This approach prioritizes continuity and avoids the governance precedent of forced migration, but it risks leaving a large fraction of the supply vulnerable if voluntary adoption is slow.

Rate-Limited Release (Hourglass V2)

A separate proposal suggests that if a quantum attacker breaks P2PK outputs, the stolen coins should be released at a fixed rate of approximately one BTC per block, rather than being immediately spendable. This would limit the market impact of a quantum theft by spreading the selling pressure across years, buying time for a network response. It does not prevent the theft but mitigates the systemic shock.

ApproachTriggerFreeze RiskTheft RiskGovernance Precedent
BIP-361Fixed deadline (~5 years post-activation)High: unmigrated coins frozenLow: deadline precedes CRQC estimatesSets precedent for network-imposed freezes
Quantum CanaryEmpirical: canary address spentModerate: freeze activates only after proven attackModerate: attacker may skip canaryFreeze is reactive, not preemptive
Optional MigrationNone: voluntary adoptionNone: no freeze mechanismHigh: slow adoption leaves coins exposedNo precedent set
Hourglass V2Post-theft rate limitingNone: no freezeModerate: theft occurs but impact is slowedNovel consensus rule on spending rate

Lessons from Taproot Activation

BIP-361's feasibility depends on the Bitcoin community's ability to coordinate a network-wide upgrade, and the most recent precedent is instructive. Taproot's activation (BIPs 340, 341, 342) followed a contentious debate about activation methodology. The community split over whether to use BIP-9's miner-signaling approach or BIP-8's flag-day activation. Russell O'Connor's Speedy Trial compromise shipped in Bitcoin Core 0.21.1 in May 2021 and gave miners roughly three months to signal at a 90% threshold. Taproot locked in at block 687,284 in June 2021 and activated at block 709,632 in November 2021.

The timeline from initial proposal to activation spanned roughly two years (BIP-341 was published in January 2020). But Taproot was a relatively uncontroversial upgrade that added new capabilities without restricting existing ones. BIP-361 is categorically different: it would remove existing spending capabilities. The political difficulty of the quantum migration will dwarf anything in Taproot's activation history.

If BIP-360's quantum-resistant addresses activated through a similar Speedy Trial process, and if the proposal-to-activation timeline matched Taproot's, Phase A would arrive around 2032 and Phase B around 2034. Whether that timeline aligns with CRQC development is an open question that depends on quantum computing progress that no one can reliably forecast.

What This Means for Bitcoin Layer 2 Protocols

Any quantum migration at the base layer cascades upward through Bitcoin's Layer 2 ecosystem. Protocols that rely on Bitcoin's signature primitives for their own security inherit both the vulnerability and the migration requirement.

Lightning Network

The Lightning Network is structurally exposed because its payment channels require continuous public key exposure for channel states, routing, and HTLC enforcement. Every channel open, close, and routing hop reveals public keys on-chain or in the gossip layer. A quantum migration would require updating not just the on-chain funding transactions but the entire BOLT specification for commitment transactions, revocation, and routing.

Spark and FROST Signing

Spark uses FROST threshold signatures to secure its statechain-based transfers. FROST produces standard Schnorr signatures, which means the protocol's signing infrastructure relies on the same elliptic-curve assumptions that BIP-361 aims to retire. A quantum migration at L1 would require corresponding updates to Spark's distributed key generation and signing rounds.

The transition path for Spark has a structural advantage: because transfers happen off-chain through operator-coordinated key rotations rather than on-chain signature broadcasts, the public key exposure window is narrower than in Lightning. Spark's operator set can upgrade its signing infrastructure without requiring every user to perform an on-chain transaction. The migration would still be complex, requiring new post-quantum threshold signature schemes (an area of active cryptographic research), but the operational surface is more contained than a full Lightning channel graph migration.

Layer 2 dependency: Every Bitcoin Layer 2 inherits the base layer's cryptographic assumptions. BIP-361's migration timeline sets the clock for the entire ecosystem, not just L1 holders. Protocols that build on secp256k1 need to begin planning their own migration paths in parallel.

Open Questions

BIP-361 is a draft, not a decision. Several fundamental questions remain unresolved.

  • Which post-quantum signature algorithm will Bitcoin adopt? Hash-based schemes like SPHINCS+ offer conservative security but produce large signatures. Lattice-based schemes are more compact but less battle-tested. The choice affects transaction sizes, block space economics, and fee markets.
  • Can Phase C's ZK recovery mechanism work for pre-BIP-39 keys? If not, the oldest and most vulnerable coins have no path back.
  • Should the freeze be absolute or should there be a grace period where quantum-vulnerable spends require higher fees or longer confirmation windows?
  • How should the activation mechanism work? BIP-361's draft proposes version-bit signaling at a 90% threshold, but miner signaling for a property-restricting change is politically different from signaling for a capability-adding upgrade.
  • What happens to Bitcoin ETFs and institutional custodians that hold coins in reused addresses? The migration deadline creates regulatory and operational urgency for the traditional finance infrastructure that has grown around Bitcoin since 2024.

The Road Ahead

BIP-361 is not a finished plan. It is a framework for a conversation that Bitcoin will need to have, likely within this decade. The proposal's value lies less in its specific phase timelines and more in forcing the community to confront a set of tradeoffs that do not have clean answers. Every path forward involves loss: lost coins, lost principles, or lost time.

For developers building on Bitcoin today, the practical takeaway is that cryptographic agility matters. Protocols, wallets, and infrastructure should be designed with the assumption that signature algorithms will change within their operational lifetime. The question is not whether Bitcoin will migrate away from elliptic-curve cryptography, but when and how.

For a deeper look at the address-level vulnerability that BIP-361 targets, see our analysis of Taproot's quantum exposure. For the foundational cryptography, see BIP-360's quantum-resistant address format and the post-quantum cryptography landscape for Bitcoin. Developers building on Spark can explore the Spark SDK documentation to understand how the protocol's signing architecture would interact with a post-quantum transition.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.