Bitcoin developer contributors have just cleared a documentation hurdle that crypto Twitter was treating like an emergency quantum patch. It wasn’t.
On February 11th, a new output type proposal, Pay-to-Merkle-Root (BIP-0360), was integrated into the official Bitcoin Improvement Proposals repository. No nodes were upgraded. There is no activation timeline.
The BIPs repository itself warns that publication does not imply consensus or adoption, nor does it mean the idea is good. What actually happened is that the draft specification met the criteria for formally documented status in scope.
But the framework surrounding P2MR reveals something more interesting than the merge itself. The Bitcoin developer community is grappling with migration problems that smart cryptography alone cannot solve.
The real story is that the process of upgrading Bitcoin is slow, adjustments are difficult, and preparing for low-probability, high-consequence risks requires years of preparation before anyone accepts the threat is real.
Taproot without key pass door
It is easy to understand if you think of P2MR as Taproot with some parts removed.
Taproot’s output of the day (P2TR) commits to a reconciled public key. When it comes to spending from Taproot output, users have two options. Use keypasses (simple signatures similar to other Bitcoin signatures) or scriptpasses (reveal one script from a Merkle tree of possible scripts and prove it is part of a commitment).
Most of your Taproot spending uses Key Pass. This is because Key Pass is smaller and cheaper and does not reveal anything about other spending conditions that may have existed.
P2MR permanently removes the keypass. The output is committed directly to the Merkle root of the script tree, without any internal keys or key usage options.
All expenditures must be scripted and Markle proof provided. Therefore, P2MR costs more (minimum 103 bytes compared to 66 bytes for Taproot keypath monitoring) and is more expensive.
This tradeoff is intentional. P2MR removes the always-available attack surface created by public keys.
Long exposure and short exposure
BIP-0360 frames quantum risk through two attack models, but this distinction is important because the defenses are different.
Long exposure attacks target data that is already visible on-chain, such as public keys in unused outputs that have been exposed for months or years. An attacker using a future quantum computer will be able to work on cracking that key offline with no time constraints.
We don’t need to win the mempool race, but we do need to build a quantum system that can recover the private key from the public key.
Short exposure attacks are more severe. The attacker must recover the private key while the transaction is unconfirmed, typically within minutes to seconds.
BIP-0360 argues that short exposure attacks require more sophisticated quantum systems and that post-quantum signatures need to be assembled as defenses against that window.
P2MR is not a short exposure solution, but it eliminates long exposure surfaces for Taproot style functionality.
Migration lead time is the real constraint
If a quantum computer capable of breaking elliptic curve cryptography is still years or even decades away, why submit this proposal now?
The answer has more to do with Bitcoin’s upgrade speed than the quantum timeline. Even with uncertain risks, a secure migration path requires multiple sequential phases: specification, implementation, review, activation discussion, wallet and exchange support, user education, and gradual migration.
Each phase can take months or years. Starting early creates options because waiting for certainty means starting too late.
BIP-0360’s tone is “I’m ready, I’m not scared.”
The proposal does not claim that quantum computers will beat Bitcoin in 2027 or 2030. We argue that before post-quantum signatures are ready, Bitcoin should adopt a lower-risk tap script native output type to avoid long-term exposure.
The logic is positive. Taproot and Tapscript are modern scripting languages for advanced Bitcoin protocols.
If you think these tools are critical to Lightning, Covenant, or other smart contract use cases, having a version of that functionality without the long exposure risk can be a useful building block.
The timing also reflects a shift in the way quantum risk is discussed in the Bitcoin world.
BIP-0360 explicitly addresses criticism that Bitcoin developers are not taking quantum threats seriously.
The proposal, which includes Isabel Foxen Duke as a co-author, is focused on making it understandable not only for core developers but also for a general audience, demonstrating an intention to make quantum enablement readable and accessible.
Recent academic research has also made the discussion of quantum risk more concrete. A paper on benchmarking hybrid post-quantum signatures and elliptic curve cryptography for quantum systems provides quantitative resource estimates rather than vague warnings.
Science is progressing, even if the timeline is uncertain.
Opt-in migration instead of automatic protection
If P2MR is activated, that is an important “if” given that activation requires broad consensus and successful implementation of a soft fork, but changes are opt-in rather than mandatory.
The wallet adds support for new address types starting with bc1z, compatible with SegWit version 2. Users who want to reduce the risk of long-term exposure can generate P2MR addresses and transfer funds by sending to those addresses.
The output of existing tap routes is still available based on existing rules. Nothing breaks down overnight, and your coins are not retroactively protected.
This migration is similar to a gradual migration to SegWit or Taproot. Early adopters will migrate first, exchanges and admins will spend months adding support, and users will find reasons to migrate.
For most retail users, the reason may be vague (“quantum safety”) or non-existent. For institutions with long-term assets, the calculation is different.
Custodians who have held Bitcoin for many years are very concerned about the risk of long-term exposure. P2MR allows continued use of tapscript-style programmability, useful for multisig configurations, time-locked vaults, and other advanced scripts. At the same time, it eliminates the attack surface of “leaving the public key on the chain.”
This trade-off is real. P2MR spending is larger and more expensive than Taproot keypass spending. Every time P2MR is spent, it becomes obvious that the script tree was used, sacrificing some of the privacy benefits provided by the Taproot keypass.
For users who prioritize low fees and privacy over quantum risk mitigation, Taproot Key Pass remains a better option.
what makes this crazy
P2MR is a draft, not a completed deal. Activation requires convincing node operators, miners, developers, and economic users that the trade-off is worth it.
Some may argue that the quantum risks are too remote to justify the adjustment costs.
Some point to the loss of privacy due to forced script pass expenditures and the burden of fees from large-scale witnesses.
Furthermore, if post-quantum signatures arrive sooner than expected, one may question whether P2MR is necessary.
Technical obstacles still remain. Post-quantum signature schemes are still in the process of standardization, and their size and verification costs vary widely.
If the winning scheme does not integrate cleanly with P2MR’s script path framework, the value of the proposal as a basis for future work will be diminished.
what is the problem
Zooming out, P2MR is part of a larger question about how Bitcoin makes decisions under uncertainty.
The proposal argues that we do not know when quantum computers will threaten Bitcoin or which post-quantum scheme will prevail. Instead, we advocate creating options today that reduce risk tomorrow.
Even if the option is not widely used, having it is worth the adjustment cost.
This framework shifts the discussion from “Is quantum risk real?” “How many options are worth including?” The answer depends on who you ask.
Options can be valuable for long-term holders and custodians with multi-year horizons. For retail users seeking lower rates and privacy, the trade-off is even harder to justify.
The final stage is not a single activation date or universal migration. This is a slow and uneven transition, with different users adopting P2MR for different reasons, or not adopting it at all.
Bitcoin has no central authority mandating upgrades. Networks evolve through voluntary coordination, and the success of P2MR depends on whether enough participants feel the trade-off is worth it. This proposal is now formally documented.
Whether it becomes part of Bitcoin’s consensus rules is a matter of discussion, testing, and tweaking over the next few years.
(Tag translation) Bitcoin
