This “quantum-safe” Bitcoin idea eliminates Taproot’s key path and intentionally increases fees.
Bitcoin developer contributors have just cleared a documentation hurdle that Crypto Twitter had been treating like an emergency quantum patch. It wasn’t like that.
On February 11, a proposal for a new output type, Pay-to-Merkle-Root (BIP-0360), was merged into the official Bitcoin Improvement Proposals repository. No nodes have been upgraded. There is no activation timeline.
The BIP repository itself warns that publication does not mean consensus or adoption, nor does it mean the idea is even good. What actually happened was that the draft specification met the threshold to be within range of officially documented status.
But framing P2MR reveals something more interesting than the merger itself. The Bitcoin developer community is grappling with migration problems that can’t be solved with clever cryptography alone.
The real story is that Bitcoin’s upgrade path is slow, difficult to adjust, and preparing for low-probability, high-consequence risks requires starting years before anyone agrees that the threat is real.
Taproot without key path door
It is easy to understand P2MR if you think of it as Taproot with one piece removed.
The current Taproot output (P2TR) commits the adjusted public key. When spending from Taproot output, users have two options: use a key path (a simple signature that looks like any other Bitcoin signature) or a script path (reveal one script in the Merkle tree of possible scripts and prove that it is part of the promise).
Most Taproot spends use the key path because it is smaller and cheaper, and it does not indicate anything about whether other spend conditions existed.
P2MR completely removes the key path. Output is committed directly to the script tree Merkle root without any internal keys or key spending options.
All expenditures must disclose the script and provide Merkle proof. This makes P2MR more expensive (at least 103 bytes vs. 66 bytes for Taproot key path supervision).
The balance is intentional. P2MR eliminates the always-on attack surface that public keys create.
Long Exposure vs. short exposure
This distinction is important because BIP-0360 frames quantum risk through two attack models, and their defenses are different.
Long-term exposure attacks target data that is already visible on the chain, such as public keys from unused output that have been exposed for months or years. An attacker using a future quantum computer could decrypt that key offline, without time pressure.
You don’t have to win a mempool competition, but you do have to build a quantum system that can recover the private key from the public key.
However, exposure attacks have become more stringent. An attacker must recover the private key while the transaction remains unconfirmed (usually within minutes or seconds).
BIP-0360 asserts that short-exposure attacks require more advanced quantum systems and post-quantum signature frames as defenses against such windows.
P2MR does not resolve short exposures, but eliminates long exposure surfaces for Taproot-style functionality.
Migration lead time is a real constraint.
If quantum computers capable of breaking elliptic curve cryptography are still years or decades away, why submit this proposal now?
The answer has more to do with Bitcoin’s upgrade rate than its quantum timeline. Even if the risks are uncertain, a safe transition path requires several sequential steps: specification, implementation, review, activation discussions, wallet and exchange support, user training, and gradual migration.
Each step takes months or years. Starting early gives you options. Because waiting for certainty means starting too late.
BIP-0360’s tone is “I’m not afraid, I’m prepared.”
This proposal does not claim that quantum computers will break Bitcoin in 2027 or 2030. The proposal argues that Bitcoin should adopt the low-risk TabScript default output type to avoid extended exposure before post-quantum signatures are ready.
The logic is future-oriented. Taproot and tapscript are modern scripting languages for the advanced Bitcoin protocol.
If you think these tools are important to your Lightning, commitments, or other smart contract use cases, having a version of that functionality without the risk of long-term exposure is a useful component.
The timing also reflects a shift in the way quantum risk is discussed in Bitcoin circles.
BIP-0360 explicitly addresses criticism that Bitcoin developers are not taking quantum threats seriously.
The addition of Isabel Foxen Duke as a co-author indicates someone’s focus on making the proposal understandable for a general audience, not just core developers, and an intention to make quantum preparations readable and accessible.
Recent academic research has also discussed quantum risks in more detail. The paper on benchmarking hybrid post-quantum signatures and elliptic curve cryptanalysis in quantum systems provides quantitative resource estimates rather than vague warnings.
Science is advancing, although the timeline is uncertain.
Opt-in migration, not auto-protection
If P2MR is activated, this is an important “if” considering that activation requires widespread consensus and a successful soft fork deployment, and changes are optional, not mandatory.
The wallet adds support for new address types starting with bc1z, corresponding to SegWit version 2. Users who wish to reduce their risk of long-term exposure can create a P2MR address and send funds to that address.
Existing Taproot outputs can continue to be used according to existing rules. Nothing breaks overnight and no coins are retroactively protected.
Migration is similar to a gradual transition to SegWit or Taproot. Early adopters move first, exchanges and custodians add support over the months, and users migrate as they discover why.
For most retail users, the reasons may be obscure (“quantum safe”) or non-existent. For institutions with long-term holdings, the calculations are different.
Custodians who have held Bitcoin for many years are keenly concerned about their long-term exposure risk. P2MR allows you to continue using TabScript-style programming features that are useful for multi-signature setups, time-locked vaults, and other advanced scripts. At the same time, it eliminates the attack surface of “leaving the public key on chain”.
The trade-offs are real. P2MR spend is larger and more expensive than Taproot key path spend. Any P2MR expenditure reveals that a script tree has been used and sacrifices some of the privacy benefits provided by the Taproot key path.
For users who prioritize low fees and privacy over quantum risk mitigation, the Taproot Key route is a better choice.
What could derail this?
P2MR is a draft, not a completed transaction. Enabling it requires convincing node operators, miners, developers, and economic users that the trade-off is worthwhile.
Some would argue that quantum risk is too far off to justify the cost of coordination.
Others point to loss of privacy due to mandatory script path expenditures or fee overhead due to large witnesses.
Others will question whether P2MR is necessary if post-quantum signatures arrive sooner than expected.
Technical hurdles also remain. Post-quantum signature schemes are still being standardized and their scale and verification costs vary widely.
If a successful plan is not fully integrated with P2MR’s script path framework, the value of the proposal as a foundation for future work is diminished.
What’s at stake?
Minification and P2MR are part of a larger question about how Bitcoin makes decisions under uncertainty.
This proposal does not claim to know when quantum computers will threaten Bitcoin or which post-quantum plan will win. Instead, we argue that we should create options today to reduce the risks of tomorrow.
The point is that even if options are not widely used, having them is worth the cost of the adjustment.
This framing shifts the debate from “Is quantum risk real?” “How many options are worth building?” The answer depends on who you ask.
Selectivity is important for long-term holders and custodians with multi-year time horizons. For retail users seeking lower fees and greater privacy, the trade-off is harder to justify.
The end game is not a single activation date or a complete migration. It’s a slow and uneven change, with different users adopting P2MR for different reasons or not at all.
Bitcoin has no central authority that can order upgrades. Networks evolve through voluntary coordination, and the success of P2MR depends on whether enough participants value the trade-offs. The proposal is now officially documented.
Whether this will become part of Bitcoin’s consensus rules is a matter that will require discussion, testing, and tweaking over the next few years.
