Aligning privacy incentives in P2MR

[conduition]

Hi list. I'm following up on an idea I sketched in this thread debating P2MR vs P2TRv2. 

The premise is this: What if we modified this line of BIP360:

The last stack element is called the control block c, and must have length 1 + 32 * m, for a value of m that is an integer between 0 and 128, inclusive. Fail if it does not have such a length.

To this:

The last stack element is called the control block c, and must have length 1 + 32 * m, for a value of m that is an integer between 1 and 128, inclusive. Fail if it does not have such a length.

The key change is that the control block must now include at least one merkle authentication path. This effectively bans depth-zero script trees in P2MR, and requires every P2MR address to always pay the cost of having at least two spending conditions.

This seems like a reduction in P2MR's features and efficiency. Why would we want to ban depth-zero script trees? Well these seem to be the source of a perverse incentive, as pointed out by Matt Corallo and Antoine Poinsot in prior threads. Bitcoin script users are economically and practically incentivized by P2MR to use depth-zero script trees because their witnesses are smaller than if the same script were used in a taproot script spend.

Furthermore, depending on the exact scripts and the developers' resources, devs using P2MR for a multi-party scripting protocol may not be sufficiently incentivized to add a cooperative spending path, even if their protocol might allow it. Doing so would require a depth-1 tree, which increases the witness size of the non-cooperative script spend path by 32 bytes. For some short scripts, e.g <height> CLTV <pubkey> CHECKSIG​, the devs may actually have incentive not to add a cooperative spending path, because the cooperative path would actually be less-efficient than just using the non-cooperative path as the single leaf of a depth-zero tree. This leads to easy fingerprinting of scripting protocols, less privacy for everyone else, and undoes a key design goal of P2TR.

In Matt's words:

The value of taproot is that its design natively adds [a cooperative spending path] *for free* to every contracting protocol, and not only adds it for free but *forces* every contracting protocol to carry at least some of the cost if they decline to do this. This results in a massive net privacy win across the entire Bitcoin ecosystem...

a goal of taproot is *privacy* while offering efficiency for the common (all-sign) case. That is generally true across contracting protocols and makes things net-cheaper with a taproot-style system where you hit the common case often. This is another reason why P2MR is quite a loss

By eliminating depth-zero script trees, we'd force all P2MR users to pay for the cost of having at least two spending conditions. We'd eliminate the incentive for script devs to use P2MR over P2TR because both are equally efficient, and incentivize P2MR users to add a cooperative spending path using BIP340, since those users are already paying for the cost of having a depth-1 tree anyway.

This change to BIP360 wouldn't affect the recommended standard use-cases for single-signer and multisig P2MR: hybrid addresses with one Schnorr leaf and one PQ leaf. If anything, this change would encourage the proper use of PQ fallback scripts, because the incentive logic can be applied to someone who tries to use P2MR with only a single EC Schnorr leaf: This user must pay for the cost of a second leaf script anyway, so why not follow best-practices and add a PQ leaf?

AFAICT this change only affects use cases which would otherwise degrade the fungibility of the UTXO set according to BIP360 critics, and encourages those use-cases to adopt a cooperative spending path which (assuming all other factors equal) will be indistinguishable from a regular single-signer P2MR wallet with a PQ fallback leaf.

I've already chatted about this off-list with some BIP360 proponents and they seem receptive, but I'm really curious about the opinions of those who are leaning towards P2TRv2. Would this change to BIP360 address your concerns surrounding P2MR's privacy incentives? If not, why?

regards,

conduition

[Antoine Poinsot]

Hi conduition,

I think this would address the perverse incentive concern, but still fail in not disincentivizing mass migration.

It's important to consider that in any scenario where Bitcoin as we know it survives a CRQC, the vast majority of users would have had to migrate to an output type that includes an escape hatch long before we could have been reasonably certain that a CRQC would materialize. Therefore we should not assume that the vast majority of users strongly desire to migrate to an escape-hatch output type. (In fact, i think it would actually be reasonable to assume none have a strong desire to do so. This is because everyone has an incentive for everybody to migrate, but there is little incentive for each individual to migrate if nobody else does.)

Therefore any additional barrier to encourage users to opt into an escape-hatch output type is working against CRQC risk mitigation. And i think the additional costs of using P2MR compared to P2TRv2 is one of them. Most likely all "long-tail" users, who would be the least likely to seek migration, use single-key spending policies. In fact, most Bitcoin users do: in the past 90 days of blocks, 93.6% of all transaction inputs are for single-key spending policies. For a typical 2-input 2-output transaction for a "single-key wallet", P2MR is about 15% more expensive to use than P2TRv2 [^0].

I understand that P2MR does not introduce this additional cost just for kicks, but i think "long-range" protection is a red-herring and not worth hindering individual migration to the escape-hatch output type, which is critical to the systemic migration of Bitcoin away from relying on EC cryptography.

So your proposal does address one of my concerns with a P2MR + PQ opcode strategy. However, i still believe P2TRv2 to be a superior strategy for the reason outlined above.

Best,

Antoine

[^0]: Using 57.5*2 + 43*2 = 201 vbytes as the base size. P2MR adds an additional 32 witness bytes in the control block for the PQ spend path, and an additional 35 witness bytes for the EC leaf script reveal. That's 33.5 more vbytes per input, which is 116.66% the size of the same transaction with P2TRv2.

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Q8YTY1ArMzia7tRvcZ5v769WPxCMxAl_0rUy-byOBjBcTd4HXj7IB7Yt4gxLbKqk7EXFWy-PuGB6QtI28qRjE5Vob-l44UmBH6L8aXInoSk%3D%40proton.me.

[conduition]

Hi Antoine, thanks for the feedback. Glad to hear you're receptive!

It's important to consider that in any scenario where Bitcoin as we know it survives a CRQC, the vast majority of users would have had to migrate to an output type that includes an escape hatch long before we could have been reasonably certain that a CRQC would materialize. Therefore we should not assume that the vast majority of users strongly desire to migrate to an escape-hatch output type. (In fact, i think it would actually be reasonable to assume none have a strong desire to do so. This is because everyone has an incentive for everybody to migrate, but there is little incentive for each individual to migrate if nobody else does.)

Therefore any additional barrier to encourage users to opt into an escape-hatch output type is working against CRQC risk mitigation.

All else being equal, whether we use P2MR or P2TRv2 I believe we will end up with roughly the same (small) fraction of the UTXO set migrated by Q-day. I believe this because address format adoption is always slow even with good incentives. Even after 7 years and plenty of incentives to migrate, P2TR still secures only a small fraction of the UTXO-set compared to P2(W)PKH, and a tiny fraction (0.75%) of the supply. See this 2025 report from mempool.space and this 2025 report from Galaxy Digital. Incentivizing adoption doesn't always lead to adoption, so why expect it to do so with P2TRv2? It doesn't offer any incentive over P2TR beyond a shallow promise of maybe-some-day-quantum-security.

Here's my timeline prediction, with the above precedent in mind. We deploy a PQ output type, some minority of UTXOs migrate to it. When the first confirmed ECDLP break is proven (e.g. if someone breaks a NUMS point) or suspected (someone stole Satoshi's coins), then we will deploy a rescue protocol which we hopefully prepared in advance to protect the majority procrastinator UTXOs. Maybe we disable EC spending at the same time (a valid option for either P2MR or P2TRv2). Then there will be a brief fork-war (hard or soft) revolving around the question of how to handle Satoshi's coins. After that IDK what happens, but I expect Bitcoin will survive if we prepare adequately today by deploying a quantum-safe address format and PQ signature scheme, and develop rescue protocols for later activation to move laggards over to PQ wallets.

Whether we pick P2MR or P2TRv2 today, neither choice will affect the early stages of this plot-line very much, so we might as well optimize for the long-term future, and P2MR wins out there.

any additional barrier to encourage users to opt into an escape-hatch output type is working against CRQC risk mitigation. And i think the additional costs of using P2MR compared to P2TRv2 is one of them.

I have good news for you: there is an optimization to BIP360 which would make single-signer Schnorr spending significantly (32 bytes) cheaper. It's not my idea so I don't want to jump the gun in explaining the details, but expect another mailing list post soon with more info.

regards,

conduition

[Pieter Wuille]

Hi Conduition,

Some comments inline below.

On Friday, June 5th, 2026 at 6:59 PM, 'conduition' via Bitcoin Development Mailing List <bitco...@googlegroups.com> wrote:

Hi Antoine, thanks for the feedback. Glad to hear you're receptive!

It's important to consider that in any scenario where Bitcoin as we know it survives a CRQC, the vast majority of users would have had to migrate to an output type that includes an escape hatch long before we could have been reasonably certain that a CRQC would materialize. Therefore we should not assume that the vast majority of users strongly desire to migrate to an escape-hatch output type. (In fact, i think it would actually be reasonable to assume none have a strong desire to do so. This is because everyone has an incentive for everybody to migrate, but there is little incentive for each individual to migrate if nobody else does.)

Therefore any additional barrier to encourage users to opt into an escape-hatch output type is working against CRQC risk mitigation.

All else being equal, whether we use P2MR or P2TRv2 I believe we will end up with roughly the same (small) fraction of the UTXO set migrated by Q-day. I believe this because address format adoption is always slow even with good incentives. Even after 7 years and plenty of incentives to migrate, P2TR still secures only a small fraction of the UTXO-set compared to P2(W)PKH, and a tiny fraction (0.75%) of the supply. See this 2025 report from mempool.space and this 2025 report from Galaxy Digital. Incentivizing adoption doesn't always lead to adoption, so why expect it to do so with P2TRv2? It doesn't offer any incentive over P2TR beyond a shallow promise of maybe-some-day-quantum-security.

I don't think that's necessarily the right conclusion. P2TR adoption is low, partially because wallets and especially commercial service providers generally don't ever upgrade their technology stacks unless there is a compelling reason; the ecosystem primarily updates through companies going out of business and being replaced by new ones, which are more likely to be built using modern technology. We obviously cannot ask for faster movement through business failure here, but as far as compelling reasons go, I think the quantum resistance debate is quite different from P2TR adoption. As Q-fear grows, I suspect there will be increasingly loud and hard-to-ignore voices (and possibly regulation...) to adopt post quantum cryptography technology stacks. At that point, wallets may start to offer users an "Upgrade to quantum-resistant addresses?" migration button. In the case of P2MR that will need to come with a "Warning: transactions will cost 15% more going forward" notice. In the case of P2TRv2, depending on what what used before it may have 0 impact on costs, or even be a discount going forward. If on-chain fees remain as low as they are now, this may not matter, but otherwise, I think the number may very well discourage a substantial amount of users who aren't convinced about CRQC threats. And I think those users do matter, unfortunately.

