P2TRv2 or P2MR: should Bitcoin's first post-quantum output leave the box open?

Updated September 2026

This site is built on one idea: a public key hidden behind a hash is a closed box, and a key on the chain is an open one. The question now being argued among Bitcoin developers is whether the next output type should close the box by design or leave it open and promise to lock it later. The discussion, "PQC output type discussion" on Delving Bitcoin, was opened by Pieter Wuille on July 27, 2026. Its latest post, on September 21, sharpened the disagreement rather than settling it. Here is what each side proposes and what it would mean for your coins.

What are the options on the table?

Wuille's opening post laid out four candidates. Two of them carry the debate.

• P2MR. The output type in BIP-360, still a draft at version 0.12.1: SegWit version 2, addresses starting with bc1z, and an output that commits only to the Merkle root of a tree of scripts. There is no key path, so no elliptic curve key sits on the chain before a spend. Our BIP-360 explainer covers the details.
• P2TRv2. Taproot again, with the same rules as today's bc1p outputs plus post-quantum signature paths. Every output shows an elliptic curve key, and the expectation is that a later rule change would switch off the elliptic curve paths inside this output type. Wuille marks its origin as unclear. It has no BIP.
• P2TRH. Anthony Towns's variant: store a hash of the Taproot key instead of the key, and recover the key from the signature at spend time. It hides the key but needs a changed signature scheme and gives up batch validation.
• P2QR. P2MR with elliptic curve signatures disabled from day one. Unconditionally resistant to a quantum computer, and more expensive to use from the start.

In box terms, P2MR and P2TRH are closed boxes, P2QR is a box with no elliptic curve lock at all, and P2TRv2 is an open box, the same as Taproot today, with a promise attached.

How would P2TRv2 lock an open box later?

Through two mechanisms, usable with either new output type, that Wuille described on the bitcoin-dev mailing list in June, summarized by Bitcoin Optech on July 3.

• The tripwire. Credited to Tadge Dryja. The soft fork fixes a public key whose private key nobody knows. If a transaction ever spends with it, that is proof someone can break elliptic curve keys, and the elliptic curve paths in the new output type stop working: from the next block in Wuille's first sketch, or after a delay of days that Wuille suggested later in the thread. Sjors Provoost built a demonstration of a variant, using a compact proof published in a block's coinbase, in a personal fork of Bitcoin Core in June, marked as not meant for merging.
• Miner lockdown. Suggested by Provoost. The switch-off ships with the new output type but with a very long activation window, so a majority of hashrate can trigger it without waiting for a separate soft fork. Wuille was more hesitant about this one, because it hands miners more power.

Two limits matter. The switch-off would apply only inside the new output type, which people would choose to use, not to existing coins. And a tripwire only fires if someone publishes proof of breaking the special key, which an attacker who keeps quiet never has to do. Antoine Poinsot argued on September 16 that without miner lockdown a tripwire does not force the switch-off to happen and works mainly by setting expectations, and that the harder problem is making sure the switch-off never happens too early.

What is Wuille's case for P2TRv2?

Wuille, one of the authors of Taproot's BIPs, proposes two stages. First, an emergency step aimed at as many users as possible: P2TRv2 with a tripwire, perhaps miner lockdown later, and a hash-based post-quantum signature. Later, a full migration: a P2MR-based type with a new way of counting witness data, so its elliptic curve spends cost about what Taproot spends cost today, with cheaper post-quantum signatures once the elliptic curve paths are switched off.

The argument is about behavior, not cryptography. Wuille points out that not showing the same address twice has been best practice since 2009, yet address reuse is still entrenched, and recalled trying to move payments beyond plain addresses about 15 years ago, work that fed into the BIP70 payment protocol, which was later abandoned. Changing habits, Wuille's September 21 post argues, takes a better workflow or making the old one hard or impossible, and relying on education is naive.

Keys leak in other ordinary ways too. Registering a hardware wallet with a coordinator, setting up a multisig or sharing an xpub with a watch-only app all hand out the material that opens the box. Wuille's opening post noted that P2MR keeps its advantage only if no actual elliptic curve keys are shared, which rules out xpub sharing, MuSig, adapter signatures and FROST.

In the September 21 post, Wuille argued that the difference only matters for users able to decide for themselves when to stop using elliptic curve paths, called it "largely psychological", and allowed that it might still matter if it affects adoption. P2TRv2 would keep Taproot's fees and most of today's workflows, which Wuille sees as removing friction for everyone, including today's Taproot users. conduition argued on September 8 that any post-quantum type, P2TRv2 included, needs new standards for deriving post-quantum keys, so even P2TRv2 needs more than a version bump. On September 18 conduition granted P2TRv2's advantages, drop-in compatibility and a small fee saving, but called them minor next to the risk of every P2TRv2 coin being exposed. Wuille's posts also propose a way to keep today's habits working: one static post-quantum key per wallet, written into the wallet's descriptor next to the xpub.

What is the case for P2MR first?

The developer known as conduition argues the other way, as in earlier threads. The main points, from posts on September 8, 14 and 18:

