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