Here's my timeline prediction, with the above precedent in mind. We deploy a PQ output type, some minority of UTXOs migrate to it. When the first confirmed ECDLP break is proven (e.g. if someone breaks a NUMS point) or suspected (someone stole Satoshi's coins), then we will deploy a rescue protocol which we hopefully prepared in advance to protect the majority procrastinator UTXOs. Maybe we disable EC spending at the same time (a valid option for either P2MR or P2TRv2). Then there will be a brief fork-war (hard or soft) revolving around the question of how to handle Satoshi's coins. After that IDK what happens, but I expect Bitcoin will survive if we prepare adequately today by deploying a quantum-safe address format and PQ signature scheme, and develop rescue protocols for later activation to move laggards over to PQ wallets.

No offense, but this sounds like a fairly depressing scenario to me. If an ECDLP break happens before even a large majority of the "active" economy adopts Q-safe outputs, I don't think there is much of an interesting future for Bitcoin. Leaving many users' coins vulnerable to theft will undermine short-term trust in the currency, possibly fatally so. The alternative, burning significant amounts of users' coins will be seen as confiscation that undermines the long-term stability value proposition bitcoin has, as it would be indistinguishable from a PQC altcoin that imports some fairly arbitrary subset of Bitcoin's UTXO set (see also https://antoinep.com/posts/quantum_risk_mitigation/, where Antoine makes that point in more detail).

I cannot confidently state that your scenario is unlikely of course, but I think there is little we can do today that affects the outcome in this case. People can think about emergency recovery scenarios to scavenge what's left to save (BIP32 ZKPs and all that), and the result may well survive, but I don't think it'll be very interesting, and not something we as protocol designers should optimize for at this stage.

The interesting scenarios to me are ones where either a CRQC doesn't happen, or where we get a large majority of users to adopt Q-safe outputs before that happens. Maximizing the probability that that will happen should be our priority.

Whether we pick P2MR or P2TRv2 today, neither choice will affect the early stages of this plot-line very much, so we might as well optimize for the long-term future, and P2MR wins out there.

The ideal long-term future is one where we get feature-rich cryptographic schemes that can replace most of the properties Bitcoin relies on today (homomorphic derivation, efficient multisigs, ...) with low costs (through discounts, smaller signatures/keys, efficient verification, ...). At that point, they can be introduced in PQC-only outputs even (say, P2MR without any EC opcodes ever), everyone can adopt them over time, and then when a CRQC appears or not won't really matter. That technology does not exist today, I think, so the best we can aim for today is something where most users can migrate to with minimal downsides before Q-day, even if it comes with some downsides afterwards, which will inevitably be chaotic but maybe not an existential threat. I don't think it matters much that P2TR(v2) is slightly less efficient than P2MR in this hopefully-avoidable chaos; we'll have much bigger fish to fry.

I believe P2MR is effectively optimizing for the time after/if a CRQC appears (possibly only temporarily so if another migration to a more fully-features PQC scheme is needed anyway then) while P2TRv2 is optimizing for the time before a CRQC happens and minimizing barriers for adopting Q-safe coins. All of this is under the assumption that P2MR comes with a reasonable expectation of a narrow P2MR-only EC opcode disabling softfork when CRQCs happen (like P2TRv2); without it, I believe it is much worse, as P2MR would be entirely inadvisable to adopt by anyone whose workflow relies on sharing public keys with others (hardware wallets with descriptor-based watchonly software, wallets with indexing servers, multisig, Lightning, escrows, fee bumping, ...).

So, I prefer P2TRv2 here, though under the assumption that the narrow EC opcode disabling softfork can be relied upon. I am not confident that that is possible, though I have more thoughts on the matter. That's for another post, though.

any additional barrier to encourage users to opt into an escape-hatch output type is working against CRQC risk mitigation. And i think the additional costs of using P2MR compared to P2TRv2 is one of them.

I have good news for you: there is an optimization to BIP360 which would make single-signer Schnorr spending significantly (32 bytes) cheaper. It's not my idea so I don't want to jump the gun in explaining the details, but expect another mailing list post soon with more info.

It's possible to allow a Merkle tree whose leaves are either EC keys or scripts, and then allow spending from the key-leaves by revealing the path and a signature, but recover the expected public key from the signature. That needs a variation of BIP340 that doesn't commit to the public keys (which may break some of the proofs of higher-level schemes, but as long as there is no ANYPREVOUT like functionality, the message implicitly commits to the output so that may be fine). But even with that, efficiency is 32 bytes worse than P2TR, because in a Q-safe setting with at least one additional PQC branch, you have at least 32 bytes of Merkle path. Is this what you have in mind?

-- 
Pieter

[Hayashi]

Dear Conduition, Antonie, and list,

A reasonable intersection of both opinions could be further witness discount of EC Schnorr of P2MR (Segwit v2). 
Further 2x witness discount (total 8x witness discount) makes P2MR EC-spend transaction cost almost at par with P2TRv2 key-spend path.

Anyway, we will have to discuss discount policy when we try to add PQ signature to Bitcoin. I think we could discount witness for those who use EC Schnorr leaf if larger transaction cost heavily discourages the migration.

Best Regards,
Hayashi

[conduition]

Hey Pieter, nice to hear from you too on this. 

Do you have any take on the OP idea about P2MR depth restrictions?

as far as compelling reasons go, I think the quantum resistance debate is quite different from P2TR adoption. As Q-fear grows, I suspect there will be increasingly loud and hard-to-ignore voices (and possibly regulation...) to adopt post quantum cryptography technology stacks.

I hope so too! It's totally possible that a significant majority of UTXOs migrate in time - say if you're right and there is a very public concerted push towards PQ, or if Q-day turns out to be 50+ years from now. But it's impossible to predict this. For now I hope for the best, but I also want to plan for the worst.

If PQ fear is indeed such a strong motivating factor as you hypothesize, wouldn't this be an argument against P2TRv2? P2TRv2 isn't quantum-resistant by default but P2MR is. Personally, if I thought a CRQC is imminent, I would rather sell my coins or stow them in a P2WSH address than migrate to an address format which requires a follow-up fork to be secure. 

To borrow a phrase, P2TRv2 bears a systemic risk (solving the fork timing problem), whereas P2MR has only local risk (address reuse, which btw would also be solved if we could solve fork-timing). Antoine drew this comparison on his post too but we apparently disagree on which is preferable.

Users and devs can control local risk with very simple software tweaks (to avoid address reuse) but they can't do anything about systemic risks. This is why I prefer P2MR. If the fork-timing problem can be solved conclusively then maybe P2TRv2 would be viable, but as you've alluded to, we have yet to hear any passable solution that doesn't require a cooperative CRQC.

No offense, but this sounds like a fairly depressing scenario to me. If an ECDLP break happens before even a large majority of the "active" economy adopts Q-safe outputs, I don't think there is much of an interesting future for Bitcoin. Leaving many users' coins vulnerable to theft will undermine short-term trust in the currency, possibly fatally so. The alternative, burning significant amounts of users' coins will be seen as confiscation that undermines the long-term stability value proposition bitcoin has, as it would be indistinguishable from a PQC altcoin that imports some fairly arbitrary subset of Bitcoin's UTXO set (see also https://antoinep.com/posts/quantum_risk_mitigation/, where Antoine makes that point in more detail).

Agreed, it would suck, but would likely be viable.

I lack data, but I suspect that by Q-day most coins will have some knowledge-asymmetry with a CRQC (hash preimages, BIP32 parent keys, hidden P2TR script paths, etc) and so can be rescued with simple commit/reveal protocols - no heavy ZK machinery or hard-forks needed.

With that in mind, then it doesn't really matter how many recoverable coins migrate before Q-day, does it? If you can assume P2TRv2's PQ-security promise will be deployed on-time, then you can also assume any BIP32 wallet in-use today can be rescued. What we really must care about is migrating the unrecoverable fraction of coins (e.g. JBOK wallets with exposed pubkeys). These should already be rare and will only become rarer as more time passes.

So in order to argue your point that P2TRv2 makes confiscation/theft less likely, you'd need to show that P2TRv2 will result in a meaningfully higher number of unrecoverable coins migrating. And I don't see why that would be the case. Holders of ancient JBOK coins with exposed keys are probably either dead, or have lost their keys. If a holder does still have the keys, then why would they move to P2TRv2 but not P2MR?

On a more positive note, if we can someday say "Look, quantum computers appeared and screwed some people over, but most people can recover their coins as long as they fulfill any one of these common criteria," then that seems like Bitcoin's unique value and confiscation resistance is surprisingly intact to me. Certainly better than certain other altcoin migrations I've seen in the past, but I guess this is a subjective question, and everyone will have their own opinion.

It's possible to allow a Merkle tree whose leaves are either EC keys or scripts, and then allow spending from the key-leaves by revealing the path and a signature, but recover the expected public key from the signature. That needs a variation of BIP340 that doesn't commit to the public keys (which may break some of the proofs of higher-level schemes, but as long as there is no ANYPREVOUT like functionality, the message implicitly commits to the output so that may be fine). But even with that, efficiency is 32 bytes worse than P2TR, because in a Q-safe setting with at least one additional PQC branch, you have at least 32 bytes of Merkle path. Is this what you have in mind?

Sorry to string you along but I'm gonna hold off here as I don't want to take credit for the idea by jumping the gun and explaining it myself. I'll leave it open for the actual author to chime in on this thread if/when he's ready :)

A reasonable intersection of both opinions could be further witness discount of EC Schnorr of P2MR (Segwit v2).
Further 2x witness discount (total 8x witness discount) makes P2MR EC-spend transaction cost almost at par with P2TRv2 key-spend path.

I wouldn't rule out a discount in a future upgrade but for now i'm hesitant to bundle PQ addresses/signatures with anything that might disrupt the existing fee market, especially given the frustratingly controversial topic of inscriptions/spam. I can already picture the Knotsies decrying a witness-discounted PQ soft fork as "spam-support hidden behind quantum FUD". Never mind that we're already going to have to bump the stack element size limit...

regards,

conduition

[Boris Nagaev]

Hi Antoine, Conduition, Pieter, and list,

I want to share my proposal for EC public key recovery in P2MR (BIP-360). It saves 35 bytes in the witness by removing the witness element that contains the script.
https://delvingbitcoin.org/t/public-key-recovery-for-ec-leaves-in-p2mr-bip-360/2603 

Best,
Boris

[Pieter Wuille]

Hi conduition,

See more comments inline below.

On Saturday, June 6th, 2026 at 3:33 PM, conduition <condu...@proton.me> wrote:

Hey Pieter, nice to hear from you too on this. 

Do you have any take on the OP idea about P2MR depth restrictions?

I think it improves one aspect of the incentive differences (relative costs within the output type for common vs. uncommon). The key recovery idea improves another (relative costs w.r.t. P2TR in the common case). Even with both, the result is still worse than P2TR today in both aspects (key-based spend is still more expensive compared to P2TR, and the incentive for key-based over script-based spend is weaker within P2MR).

I want to take a step back however and separate the discussion into two somewhat orthogonal dimensions along which P2MR and P2TRv2 differ, because discussing the details sometimes conflates them:

• The exact commitment structure (Merkle root, variations with branch length / key recovery, Taproot structure, ...).
• The expectation of when an EC-disabling consensus change happens:

• "Never", or as part of a wide (not-output-specific) EC disabling/freeze (P2MR)
• "Later", through a later softfork that specifically disables EC narrowly in that output type (P2TRv2)
• "Now", Immediately in that output type ("P2QR", i.e., P2MR with all EC opcodes disabled from the start).

Tweaking the commitment structure modifies the incentives of one over the other under some conditions, but I think the question of when/how the EC-disabling happens is the more fundamental one, and it is largely independent of the commitment structure. I'll go into more detail below, but my reasoning is primarily that the "Never" and/or "Immediately" options are just insufficient with current technology for any worthwhile migration attempt (independent of which commitment structure is used), and thus that we simply need the "Later" option. Once you accept that, there is a secondary line of reasoning about which specific structure(s) are , and that is where taproot-based constructions come out ahead by having better incentives in the short- to medium term (the numbers above mean essentially less/zero economical friction).

I also want to point out there that Merkle-Never and Merkle-Later are two very fundamentally different things, and we can't just decide at a later point in time whether a narrow fork should still be applied. If the expectation is no EC-disabling in it, then disabling is confiscatory.

There is one technical difference where the specific commitment structure matters: P2MR ("Merkle-Never") can be used in a Q-safe way and a hypothetical "Taproot-Never" cannot (which includes P2TRv2, if you don't believe in being able to rely on the future narrow disabling), which seems to be the primary reason people like it. However, I think this is extremely restrictive, and simply not an option for most users, because it means:

• Not using wallet indexing services that transmit public keys/xpubs.
• Not using hardware wallets with watchonly software wallets that rely on xpubs/descriptors.
• Not using multisig (or MuSig/threshold schemes/...). Even a PKH-based multisig (as you suggested elsewhere) is icky due to parties needing to share signatures with each with each other, of coins that aren't necessarily going to be spent.
• Not using Lightning.
• Not using silent payments.
• Not using escrow services (like Blockstream's or BitGo's 2-of-3 wallet services).
• Not spending fork coins / airdrops.
• Never reusing addresses.

Of course, with evolving technology and other developments, some of these restrictions may weaken. Alternatives for some of these may be developed, but I don't think think fundamentally everything can be addressed. By their nature, public keys are designed to be public, and I don't believe we can realistically migrate the whole ecosystem (even in the long term) off that premise. The real solution is feature-rich efficient PQC signature schemes of course, but those do not exist today. If we want to start a migration in the near-term, with today's technology, it needs to be compatible with today's ecosystem.

If PQ fear is indeed such a strong motivating factor as you hypothesize, wouldn't this be an argument against P2TRv2? P2TRv2 isn't quantum-resistant by default but P2MR is. Personally, if I thought a CRQC is imminent, I would rather sell my coins or stow them in a P2WSH address than migrate to an address format which requires a follow-up fork to be secure. 

To borrow a phrase, P2TRv2 bears a systemic risk (solving the fork timing problem), whereas P2MR has only local risk (address reuse, which btw would also be solved if we could solve fork-timing). Antoine drew this comparison on his post too but we apparently disagree on which is preferable.

This indeed touches on a fundamental difference in viewpoint.

I believe the primary risk in both approaches ("Never" and "Later") is systemic! Bitcoin either as a whole migrates to PQC resistance, or not and everyone loses. If too many(*) vulnerable coins/users remain on Q-day, I believe the remaining options are all damaging for everyone, because a wide EC freeze may be necessary to remain relevant (who would use a currency where many coins are vulnerable to theft?), but doing so likely undermines Bitcoin's long-term value proposition (how does it differ from an native-PQC altcoin bootstrapped with some arbitrary subset of Bitcoin's UTXO set?). Individual users adopting a quantum-resistant workflow without an expectation that most other users will do the same is not a migration strategy, but a hedge against Bitcoin's ability to meaningfully migrate in time. Yes, if available there will certainly be users taking it, but I'm not convinced it is beneficial for the success probability of currency-wide migration if a "Later" option is available too, and possibly worse.

The "Later" option does not have all the restrictions listed above, and I believe has a chance of getting adopted in the medium term by everyone if available with sufficiently low friction. That of course brings us to how the expectation of a future EC softfork can be relied upon. And it is something of a self-fulfilling prophecy I think. If literally all PQC defense of Bitcoin were to be done through one new output type, then it seems almost a given that the EC disabling will happen in time: even if "Bitcoin" doesn't, someone will create a fork that does so in time, and if it's that essential, that fork will win. A concern may exist about potential disagreement within the community about when the disable-fork should occur, but I think it's still a far better prospect than... essentially making Q-day a guaranteed disaster apart from a few people that get to save their coins, if it happens before the future feature-rich efficient PQC signature schemes can be adopted.

And if you accept that at least a "Later" option is needed, I think adding more PQC options actually weakens it! If some people have their coins in "Never" or "Now" outputs in a PQC-safe manner (subject to the restriction / costs those bring), then that reduces the incentive to get the "Later" narrow EC freeze to occur, and indirectly reduces the value of that output type.

(*) = I don't know what numbers are the threshold here, or how users vs. coins compares. Still, reducing the number of coins/users for which the "theft vs freeze" applies always seems like a win.

Users and devs can control local risk with very simple software tweaks (to avoid address reuse) but they can't do anything about systemic risks.

I think you're vastly underestimating what is simple for most uses. Not sharing public keys or signatures with untrusted parties is a wildly different world than we have today.

This is why I prefer P2MR. If the fork-timing problem can be solved conclusively then maybe P2TRv2 would be viable, but as you've alluded to, we have yet to hear any passable solution that doesn't require a cooperative CRQC.

I think it has a much higher chance of getting ~everyone on it in time, even if there is no certainty.

I lack data, but I suspect that by Q-day most coins will have some knowledge-asymmetry with a CRQC (hash preimages, BIP32 parent keys, hidden P2TR script paths, etc) and so can be rescued with simple commit/reveal protocols - no heavy ZK machinery or hard-forks needed.

I don't understand this, can you elaborate? Having a knowledge-asymmetry seems like something that matters for ZK machinery.

With that in mind, then it doesn't really matter how many recoverable coins migrate before Q-day, does it? If you can assume P2TRv2's PQ-security promise will be deployed on-time, then you can also assume any BIP32 wallet in-use today can be rescued. What we really must care about is migrating the unrecoverable fraction of coins (e.g. JBOK wallets with exposed pubkeys). These should already be rare and will only become rarer as more time passes.

I think anything relying on BIP32 recovery is disaster-recovery territory, not interesting migration, because it'll inevitably be an arbitrary subset that survives. It's something people can think about of course for use in case of a Q-day before migration to PQC-safe outputs at scale happens. As I've argued, that's probably an uninteresting outcome for everyone. People will want to do what they to save what remains, but I don't think it should really matter in this discussion today.

Also, It sounds like you're really saying that the systemic migration to PQC is something that will happen through a commit/reveal, not through what we're discussing now. So what is the point of having something like P2MR or P2TRv2 in the near term?

On a more positive note, if we can someday say "Look, quantum computers appeared and screwed some people over, but most people can recover their coins as long as they fulfill any one of these common criteria," then that seems like Bitcoin's unique value and confiscation resistance is surprisingly intact to me. Certainly better than certain other altcoin migrations I've seen in the past, but I guess this is a subjective question, and everyone will have their own opinion.

Yeah, I have a pretty different view here.

-- 
Pieter

[conduition]

Hi Pieter,

I think it improves one aspect of the incentive differences (relative costs within the output type for common vs. uncommon). The key recovery idea improves another (relative costs w.r.t. P2TR in the common case). Even with both, the result is still worse than P2TR today in both aspects (key-based spend is still more expensive compared to P2TR, and the incentive for key-based over script-based spend is weaker within P2MR).

Yep, all agreed there. These changes would make P2MR better, but still not as good as taproot for pre-Q-day spending.

my reasoning is primarily that the "Never" and/or "Immediately" options are just insufficient with current technology for any worthwhile migration attempt (independent of which commitment structure is used), and thus that we simply need the "Later" option.

Also agreed. Though I take things a step further as I suspect we will also be forced to restrict legacy coins by deploying a rescue protocol, but so far i'm following w.r.t the new output type. Whether it's P2MR or P2TRv2, EC disabling will be highly desirable.

Once you accept that, there is a secondary line of reasoning about which specific structure(s) are , and that is where taproot-based constructions come out ahead by having better incentives in the short- to medium term (the numbers above mean essentially less/zero economical friction).

This is where you lose me. Why does P2TRv2 incentivize migration better than P2MR? You'd have to assume EC disabling will happen and will be timed perfectly. Then assume everyone using Bitcoin will have utter confidence in this TBD timing solution, and no reason to doubt it will work perfectly.

Even then, AFAICT the only distinction to the lay user between P2MR and P2TRv2 is that P2TRv2 is more efficient pre-Q-day, and P2MR is more efficient afterward, and both by about the same margin: 32 witness bytes (counting Boris' EC recovery improvement). That's 8 vbytes per Schnorr spend - less than a cent at current rates.

Theorycrafting for a second here. It's reasonable to conjecture fee rates will be much higher post-Q-day, and thus P2MR's 32 byte advantage over P2TRv2 will yield significant savings for end-users in absolute terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes becomes significant (100 sats per spend or more). In other words, the P2TRv2 internal key will be much more expensive to a user after Q-day than P2MR's PQ leaf script hash will be to a user today.

There are other DX considerations, like P2TRv2 being easier to deploy initially, while P2MR is easier to maintain in the long term since it has no EC code. Etc. But i'm discounting those trade-offs to focus only on the end-users here.

There is one technical difference where the specific commitment structure matters: P2MR ("Merkle-Never") can be used in a Q-safe way and a hypothetical "Taproot-Never" cannot (which includes P2TRv2, if you don't believe in being able to rely on the future narrow disabling), which seems to be the primary reason people like it. However, I think this is extremely restrictive, and simply not an option for most users, because it means:

• Not using wallet indexing services that transmit public keys/xpubs.
  

• ...

You're saying that P2MR without an EC disable fork is not perfectly secure assuming current Bitcoin usage patterns continue. I agree, which is why an EC disabling soft-fork will almost certainly be needed. "Merkle-Never" is impossible IMO. Sooner or later we will disable EC spending in P2MR.

I think our disagreement comes from your assumption we must always time the disabling fork perfectly to coincide with Q-day. On the other hand, I expect we will not solve the fork timing problem, so an EC disable fork will be a messy, panicked affair, arriving possibly quite late (months or years after Q-day). With P2MR, at least holders who used it properly will have shelter, and those who didn't will have an opportunity to move coins somewhere safe to ride things out.

P2TRv2 has no such room for compromise: either everyone is exposed, or nobody is. Well except for all the people who didn't migrate, they're still exposed (which is why we'll need a rescue protocol either way).

And if you accept that at least a "Later" option is needed, I think adding more PQC options actually weakens it! If some people have their coins in "Never" or "Now" outputs in a PQC-safe manner (subject to the restriction / costs those bring), then that reduces the incentive to get the "Later" narrow EC freeze to occur, and indirectly reduces the value of that output type.

Interesting. It sounds like you're arguing that because P2TRv2 is blatantly PQ-vulnerable, it will incentivize future bitcoin users to lock it down later. I mean yes, that's technically true, but that would be like putting a spike on the steering wheels of cars, to incentivize drivers to wear seatbelts.

Should we really bet the entire network on that incentive working out? Even if you're right and we all want very-badly to deploy EC disabling later, how can we know we'll time it correctly?

Remember, it's not just me you have to convince. You'd have to convince everyone to deploy and then adopt P2TRv2 today under the public knowledge that it is insecure and their coins are more likely to be stolen. That's a hard sell.

How does one pitch P2TRv2 to users? "It will be quantum secure one day we promise because everyone is incentivized to fix it later as Bitcoin will die if we don't."

How do you pitch P2MR? "It's quantum secure if you use it correctly."

I don't understand this, can you elaborate? Having a knowledge-asymmetry seems like something that matters for ZK machinery.

Gladly! Any hard relation that can be proven in ZK can also be proven with commit/reveal. It's less flexible because it's not zero-knowledge, so you have to reveal the secret data, and you can only do that once securely. Essentially any PQ-hard relation for which you have knowledge-asymmetry grants you a one-time use signature that cannot be forged by a QC. If you use that OTS to certify a public key (e.g. a SHRINCS key), you can then sign multiple messages.

The simplest example is a hash preimage. With preimage P​ and message m​, I publish H(P)​ and H(P, m)​ at time T​​. Then I reveal (P, m)​​​ at time T+1​. A verifier checks H(P, m)​ was published first, and confirms there exist no earlier reveals for P (by looking for H(P)​​). This confirms I​​ must have also approved the message m​​. A similar mechanism is used as the core coin authentication system of FawkesCoin. There are complexities to handle especially regarding censorship attacks, but ultimately it's doable.

I used a hash function as the relation here, but this can be used to prove any quantum-hard relation: BIP32 derivation, taproot tweaking, musig keys, hashed addresses, etc. You just have to endow the verifier with the correct validation procedures. We're still finding new relevant knowledge-asymmetries today. I really ought to start cataloging them better... I'm hoping to spend more time on this field in the near future because I think it's going to be very important, and right now all the knowledge just lives in mailing list archives.

It sounds like you're really saying that the systemic migration to PQC is something that will happen through a commit/reveal, not through what we're discussing now. So what is the point of having something like P2MR or P2TRv2 in the near term?

Because consensus changes take years to deploy, and we're running out of those. Many people seem to think so at least, I'm no physicist.

Essentially yes though, I expect the majority of holders will probably migrate to PQ addresses via rescue protocols, either on Bitcoin or a fork thereof. Even if we can't come to consensus and deploy a new output type, we'll still be able to rescue most coins. It's just that we'd have nowhere to rescue them to, so we ought to make PQ wallets available soon, so we're not in a rush to build them later when we need them. If a PQ wallet can use cheap EC signatures while they're still trustworthy, all the better.

regards,

conduition

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/_z6_JUmphCkUYvI6gemSFMD9Sb_rDL03IQbtZQCNlk6pmioGEQBir_gMyZCfticFa8Ttfc0xoFHdxR07_MNuAfBu8do_h5IDf2apVk1w1BM%3D%40wuille.net.

[conduition]

I have just submitted a PR into BIP360 which implements the suggestion described in OP.

regards,

conduition

[Pieter Wuille]

Thanks for the comments, conduition,

See my responses inline below.

On Friday, June 12th, 2026 at 12:43 AM, conduition <condu...@proton.me> wrote:

Hi Pieter

my reasoning is primarily that the "Never" and/or "Immediately" options are just insufficient with current technology for any worthwhile migration attempt (independent of which commitment structure is used), and thus that we simply need the "Later" option.

Also agreed. Though I take things a step further as I suspect we will also be forced to restrict legacy coins by deploying a rescue protocol, but so far i'm following w.r.t the new output type. Whether it's P2MR or P2TRv2, EC disabling will be highly desirable.

I want to first correct a potential misunderstanding here, because I realize the terms "Later" and "Never" aren't very descriptive. They are specifically about an expected and relied-upon expectation that an EC-disabling fork will happen that at least applies to the output type itself, in time. "Later" is the expectation that such a disabling will happen after the output type is introduced, but still in time (so, before Q-day). Outputs without a strong expectation that their EC paths/opcodes will be disabled, or not in time, I classify under "Never".

Note that it is not about whether you believe such disabling (possibly in general) will be needed or not, but about whether there is a built-in expectation that it will​ be, as it changes usage patterns: using a "Later" type without PQC path is manifestly incorrect as the coin is subject to burning, and due to the expected EC disabling, cannot be treated as confiscation (which could otherwise be a basis to protest the disabling). The upside is that the EC paths/opcodes in it can be used without the arduous restrictions of post-EC-safety (no address reuse, no pubkey sharing, ...). It also trades the security assumption of CRQCs being too slow for short-range attacks for a security assumption that the EC disabling will happen in time.

So under that terminology (and again, apologies for the confusing naming, feel free to suggest better ones, but I'll stick with them for now to not confuse things further):

• I think most people interpret P2MR as something that falls under Merkle-Never. Sure, some may assume EC disabling in general will be needed, but there is no strong expectation that P2MR will have EC opcodes disabled before Q-day, I think.
• It's possible to consider an alternative to P2MR ("P2MR+ED") which comes with a built-in Expected Disabling of (just) its own EC opcodes before Q-day, which would fall under Merkle-Later.
• P2TRv2 falls under Taproot-Later.
• A hypothetical proposal to add just PQC opcodes to normal P2TR would be under Taproot-Never.
• A new output type ("P2QR") that is like P2MR, but with EC disabled right from the start would be under Merkle-Now.

I introduce this separation into two dimensions because I think most of the arguments for/against P2TRv2 vs P2MR are really arguments about "Later" vs "Never", rather than arguments about "Taproot" vs "Merkle".

Having a "Later" type does not rule out the possibility of also having a separate general EC disabling, but it can (and hopefully does) significantly reduce the need/impact of that. Coins whose EC path/opcodes are disabled through the "Later" type aren't confiscated. If that gets adopted at scale, it removes those coins entirely from the steal-or-freeze equation. Perhaps to the point where general freezing is not considered a necessity anymore. Perhaps to the point where general freezing is limited to old presumed-lost coins, and the Bitcoin community then doesn't see that as an infringement on its core value proposition anymore.

So the point of mine you're responding to here is really saying: we need​ a "Later" output type, whether that's P2MR+ED or P2TRv2 or something else, because other output types are practically unavailable to large classes of users: "Never" (because it is so restrictive in how it can be used in ways that are incompatible with today's reality) and "Now" (because it's too expensive and comes with bad privacy trade-offs, probably encouraging address/key reuse to avoid needing to share tons of keys etc).

• 
  

Once you accept that, there is a secondary line of reasoning about which specific structure(s) are , and that is where taproot-based constructions come out ahead by having better incentives in the short- to medium term (the numbers above mean essentially less/zero economical friction).

This is where you lose me. Why does P2TRv2 incentivize migration better than P2MR? You'd have to assume EC disabling will happen and will be timed perfectly. Then assume everyone using Bitcoin will have utter confidence in this TBD timing solution, and no reason to doubt it will work perfectly.

The point you're responding to is about if​ you already accept that we need "Later", then among the two options "P2MR+ED" or "P2TRv2", the latter is preferable.

I believe here you're instead arguing for P2MR ("Merkle-Never") over all "Later" options. That was my previous point: I think (solely) having "Never" output types like P2MR is just utterly insufficient for any worthwhile migration. It's so incompatible with today's workflows that it either won't be adopted, or (possibly inadvertently) adopted in an insecure fashion. Yes, it gives people the option to safeguard their own coins, but to me that's disaster recovery territory - I think we ought to prioritize maximizing the chances for saving the currency as a whole in case Q-day comes, not a small subset of individual users' coins. P2MR (alone) doesn't really achieve much in that regard in my view, thus we at least need something of the "Later" class in addition.

So the point here was just: if you already accept the need for a "Later" output type (= one with builtin-in EC disabling expected from the start), P2TRv2 is preferable over P2MR+ED, because:

• It's cheaper for now for common cases, thus has lower friction for adoption, especially to those for whom quantum-resistance isn't a priority.
• It has less incentive for misuse, because the only​ reason why anyone would use P2TRv2 is quantum resistance (given that P2TR already exists).
• Their security assumptions are identical (all based on expected EC disabling before Q-day; but note that that isn't the case for "Never" P2MR).
• Preserving the taproot incentive structure better, for now.

Even then, AFAICT the only distinction to the lay user between P2MR and P2TRv2 is that P2TRv2 is more efficient pre-Q-day, and P2MR is more efficient afterward, and both by about the same margin: 32 witness bytes (counting Boris' EC recovery improvement). That's 8 vbytes per Schnorr spend - less than a cent at current rates.

Yes, but one doesn't need to look back very far to see times where Bitcoin fee rates were much higher, and presumably, if Bitcoin is going to survive post-subsidy, it'll need much higher fees in any case. I don't think you can use today's low-fee regime as an argument for fees not being relevant.

Theorycrafting for a second here. It's reasonable to conjecture fee rates will be much higher post-Q-day, and thus P2MR's 32 byte advantage over P2TRv2 will yield significant savings for end-users in absolute terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes becomes significant (100 sats per spend or more). In other words, the P2TRv2 internal key will be much more expensive to a user after Q-day than P2MR's PQ leaf script hash will be to a user today.

Agreed. After Q-day we'll probably want some "Merkle" type (P2MR or P2QR), or something novel we haven't imagined yet. But I think that's a concern for later, when we're ready to adopt "full migration" technology (feature-rich, efficient, PQC). If Q-day comes before that time, we'll inevitably be scrambling in a somewhat suboptimal but hopefully survivable world. I don't think we should optimize for the hopefully short / avoidable temporary "after Q-day, before fancy tech" time, at the cost of (a) reducing the chances of actually migrating the Bitcoin ecosystem to be Q-ready and (b) incentives and properties in the present time before Q-day.

I think our disagreement comes from your assumption we must always time the disabling fork perfectly to coincide with Q-day. On the other hand, I expect we will not solve the fork timing problem, so an EC disable fork will be a messy, panicked affair, arriving possibly quite late (months or years after Q-day). With P2MR, at least holders who used it properly will have shelter, and those who didn't will have an opportunity to move coins somewhere safe to ride things out.

This is very interesting. I have reservations too about the "Later" EC-disabling soft fork expectations about P2TRv2, but they're not about whether the future Bitcoin ecosystem can coordinate a softfork; that seems almost trivial if not doing so poses an existential threat, and could be done within a few months if it's expected and designed already. I'm more worried about it not being adopted due to indifference/friction, or being abused/misused. 

FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed perfectly. The expectation should be just that it happens before Q-day, and when it looks inevitable or the fear about that is large enough. There is certainly some variance there, and there will be some disagreement, but I can't imagine we don't get at least a year's worth of notice in the form of breakthroughs on simpler QC problems.

And if you accept that at least a "Later" option is needed, I think adding more PQC options actually weakens it! If some people have their coins in "Never" or "Now" outputs in a PQC-safe manner (subject to the restriction / costs those bring), then that reduces the incentive to get the "Later" narrow EC freeze to occur, and indirectly reduces the value of that output type.

Interesting. It sounds like you're arguing that because P2TRv2 is blatantly PQ-vulnerable, it will incentivize future bitcoin users to lock it down later. I mean yes, that's technically true, but that would be like putting a spike on the steering wheels of cars, to incentivize drivers to wear seatbelts.

First a meta-point here: the reason I like separating the discussion into different dimensions than just "P2TRv2 vs P2MR" is because there are more options than those two, and not every argument applies to the same separation into two classes. Let me list them explicitly here, roughly in decreasing order of how strongly I feel about them:

1. We need at least a "Later" option for meaningful migration, i.e. P2TRv2 or P2MR+ED.
2. Within the "Later" option, P2TRv2 is preferable.
3. A "Later" option benefits from being the only PQC migration strategy, making it a Schelling point.
   

If one were to disagree with just (3), other options could be e.g. to introduce both P2TRv2 and P2MR, or even P2TRv2 and P2QR. That may be easier or harder to get consensus on, I don't know. I think having multiple PQC migration paths makes the "Later" option less compelling (3), but even then I believe we still need one (1).

Secondly, yes I understand the concern, if you phrase it like that. But I think this sort of risk exists whether we choose to base the new output type's security on it or not. I think Bitcoin can only meaningfully survive a systemic risk of this nature through collective action, at least in the near to medium term, and the P2TRv2-expected-disabling one has at least a chance of being sufficient, and is non-invasive. In contrast, one that needs to freeze non-opted-in coins is likely far more damaging.

Should we really bet the entire network on that incentive working out? Even if you're right and we all want very-badly to deploy EC disabling later, how can we know we'll time it correctly?

I don't see it as a bet. It's an opportunity, and we can choose to take it or not. If Q-day comes before migration can reach meaningful levels (what those are is probably a matter of perspective), then I think there isn't much of an interesting future for Bitcoin anyway.

Remember, it's not just me you have to convince.

Absolutely! But I think your views probably reflect those of many others, so getting to the core of things like this thread seems to be doing can gain us insight.

You'd have to convince everyone to deploy and then adopt P2TRv2 today under the public knowledge that it is insecure and their coins are more likely to be stolen. That's a hard sell.

How does one pitch P2TRv2 to users? "It will be quantum secure one day we promise because everyone is incentivized to fix it later as Bitcoin will die if we don't."

How do you pitch P2MR? "It's quantum secure if you use it correctly."

To me, the pitch is "Bitcoin can only remain valuable if we mostly/all migrate." for both. P2TRv2 is just much easier to adopt, because P2MR (or any "Never" output type) fundamentally requires many users to change their workflows entirely.

This focus on allowing individual users the ability to safeguard their coins just feels like a red herring: I'm not worried about my own coins being stolen. I'm worried about (fear of) a CRQC undermining trust in the currency as a whole, or through a fear-driven consensus change the ecosystem destroying its own values beforehand.

The simplest example is a hash preimage. With preimage P​ and message m​, I publish H(P)​ and H(P, m)​ at time T​​. Then I reveal (P, m)​​​ at time T+1​. A verifier checks H(P, m)​ was published first, and confirms there exist no earlier reveals for P (by looking for H(P)​​). This confirms I​​ must have also approved the message m​​. A similar mechanism is used as the core coin authentication system of FawkesCoin. There are complexities to handle especially regarding censorship attacks, but ultimately it's doable.

Neat, thanks for explaining. You'd need some way to attach these to a specific UTXO(s), I'd imagine, so the information can live with, and disappear with, those outputs. Otherwise you need an boundlessly growing set of H(P) values to prevent reuse?

In either case, I consider anything that requires hardcoding specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus rules (and only allowing those coins to survive) to be squarely in disaster-recovery land. It feels like embracing arbitrariness, and giving up on the permissionlessness that makes Bitcoin interesting - if the community shows it can get consensus on effectively burning coins except those that match a whitelist, it feels hard to maintain censorship-freeness as a value, even if the whitelist includes most of the (active) coins. That is of course not to say such techniques aren't interesting to work on, but to me, their place is in disaster recovery scenarios to save what's left, after Q-day, if migration attempts were unsuccessful. In such a setting, I think we're already in effectively an altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly growing) set of ways to recover burned coins can be hardforked in.

Because consensus changes take years to deploy, and we're running out of those. Many people seem to think so at least, I'm no physicist.

I understand the feeling of urgency, but this seems like a "we must do something, this is something, thus we must do it!" approach that just gives people the impression something is being done, without fundamentally tackling the hard problem of actually migrating Bitcoin, and leaving that harder problem to a (to me) very undesirable, but still unspecified future. And solving that harder problem will inevitably need another consensus change later, so it doesn't help with the "running out of years" problem if you believe those take too long.

My impression is that your approach is to have an answer for many possible futures, including ones where Q-day arrives within just a few years. But optimizing for disaster-recovery also means reducing the chances of preserving Bitcoin as we know it in the scenarios where a successful migration is still possible. And if Q-day does arrive that soon, I don't see what we can do today that would preserve Bitcoin in a form we care about anyway. By accepting that, we can focus on the futures where our choices today can still materially improve the outcome.

Essentially yes though, I expect the majority of holders will probably migrate to PQ addresses via rescue protocols, either on Bitcoin or a fork thereof. Even if we can't come to consensus and deploy a new output type, we'll still be able to rescue most coins. It's just that we'd have nowhere to rescue them to, so we ought to make PQ wallets available soon, so we're not in a rush to build them later when we need them. If a PQ wallet can use cheap EC signatures while they're still trustworthy, all the better

Thanks, I think that very much highlights a difference in vision. To me, if we need to mostly migrate to PQ through rescue protocols post Q-day, we've long lost already. Since it's just not an interesting future to me, I weigh optimizing for it as a very minor secondary goal at best, and actively distracting at worst.

Of course, if you believe it's the only possible future, I understand you'd come to a different conclusion. But is it really? Do you think this isn't a plausible future:

• A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added too) gets introduced in the next few years, with hash-based PQC opcodes.
• Over the course of the next decade or so, it gets adopted by practically all active users.
• What happens next depends on whether Q-day happens late-ish or soon-ish afterwards:
• Late-ish (incl. never):
• Isogenies (or something else) get a ton more attention, implementations get more efficient, gain well-studied features like tweaking and homomorphic derivation, get far better confidence in their security.
• A P2QR output type with isogeny PQC (or possibly hybrid EC+isogeny) opcodes get added.
• Many users migrate over to this P2QR type, and are fully living in a Q-migrated world.
• (Possibly) Q-day happens, and nobody cares.
• Soon-ish:
• A (not-quite-CR)-QC breaks 128-bit ECDLP, say.
• The community quickly softforks to disable EC paths/opcodes in P2TRv2. It's messy, spending gets expensive, there are privacy losses from PQC key reuse etc, but nothing really breaks.
• Some stragglers migrate still, but a large part of the ecosystem migrated already, supporting wallets are commonplace.
• Based on how worried people are about early-era unmigrated coins, either them being stolen isn't considered a threat anymore, or they get still widely frozen but it's just a minority / presumed-lost coins.
• Q-day happens.
• Accelerated research into PQC schemes gets incorporated into P2QR, over a longer time period, and eventually the messiness of P2TRv2 disappears.

There are many other possible futures. Some are minor variations of these two scenarios. Some are fairly bad independently of the choice between P2MR or P2TRv2 (e.g. Q-day comes before any substantial migration). Some are mostly fine regardless (e.g. everyone has time to migrate to later P2QR isogeny stuff, or just no CRQC ever). But these two in particular, I think have a much better chance of happening with P2TRv2 than P2MR, because far more people can just adopt it with low friction.

Cheers,

-- 

Pieter

[Anthony Towns]

On Tue, Jun 16, 2026 at 08:09:08PM +0000, Pieter Wuille wrote:
> I want to first correct a potential misunderstanding here, because
> I realize the terms "Later" and "Never" aren't very descriptive. They
> are specifically about an expected and relied-upon expectation that an
> EC-disabling fork will happen that at least applies to the output type
> itself, in time. "Later" is the expectation that such a disabling will
> happen after the output type is introduced, but still in time (so, before
> Q-day). Outputs without a strong expectation that their EC paths/opcodes
> will be disabled, or not in time, I classify under "Never".

> I believe here you're instead arguing for P2MR ("Merkle-Never")
> over all "Later" options. That was my previous point: I think (solely)
> having "Never" output types like P2MR is just utterly insufficient for
> any worthwhile migration. It's so incompatible with today's workflows
> that it either won't be adopted, or (possibly inadvertently) adopted
> in an insecure fashion. Yes, it gives people the option to safeguard
> their own coins, but to me that's disaster recovery territory - I think
> we ought to prioritize maximizing the chances for saving the currency
> as a whole in case Q-day comes, not a small subset of individual users'
> coins. P2MR (alone) doesn't really achieve much in that regard in my view,
> thus we at least need something of the "Later" class in addition.

I'm not sure I follow/agree with the logic here. I think the general idea
is:

1) we create some new address types that allow post-quantum spending, but
also allow efficient quantum-vulnerable spending that can be used prior
to Q-day

2) many people migrate to these new address types

3) Q-day arrives

4) all spending goes via the post-quantum paths, and everyone's funds are
safe

There are three main variations to this, I think:

Later-dominant: towards the end of (2) but prior to (3), the
quantum-vulnerable spend paths are disabled in a predictable, planned
manner, preventing coin theft, but not disrupting active usage
significantly (or not disrupting it any more than the proximity of
Q-day already is).

Self-reliance: Q-day goes from maybe to definitely faster than consensus
changes can be coordinated, and the only reason people's funds remain
safe is that they can (and do) keep the quantum-vulnerable spend
paths secret.

Disaster-recovery: neither the "predictable/planned consensus change" of
Later nor the "everyone takes responsiblity for their own funds"
works, and the only way to avoid a large percentage of bitcoin
becoming a reward for quantum research is to replace EC spend paths
with a ZK proof of knowledge of a BIP32 seed or similar, requiring
a hard fork. Such a hard fork would be certain to be controversial
("why at this height: I received a payment five blocks after //
my funds were stolen by a quantum attacker five blocks earlier //
why are only BIP32 funds recoverable not scheme X"), but if no other
approach works, might still be the ultimately outcome.

> So the point here was just: if you already accept the need for a "Later"
> output type (= one with builtin-in EC disabling expected from the start),
> P2TRv2 is preferable over P2MR+ED, because:

As far as I can see, only having P2TRv2 addresses would rule out the
"self-reliance" path here.

Picking when Q-day will occur, either individually for determining
your own security posture, or collectively for organising a consensus
change seems very difficulty: it involves evaluating both complex state
of the art physics research, but also estimating the covert abilities
of national governments and the incentives to attack bitcoin prior to
revealing their capabilities. To me, that doesn't bode well for a smooth
and fast deployment of a consensus change in advance of problems occuring.

It's possible that general carelessness on behalf of users would also
rule out the effectiveness of a self-reliance approach: if only the most
conscientious 1% of users make use of P2MR securely, that might secure 10%
of funds, but having 90% of the bitcoin supply crash probably wouldn't be
very valuable either. But even then, that may make the "disaster-recovery"
approach less problematic, by ensuring the 1%/10% who were conscientious
can avoid being part of the "my funds were stolen by a quantum attacker"
contingent, eg.

> > Theorycrafting for a second here. It's reasonable to conjecture fee
> > rates will be much higher post-Q-day, and thus P2MR's 32 byte advantage
> > over P2TRv2 will yield significant savings for end-users in absolute
> > terms. If fee rates inflate 10x higher after Q-day, then 8 vbytes becomes
> > significant (100 sats per spend or more).

I don't think that is the right way to look at. 8vb/input is about
an additional 14% today (vs a taproot key-path spend), but with the
post-quantum signatures we have available now that's likely to reduce
to ~7% (SHRINCS) or ~1% (winternitz). So, post-Q-day, by dropping 32B,
you're only getting an expected savings in fees / increase in block
capacity on that order of magnitude, ie: 1%-7%. That's nice to have,
for sure, but doesn't compare to introducing a new address type that
puts the PQ sigs in an extension block, or one that uses ZK proofs to
do cross-input or cross-transaction signature aggregation, eg. So a 32B
witness overhead for an unused/unusable key-path post-Q-day doesn't seem
very relevant to me.

> FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed
> perfectly. The expectation should be just that it happens before Q-day,
> and when it looks inevitable or the fear about that is large enough.

FWIW, I would define "timed perfectly" precisely as "EC disabling
fork happens before Q-day". Maybe allowing some additional months of
EC-efficiency would be a win while not taking out too much migration time,
but for me "perfection" here means "no one who upgraded lost money via
quantum-related vulnerabilities".

One reason I'm doubtful is that I think for some the "it looks inevitable"
threshold has already been crossed, eg:

>> So let me attempt to partially fill the silence, similarly to what
>> Scott Aaronson did in his April 29 post. Given everything I know,
>> including scary non-public information, I now put the odds of qday by
>> 2032 at 50%. 10% by 2030.

>> IMO a good target date for migration is 2029, roughly 3.5 years
>> out. 2029 happens to be the date selected by Google, Cloudflare, and
>> the Ethereum Foundation.

https://x.com/drakefjustin/status/2061793725299224676

>> So, here it is: if quantum computers start breaking cryptography a
>> few years from now, don’t you dare come to this blog and tell me that
>> I failed to warn you. This post is your warning. Please start switching
>> to quantum-resistant encryption, and urge your company or organization
>> or blockchain or standards body to do the same.

https://scottaaronson.blog/?p=9718

Personally, that leaves me at a minimum very skeptical of the utility
of introducing either P2MR or P2TRv2 (etc) approaches that don't also
introduce a quantum-safe spending path on day one.

> First a meta-point here: the reason I like separating the discussion into different dimensions than just "P2TRv2 vs P2MR" is because there are more options than those two, and not every argument applies to the same separation into two classes. Let me list them explicitly here, roughly in decreasing order of how strongly I feel about them:

> - We need at least a "Later" option for meaningful migration, i.e. P2TRv2 or P2MR+ED.
> - Within the "Later" option, P2TRv2 is preferable.
> - A "Later" option benefits from being the only PQC migration strategy, making it a Schelling point.

Correct me if I'm mistaken, but I think P2TRv2 is preferable only in the
"Later-dominant" scenario, and only to the degree that it's slightly
cheaper prior to Q-day. If it were the only available option, that would
increase the risk of loss involved with both the other approaches. (I
don't think P2TRv2 is meaningfully more private than P2MR in the way
taproot v1 is, as presumably you'd only adopt that address format if
you wanted to have a post-quantum script path)

> > You'd have to convince everyone to deploy and then adopt P2TRv2 today under the public knowledge that it is insecure and their coins are more likely to be stolen. That's a hard sell.
>
> > How does one pitch P2TRv2 to users? "It will be quantum secure one day we promise because everyone is incentivized to fix it later as Bitcoin will die if we don't."
> >
> > How do you pitch P2MR? "It's quantum secure if you use it correctly."
> To me, the pitch is "Bitcoin can only remain valuable if we mostly/all migrate." for both. P2TRv2 is just much easier to adopt, because P2MR (or any "Never" output type) fundamentally requires many users to change their workflows entirely.

Let's call NoEC-day the earlier of activation of a soft-fork disabling
EC-spends on P2MR/P2TRv2 or Q-day. NoEC-day to some extent is presumably
equal to "the day the bitcoin ecosystem has finally agreed that CRQCs
are inevitable".

My (cynical?) view is the only people who will adopt either P2TRv2 or
P2MR prior to NoEC-day being schedule will be people who are willign
to use those features in a quantum-safe way -- that is, keeping their
EC pubkeys secret, and only revealing those EC pubkeys to spend them
immediately, prior to NoEC-day. In that view, the EC-spend-paths of such
coins prior to NoEC-day are only an opportunistic "make spends cheaper"
shortcut, they don't allow the funds to be used in lightning channels
or to let your wallet be audited via sharing an xpub or anything similar.

Perhaps I'm wrong: it's my opinion, not a technical fact; it's possible
that lightning software could get an upgrade to generate post-quantum
signatures for channel commitments or HTLC claims, I just think it's
pretty unlikely that that will happen at a meaningful scale when everyone
has much more immediate and less theoretical things to work on prior to
NoEC-day, especially when the efficiency/performance of such changes is
likely to be very low.

> This focus on allowing individual users the ability to safeguard their

> coins just feels like a red herring: [...]

While I appreciate your point, I also feel that "allowing individual
users the ability to safeguard their coins" is pretty close to the entire
point of Bitcoin. :)

> In either case, I consider anything that requires hardcoding
> specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus
> rules (and only allowing those coins to survive) to be squarely in
> disaster-recovery land. It feels like embracing arbitrariness, and
> giving up on the permissionlessness that makes Bitcoin interesting -
> if the community shows it can get consensus on effectively burning
> coins except those that match a whitelist, it feels hard to maintain
> censorship-freeness as a value, even if the whitelist includes most of
> the (active) coins. That is of course not to say such techniques aren't
> interesting to work on, but to me, their place is in disaster recovery
> scenarios to save what's left, after Q-day, if migration attempts were
> unsuccessful. In such a setting, I think we're already in effectively an
> altcoin-with-UTXO-bootstrapped-from-Bitcoin territory, and a (possibly
> growing) set of ways to recover burned coins can be hardforked in.

Just for the record, I think the above is an accurate description of the
"disaster-recovery" scenario above: the "quantum-safe" hard-fork variant
of bitcoin would be fairly described as a utxo-bootstrapped altcoin,
would compete in the market with the "quantum-unsafe" bitcoin that
existing nodes would continue to follow, and possibly there would be
many slightly varying such altcoins competing with each other, eg on
exactly what height the utxo snapshot was taken or what coins become
spendable. It would not be a fun time for holders of affected utxos.

> My impression is that your approach is to have an answer for many
> possible futures, including ones where Q-day arrives within just a few
> years.

"The key of strategy... is not to choose a path to victory, but to choose
so that all paths lead to a victory."

-- https://tvtropes.org/pmwiki/pmwiki.php/Main/XanatosGambit

> But optimizing for disaster-recovery also means reducing the
> chances of preserving Bitcoin as we know it in the scenarios where a
> successful migration is still possible. And if Q-day does arrive that
> soon, I don't see what we can do today that would preserve Bitcoin in
> a form we care about anyway. By accepting that, we can focus on the
> futures where our choices today can still materially improve the outcome.

Preserving bitcoin as a personally-possessible inflation resistant
store of value seems both possible and worth caring about, even if other
constraints means that many people can't afford to personally hold it
(and have to go through ETFs/exchanges/banks) and that it can't be used
for day-to-day transactions. Would be very disappointing if true, and
even given Q-day in a few years I expect we could do better than just
that, but it doesn't feel like a throw-in-the-towel event to me.

> > Essentially yes though, I expect the majority of holders will probably
> > migrate to PQ addresses via rescue protocols, either on Bitcoin or a fork
> > thereof. Even if we can't come to consensus and deploy a new output type,
> > we'll still be able to rescue most coins. It's just that we'd have nowhere
> > to rescue them to, so we ought to make PQ wallets available soon, so we're
> > not in a rush to build them later when we need them. If a PQ wallet can
> > use cheap EC signatures while they're still trustworthy, all the better

FWIW, that's my guess on how things would play out if the near-term Q-day
timelines I've seen (ie, 2029 to 2035) match reality. I hope that's
pessimistic (either because the Q-day timelines are bad estimates, or
because migration happens in a more orderly fashion), but I guess we'll
see. I don't rate my ability to evaluate Q-day predictions very highly.

> - A (not-quite-CR)-QC breaks 128-bit ECDLP, say.

I'm not in a position to judge, but the google paper claims:

"Indeed, if a leading quantum architecture encounters and overcomes
all its scaling challenges before producing a device able to
solve (for example) 32-bit ECDLP, then there may be little time
between the breaking of 32-bit ECDLP and the breaking of 256-bit
ECDLP. Furthermore, the community should not expect to see published
demonstrations of the most advanced quantum error-correction
architectures and quantum algorithms deployed to cryptanalytic
problems. Thus, a successful public demonstration of Shor’s
algorithm on a 32-bit elliptic curve should not be seen as a wake-up
call to adopt PQC as much as a potential signal that PQC adoption
has already failed."

and places the required tiffoli gates and logical qubits for a 32-bit
break at about (300k, 200) vs (10M, 600) for 128-bit or (80M, 1100)
for 256-bit.

> Of course, if you believe it's the only possible future, I understand
> you'd come to a different conclusion. But is it really? Do you think
> this isn't a plausible future:

> - A P2TRv2 type (let's leave aside whether P2MR or P2QR gets added too) gets introduced in the next few years, with hash-based PQC opcodes.
> - Over the course of the next decade or so, it gets adopted by practically all active users.

I think it might be better to look at that scenario in a more fine-grained
way? I think your "Late-ish" scenario is:

1) P2TRv2 (or whatever) is introduced
2) Some PQ opcodes get enabled, allowing expensive but PQ-safe spend-paths
via those outputs
3) P2PK, P2PKH, P2WPKH, P2WSH, P2TR all become obsolete in favour of P2TRv2,
but EC spend paths continue to be what's used in practice.
4) Some better PQ solutions become available, allowing cheap PQ-safe spend-paths
5) Everyone switches from EC paths to the new PQ paths.
6) NoEC-day happens, but no one is impacted.