• P2TRv2 leaks at least as much as P2MR. Whatever keys a P2MR user exposes by reusing or sharing, a P2TRv2 user has exposed already, because every P2TRv2 key is on the chain from the first deposit.
• A P2TRv2 with no post-quantum path would be dangerous. If a tripwire fired, coins in it would have no way left to move, which conduition sees as a risk of confiscation. Nobody proposes that version: Wuille's P2TRv2 includes a hash-based post-quantum path, and Wuille has also warned against people using P2TRv2 without one.
• The reuse problem can be worked on. Wallets could stop handing out xpubs, warn about coins on exposed addresses, use animated QR codes, keep MuSig and FROST for short-term setups and put hashed keys in scripts for long-term multisig. conduition considers post-quantum security for hardware wallets under P2MR entirely achievable.
• Nobody knows the fraction. conduition says no one can predict how many coins P2MR would really keep closed, only that it would protect some share from long exposure attacks, and expects that share to be high with education and good wallet design.

conduition still holds that P2MR alone deserves to be called post-quantum. Wuille's September 21 reply granted that P2MR is clearly stronger on this point but asked conduition to stop describing it that way, because the difference only counts if users can judge when a quantum computer exists, avoid every workflow that exposes a key, never reuse an address and Bitcoin itself survives. Another participant, ArmchairCryptologist, added a precise point on September 17: receiving twice to a hashed address does not open its box. Only a spend does, and it exposes whatever is left at that address or sent there later. Until elliptic curve spending is switched off, ArmchairCryptologist went on, P2TR and P2TRv2 are a step backwards from hashed types. Wuille called the point fair but said holders that careful are not who P2TRv2 is for, and can move to a later P2MR type.

How widespread is the habit both sides are arguing about?

Large. Project Eleven, which has published a roughly weekly count of exposed coins, put 8,177,337 BTC in its latest snapshot, dated September 14, 2026. About 6.19 million of those sit in hashed addresses that have spent before and still hold coins, the kind of reuse this debate is about. Taproot outputs, open from the moment they are funded, held about 273,000 BTC. Counts differ by method and date, and this site's page on how many coins sit in open boxes compares them.

That number cuts both ways. It supports Wuille's view that reuse is entrenched. It also shows how many coins a closed-by-design type would not protect unless habits change, which is conduition's reason for wanting wallets to change them.

What does each option cost to spend?

Wuille's table, built on earlier posts by Wuille and Anthony Towns, gives estimates for a spend that uses one elliptic curve signature: about 64 bytes of witness for P2TRv2, 128 for P2MR and 96 for P2MR with public key recovery. Spending through the post-quantum path instead costs about 32 extra bytes in each type, the price of also offering an elliptic curve path. Worked and measured numbers are close. BIP-360 works out a depth-one P2MR spend at 135 witness bytes, against 66 for a Taproot key path spend. On regtest, the developer JP measured a one-input transaction spending a two-leaf P2MR output at 513 weight units, lighter than the 545 of the matching Taproot script path transaction.

How much the difference matters is part of the argument. Wuille holds that a higher cost can put users off more than savings attract them, and that fee savings do little to drive adoption. conduition calls the gap small. A side debate about bundling cross-input signature aggregation, which would make some spends cheaper, is still open: Fabian Jahr, whose proposal it is, and conduition favor it, while Wuille, Poinsot, Adam Gibson and Antoine Riard are skeptical of tying it to the post-quantum question.

Where do they agree?

More than the tone suggests. conduition wrote on September 18 that everyone seems to agree on a rough shape: a simple risk-reduction step first, then a thorough migration. Wuille and Provoost agreed on September 11 that the first deployment should include at least one trigger, and both camps put a tripwire and a hash-based post-quantum path in their first stage. Poinsot and Riard favor separate deployments for the quick step and the full one.

The disagreement is about what goes into step one: P2TRv2, backed by Wuille, Poinsot and Riard, or P2MR, backed by conduition, who has also floated P2TRv2 bundled with cross-input signature aggregation as a compromise. Wuille's latest post names what is perhaps the biggest difference in vision: whether wallets and users can be relied on to change their workflows enough for P2MR's extra protection to show up. On how many coins would stay unexposed, Wuille suggests the two sides may have to agree to disagree.

What does not exist yet matters as much. There is no BIP, and no pull request to the BIPs repository, for P2TRv2, the tripwire or miner lockdown; Provoost's tripwire code is a demo in a personal fork. BIP-360 is a draft. Bitcoin Optech covered the thread in its August 7 newsletter and again on September 4, and nobody in it has proposed a date.

What does this mean for your coins today?

• Nothing changes yet. No quantum computer can break secp256k1, and neither design is live. A never-spent 1, 3 or bc1q address is still a closed box. A Taproot bc1p address is still an open one.
• Your habits matter under either design. Under P2MR, spending from an address and then reusing it, or sharing keys, would open the box. Under P2TRv2, the box is open anyway and the switch-off does the protecting. Either way, not reusing addresses and sharing xpubs only where you need to keeps your options widest.
• The coins that never move are the hard part. Wuille called the choice between letting those coins be stolen or freezing them more urgent than quantum computers themselves. That argument, over Satoshi's coins and every other dormant open box, sits beside this one.
• There is already a no-fork fallback. Coins moved into a QSB lock before a capable machine exists can later be spent in a way a quantum computer cannot rewrite, under today's rules and at a steep computing cost.