Bitcoin developers have introduced BIP-361, a draft proposal that would push the network through a staged migration away from address types whose public keys are already exposed on-chain and could therefore become vulnerable in a future quantum-computing scenario. The proposal is significant because it treats quantum risk not as a distant theoretical concern, but as a multi-year operational problem that may require changes to consensus rules, wallet behavior and custody infrastructure.
The draft builds on BIP-360’s proposed Post-Quantum output type, known as P2MR, and targets a large portion of older Bitcoin holdings. According to the proposal, between 1.7 million and 6.7 million BTC, or roughly 34% of supply, sits in legacy output types that would be considered primary migration candidates. That makes BIP-361 less a niche technical adjustment than a framework for potentially reshaping how a large share of dormant and long-held bitcoin can be spent.
A Three-Phase Plan to Force Migration Over Time
BIP-361 lays out a phased path rather than a single disruptive cutover. Phase A, scheduled to begin about three years after activation, would stop new bitcoin from being sent to legacy address types considered quantum-vulnerable, especially outputs such as Pay-to-Public-Key that expose public keys directly on-chain. The purpose is to halt further growth of the vulnerable set while giving users and service providers time to adjust. At that stage, the network would begin steering users away from insecure paths without yet freezing existing funds.
Phase B is the most consequential part of the proposal. Roughly two years after Phase A, or around five years from activation, the draft would change consensus rules so that legacy ECDSA and Schnorr signatures for identified vulnerable UTXOs would no longer be considered valid. In practice, that would freeze those outputs unless funds had already been migrated to a quantum-resistant destination such as P2MR. This is the point where BIP-361 stops being guidance and becomes a hard change to what the network accepts as a valid spend.
Phase C is framed as a possible rescue path for legitimate owners who fail to migrate in time. The concept involves zero-knowledge proof mechanisms tied to mnemonic seeds, but the idea remains at a research stage and has no fixed timetable. Because it is still unproven, the fallback mechanism cannot yet be treated as a reliable safety net for users who miss the migration window.
The Real Challenge Is Operational, Not Just Cryptographic
Implementing BIP-361 would require coordinated upgrades across the Bitcoin stack. Full nodes and client software would need to identify vulnerable output types, adjust mempool policy and eventually enforce new validation logic that rejects spends previously considered valid. That has direct implications for block validation, propagation and the long-term usability of parts of the UTXO set. A proposal about future cryptography would quickly become a present-day challenge for node behavior and network coordination.
The risk is not abstract: funds left in affected output types could become unspendable under Phase B if migration workflows are not completed on time. The burden of readiness would fall heavily on institutions responsible for large balances and older wallet infrastructure.
That is why the proposal is already likely to divide opinion. Supporters view the staged freeze as a necessary economic incentive to force migration before a credible quantum threat emerges. Critics argue that invalidating previously valid spends cuts against core ideas of user sovereignty, introduces needless friction and risks loss of funds for unaware holders. They also warn that a consensus change of this kind could increase the risk of fragmentation if parts of the ecosystem refuse to adopt it. The debate is ultimately about whether protecting Bitcoin’s long-term cryptographic security justifies rewriting the assumptions around spendability and control.
If BIP-361 advances, the result will not be a single upgrade but a long operational campaign involving client releases, testnet rehearsals, migration tooling and repeated coordination across the ecosystem. For node operators, the proposal would affect validation rules, block acceptance and gossip behavior. For custodians and market participants, it would require early planning around migration timelines, service availability and user communication. The proposal’s core message is clear: if quantum defense becomes policy, Bitcoin’s response will be measured in years of coordinated infrastructure work, not in one software patch.