I think your "Soon-ish" scenario differs as of step (4):

4) NoEC-day happens. Massive disruption because the "what's used in practice"
path breaks, but everything is recoverable.
5) Post-quantum approaches get even higher priority

I'm skeptical of step 3 here; and would expect to see something more like:

3') Only a small proportion of users (ie, the most conscientious/fearful)
switch to P2TRv2 with most preferring to stick with what works

That has no real impact on the Late-ish scenario, but changes the Soon-ish
scenario to either:

4'a) NoEC-day happens substantially before Q-day; people hurry to migrate
to P2TRv2, but it mostly works.

or

4'b) NoEC-day happens essentially at the same time as Q-day; coins get
stolen and we hit the disaster-recovery scenario.

Perhaps the difference between (3') and (3) playing out in reality
is just having nearly everyone agree that the upgrade is essential,
and rather than leaving it to self-interest/market-dynamics, having a
consistent push that every single wallet/service that doesn't deprecate
every current address type is a danger to the entire ecosystem, even
absent widespread agreement on when/if Q-day will happen. Arguably that
would be easier to agree on if the incremental cost of EC spend paths
in P2TRv2 prior to NoEC-day/Q-day versus current spend paths is near to
zero, rather than up to ~14% per input.

Cheers,
aj

[conduition]

I really appreciate you all taking the time to have this important discussion together and still keeping things civil. The discussion on this thread has branched out from PQ migration destinations into also discussing confiscatory retroactive upgrades, like rescue protocols. I think, as per Antoine's recent thread, it's a mistake to conflate the two subjects, so this first email is just going to focus on designing secure PQ output types, and I'll include responses to the retroactive stuff in a separate message.

----------

I feel like we've all been pulled deep into the weeds of forecasting different quantum doom scenarios here. I'm gonna try to pick out the key disagreement we are dancing around, and examine it more closely.

Sipa's comment here:

I can't imagine we don't get at least a year's worth of notice in the form of breakthroughs on simpler QC problems.

...is emblematic of an assumption baked into the security of P2TRv2: That we can predict Q-day. Unfortunately, no one - not even quantum computing experts, let alone the Bitcoin community - can reliably predict when Q-day will happen, if it even happens at all. I think this is the core problem we need to dissect.

On one hand, if we assume we'll be able to predict Q-day in advance, then we can get away with a lot: Use maximally efficient EC key-spending (P2TRv2) till the last moment, then disable EC. Deploy P2MR with only PQ sigs, and everyone can slowly migrate to use PQ sigs on P2MR. That'd be the ideal world.

But we may or may not live in that world. We have no certainty that such large technological leaps will happen slowly and behave predictably. Could the world in 1944 (outside Los Alamos) have confidently predicted the first use of an atomic bomb in 1945? Could the world in 2006 (outside Apple) have confidently predicted the iPhone would debut in 2007? How many of us in 2021 would have bet on LLMs or stable diffusion appearing? What the odds today on net-positive fusion energy for 2027? In many cases, even the innovators building these things couldn't have foreseen their success more than a few weeks in advance.

On the other hand, we also have no certainty a leap will happen quickly, or that it will happen at all. AJ highlighted some great quotes from the google paper which suggest it might happen quickly... but for all we know, maybe there's some "Great Filter" that stalls QC scaling around X Toffoli gates, or at n qubits.

Ultimately we just don't know one way or the other. AJ put it very well here:

Picking when Q-day will occur, either individually for determining your own security posture, or collectively for organising a consensus change seems very difficulty: it involves evaluating both complex state of the art physics research, but also estimating the covert abilities of national governments and the incentives to attack bitcoin prior to revealing their capabilities. To me, that doesn't bode well for a smooth and fast deployment of a consensus change in advance of problems occuring.

With that in mind, i will now attempt an argument for P2MR based on the premise that Q-day is unpredictable (at least for now).

I follow sipa's more general belief that a follow-up EC disable soft-fork for the new output type is desirable, to reduce harm after Q-Day from EC pubkey exposure. We all seem to agree there.

However, I strongly doubt that we (the entire bitcoin community) will be able to time such a fork correctly. By "correctly", I mean: within a few days before, but no later than Q-day (the first day a CRQC would be able to start stealing coins).

Why am I so strict about the timing? Consider if we accepted AJ's definition of perfect timing, 

FWIW, I would define "timed perfectly" precisely as "EC disabling fork happens before Q-day". Maybe allowing some additional months of EC-efficiency would be a win while not taking out too much migration time, but for me "perfection" here means "no one who upgraded lost money via quantum-related vulnerabilities".

...with which sipa seems to agree:

FWIW, I don't think the P2TRv2 EC-disabling fork needs to be timed perfectly. The expectation should be just that it happens before Q-day, and when it looks inevitable or the fear about that is large enough

I disagree. If we disable EC months in advance of Q-day, and if we do so only for the new output type, then it will likely backfire. During those months, a subset of coins will regress back to using classical wallets - P2TR, P2WPKH, etc - for many reasons. Maybe they think CRQCs are not a real threat yet. Maybe they think they can predict Q-day better than we did, and don't want to pay the extra sats for larger PQ signatures until then. Maybe they need EC for a specific protocol and haven't finished migrating their code to PQ yet. Who knows. But the longer the duration between EC disabling and the first verifiable proof of CRQCs (likely to arrive on or after Q-day), the more opportunity and incentive there will be for users to regress back to a place of vulnerability.

Thus if we entirely rely on EC disabling for the security of the new output type, as in P2TRv2, we should time such a deployment perfectly: Any later and all users are vulnerable. Too much earlier, and users are incentivized to regress.

Also recall that "we disable" really means "the entire community agrees to disable". If dictatorial power were vested in the hands of a well-informed autist with a Dark-Forest-style Big Red Button, then maybe they'd have a chance to react to Q-day. But an entire decentralized network, fraught with misinformation and polarized politics? Not likely, unless we can build and deploy a trustless, unattended canary in advance of Q-day, which somehow doesn't require a cooperative CRQC. That seems implausible today but I would welcome any evidence to the contrary.

And so, since timing is hard, I assert that we should prefer P2MR over P2TRv2 because we are confident P2MR is sound even if the EC disable fork is deployed late (after Q-day).

With P2MR, we at least have some wiggle-room in our timing of the EC disabling soft-fork. Maybe not a lot - depends on how much users expose their EC leaves - but perhaps enough to give us time to react while the CRQC gets busy cracking exposed keys.

As to the question of P2MR's "friction" that sipa claims discourages migration, I think this is a low-impact point in the debate and I have no rebuttal, except that a temporary tax of 32 weight units per input seems a small price for insurance against theft/devaluation of one's entire stack. I suspect P2MR's current popularity - even before Boris' EC recovery idea - is driven by that sentiment. If anything I'd argue that P2TRv2's timing-sensitivity would have an even sharper chilling effect and would curb migration progress much more than P2MR's 32 extra weight units would.

Maybe I am wrong, and 32 WU/input is a significant factor impacting user behavior before Q-day. If so, this amplifies my earlier point that deploying EC disabling too early will incentivize regression to classical addresses, and we would need to be even more careful in our timing: The pre-Q-day efficiency gap between EC and PQ sigs is much wider than the gap between P2MR and P2TRv2.

With my main argument made, I'd like to respond to individual points and questions:

I have reservations too about the "Later" EC-disabling soft fork expectations about P2TRv2, but they're not about whether the future Bitcoin ecosystem can coordinate a softfork; that seems almost trivial if not doing so poses an existential threat, and could be done within a few months if it's expected and designed already. I'm more worried about it not being adopted due to indifference/friction, or being abused/misused.

Interesting, what gives you confidence that we'll be able to coordinate and time it correctly? Assuming everyone agrees and wants to, how would we go about it?

Bitcoin can only meaningfully survive a systemic risk of this nature through collective action

Agreed! I think we just disagree about which collective actions are most important, and we have differing confidence in the feasibility of those actions and their timing.

This focus on allowing individual users the ability to safeguard their coins just feels like a red herring: I'm not worried about my own coins being stolen. I'm worried about (fear of) a CRQC undermining trust in the currency as a whole, or through a fear-driven consensus change the ecosystem destroying its own values beforehand.

I second AJ:

While I appreciate your point, I also feel that "allowing individual users the ability to safeguard their coins" is pretty close to the entire point of Bitcoin. :)

Sovereign control of value is the core promise of Bitcoin. 

However, sipa's argument is also very valid. We need to do everything we can to preserve overall integrity of the entire UTXO set, as much as is humanly possible. This preserves trust in the currency as a whole.

We can have both, by deploying P2MR with PQ sigs to secure those who can migrate in time, and then an EC disabling follow-up, maybe with rescue protocols to secure procrastinators. This protects as many UTXOs as I think are possible with current knowledge, and is not as sensitive to timing as if we used P2TRv2.

I understand the feeling of urgency, but this seems like a "we must do something, this is something, thus we must do it!" approach that just gives people the impression something is being done, without fundamentally tackling the hard problem of actually migrating Bitcoin, and leaving that harder problem to a (to me) very undesirable, but still unspecified future. And solving that harder problem will inevitably need another consensus change later, so it doesn't help with the "running out of years" problem if you believe those take too long.

I also dislike that class of argument. People use it all the time here to justify half-baked "solutions" to quantum problems. But that's not what I was saying in my point.

The act of migration itself is indeed a very complex task, vastly different from designing the migration paths. We can't start working on the latter until we have the former. So no, working on a migration path is really important and does help with "running out of years", because if we did nothing we'd have nowhere to migrate coins to, or we'd have to rush something out in a hurry when it is urgently needed.

Of course, if you believe it's the only possible future, I understand you'd come to a different conclusion. But is it really? Do you think this isn't a plausible future:

...

There are many other possible futures. Some are minor variations of these two scenarios. Some are fairly bad independently of the choice between P2MR or P2TRv2 (e.g. Q-day comes before any substantial migration). Some are mostly fine regardless (e.g. everyone has time to migrate to later P2QR isogeny stuff, or just no CRQC ever). But these two in particular, I think have a much better chance of happening with P2TRv2 than P2MR, because far more people can just adopt it with low friction.

The future you describe is absolutely plausible, and I would much prefer it, but the steps where the new output type "gets adopted by practically all active users" and where "the community quickly soft forks to disable EC paths/opcodes" are both doing doing a lot of work there. Both are possible, but uncertain, and so we ought to prepare for the alternatives too, right?

-   Isogenies (or something else) get a ton more attention, implementations get more efficient, gain well-studied features like tweaking and homomorphic derivation, get far better confidence in their security.

I hope you'll be as excited I as I am to learn that isogenies already have tweaking/derivation! See my own post here and this paper released just 10 days ago which proves the idea secure.

-   A (not-quite-CR)-QC breaks 128-bit ECDLP, say.

It is a common misconception that we can use toy curves as canaries. Unfortunately we can't trust succinct proofs on small curves because they could be classically forgeable. Pollard-Rho can break ECDLP for points of order n​ with only sqrt(n)​ work today. For example, in 2016 these researchers broke a 117-bit binary-field curve using FPGAs, and this paper's authors broke a 112-bit prime-field curve using a cluster of 200 playstations! 

So how big does a canary curve need to be, to be out of reach of Pollard-Rho but within reach of a fledgling CRQC?

Bitcoin miners are today cumulatively doing about 2^95 work per year measured in SHA256 hashes (source). Pollard-rho work is measured in point additions, which is slower than SHA256, but only by a constant factor.

Thus for a canary to be reasonably safe against large-scale classical attacks triggering a false-positive, we'd need a much larger curve, probably 192 bits or more, for a canary. That's uncomfortably close to the danger zone, especially given the warnings AJ cited, and worse, it would be a moving goalpost as classical parallelized-computing scales up.

Personally, that leaves me at a minimum very skeptical of the utility of introducing either P2MR or P2TRv2 (etc) approaches that don't also introduce a quantum-safe spending path on day one.

Likewise. We don't want people migrating to PQ output types without a PQ spending path. So we wouldn't want to deploy P2MR without a PQ signature scheme to back it up. I hope we'll deploy both upgrades simultaneously in a single soft-fork package. Maybe some time after deployment, we can change mempool relay policy to consider payments to legacy addresses as non-standard, and so further encourage migration without heavy-handed consensus changes like those proposed by BIP361.

Preserving bitcoin as a personally-possessible inflation resistant store of value seems both possible and worth caring about, even if other constraints means that many people can't afford to personally hold it (and have to go through ETFs/exchanges/banks) and that it can't be used for day-to-day transactions. Would be very disappointing if true, and even given Q-day in a few years I expect we could do better than just that, but it doesn't feel like a throw-in-the-towel event to me.

A big +1 from me on this. 

Also remember that even if Bitcoin becomes awkward to use for a few years, we can one day install better cryptography to bring lost features back, improve scaling with discounts or more-efficient signatures, etc. But once UTXOs are lost or stolen, we can never recover them without a contentious ETH-classic-esque hard-fork.

regards,
conduition

--
You received this message because you are subscribed to a topic in the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/p8AVEmAtWdA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ajN9be00Br-O3-9R%40erisian.com.au.

[conduition]

Now I have some points I'd like to respond to about rescue protocols. This is largely tangential to the P2MR/P2TRv2 question.

In either case, I consider anything that requires hardcoding specific wallet designs (BIP32 or otherwise) into Bitcoin's consensus rules (and only allowing those coins to survive) to be squarely in disaster-recovery land. It feels like embracing arbitrariness, and giving up on the permissionlessness that makes Bitcoin interesting

It's fair to say such a solution is arbitrary, insofar as the knowledge asymmetries like BIP32 CKD are arbitrary. But can you propose any alternatives which are not arbitrary?

I would not count hoping for majority migration to be a valid solution. We ought to consider and plan for the contingency that migration to the PQ output type is underwhelming, even if that is not the best outcome, because such an outcome is still likely even if the new output type were magically 10x cheaper and more private than P2TR.

My impression is that your approach is to have an answer for many possible futures, including ones where Q-day arrives within just a few years. But optimizing for disaster-recovery also means reducing the chances of preserving Bitcoin as we know it in the scenarios where a successful migration is still possible. And if Q-day does arrive that soon, I don't see what we can do today that would preserve Bitcoin in a form we care about anyway. By accepting that, we can focus on the futures where our choices today can still materially improve the outcome.

Mostly yes. I gotta agree with AJ's quote here. In chess, one wins by forcing the worst possible outcome to be victory. In probabilistic games, one wins by maximizing the chance of success and minimizing the cost of failure. We should be doing the same thing here.

A quantum "disaster recovery" scenario, as you put it, is absolutely worth optimizing for IMO, because with our current trajectory it seems very plausible, and yet its severe consequences can be mostly mitigated at little cost. I don't think we should abandon such survivable scenarios just because they're less palatable than others.

I dispute that rescue protocols would discourage PQ migration. Quite the opposite: They force PQ migration even for inactive users, by turning vulnerable UTXOs into PQ-safe ones retroactively.

Even if rescue protocols do massively discourage migration to PQ outputs, this would be of little consequence exactly because rescue protocols would exist (which is their beauty). Even in the most extreme case where we deploy a PQ output type and exactly nobody migrates to it, we can still use rescue protocols to achieve the same rate of ownership-preservation as if all quantum-recoverable coins (BIP32, hashed addr, etc) had migrated to PQ outputs immediately. It'll be less efficient and more awkward, but far from hopeless.

Again, the real target demographic that we need to focus on migrating is the quantum unrecoverable subset, i.e. coins which have no quantum-hard knowledge asymmetry, like satoshi's coins, P2PK wallets, and JBOK wallets with exposed pubkeys. If we expect to have rescue protocols, then we don't really care what address format these coins move to, as long as it's to something quantum-recoverable. But convincing them to move at all seems hard, because their owners are probably dead or the keys are lost. How to handle such coins after Q-day is an open question, and it seems to boil down to the good old "freeze-or-steal" debate.

If Q-day comes before migration can reach meaningful levels (what those are is probably a matter of perspective), then I think there isn't much of an interesting future for Bitcoin anyway.

The future is only as interesting as we make it. Even if Q-Day comes before most coins migrate, we have an opportunity to make that future interesting, using rescue protocols. Maybe some folks don't want to work on them or would rather sell their coins first, and that's totally valid, but I implore you to at least keep your mind open to the possible futures that rescue protocols open up, because it is unclear exactly which future we are bound for and I'd rather that neutral internet money still exists in each of them.

We have to play the cards we are dealt, and right now we've been dealt a very fortunate hand because of BIP32 (thanks to you sipa!): Most users have at least some secret knowledge that a CRQC cannot forge, and that's a pretty awesome privilege, one which even extends to other blockchains whose wallets use BIP32, or its derivatives. You should be very proud of that IMO 🙂

Disaster-recovery: neither the "predictable/planned consensus change" of Later nor the "everyone takes responsiblity for their own funds" works, and the only way to avoid a large percentage of bitcoin becoming a reward for quantum research is to replace EC spend paths with a ZK proof of knowledge of a BIP32 seed or similar, requiring a hard fork.

@AJ rescue protocols can be deployed via soft fork, because we'd be constricting rules and not relaxing them. We'd require any EC spends to also satisfy the rescue protocol in addition to the existing consensus rules (signatures etc). Of course, there might be external reasons to deploy it as a hard fork, e.g. to roll back mass theft if we don't time things right, or to disentangle from quantum-theft advocates, but I think we should aim for soft fork compatibility if possible.

the "quantum-safe" hard-fork variant of bitcoin would be fairly described as a utxo-bootstrapped altcoin, would compete in the market with the "quantum-unsafe" bitcoin thatexisting nodes would continue to follow, and possibly there would be many slightly varying such altcoins competing with each other, eg on exactly what height the utxo snapshot was taken or what coins become spendable. It would not be a fun time for holders of affected utxos.

I really hope we do not end up in a situation with competing rescue protocol deployments. I don't think snapshots are necessary so that's not really a factor.

As for the exact conditions which permit rescue... that could indeed get dicey if we need to collate a bunch of different rescue protocols into one Frankensteinian mess. The most popular proposal will probably be one which covers all the most common hard-relations, but this still needs more research.

If we think of rescue protocols more abstractly, the spender just needs to prove their script pubkey commited to a quantum-hard relation, and that the spender knows the witness to that relation. It doesn't actually matter which exact relation - BIP32, hashed address, musig, whatever - just that it's quantum-hard. Maybe there is a way to formulate a two-step proof system general enough to rescue UTXOs with any such relation, by first proving the relation is quantum-hard, then proving you know the witness to the relation. That would be awesome but still an open problem.

regards,
conduition

On Wednesday, June 17th, 2026 at 11:20 PM, Anthony Towns a...@erisian.com.au wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/p8AVEmAtWdA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/ajN9be00Br-O3-9R%40erisian.com.au.