From: Pieter Wuille <bitcoin-dev@wuille.net>
To: conduition <conduition@proton.me>
Cc: Antoine Poinsot <darosior@protonmail.com>,
"bitcoindev@googlegroups.com" <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Aligning privacy incentives in P2MR
Date: Tue, 16 Jun 2026 20:09:08 +0000 [thread overview]
Message-ID: <81QWqov2xqthGLjORSKtR2jDDosHG7gjK91LNQ61iIBNRQaJPsu6wTA63d3KjVdROO2VZy5zr3Buo5A8UXb3Ue5E4zc2qWYn65gRxmmFLKg=@wuille.net> (raw)
In-Reply-To: <E2-B_JaZeZg3tFHhiGcp-Mitl34-_uxcTVga5ogSMKOfeCvjHuzox7EXNw6GdlC4ggEIehP2elA3xnmvBSvIMnNu-QSHqGW81MzvD8BKRRI=@proton.me>
[-- Attachment #1: Type: text/plain, Size: 20007 bytes --]
Thanks for the comments, conduition,
See my responses inline below.
On Friday, June 12th, 2026 at 12:43 AM, conduition <conduition@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:
- 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.
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](https://jbonneau.com/doc/BM14-SPW-fawkescoin.pdf). 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
--
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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/81QWqov2xqthGLjORSKtR2jDDosHG7gjK91LNQ61iIBNRQaJPsu6wTA63d3KjVdROO2VZy5zr3Buo5A8UXb3Ue5E4zc2qWYn65gRxmmFLKg%3D%40wuille.net.
[-- Attachment #2: Type: text/html, Size: 30855 bytes --]
next prev parent reply other threads:[~2026-06-16 20:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-03 23:12 [bitcoindev] Aligning privacy incentives in P2MR 'conduition' via Bitcoin Development Mailing List
2026-06-05 19:56 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-06-05 22:52 ` 'conduition' via Bitcoin Development Mailing List
2026-06-06 4:29 ` Pieter Wuille
2026-06-06 19:33 ` 'conduition' via Bitcoin Development Mailing List
2026-06-10 3:00 ` Pieter Wuille
2026-06-12 4:43 ` 'conduition' via Bitcoin Development Mailing List
2026-06-16 20:09 ` Pieter Wuille [this message]
2026-06-18 5:09 ` Anthony Towns
2026-06-19 0:30 ` 'conduition' via Bitcoin Development Mailing List
2026-06-19 0:38 ` 'conduition' via Bitcoin Development Mailing List
2026-06-06 22:12 ` Boris Nagaev
2026-06-06 17:52 ` 'Hayashi' via Bitcoin Development Mailing List
2026-06-13 15:33 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
[not found] <Q8YTY1ArMzia7tRvcZ5v769WPxCMxAl=5F0rUy-byOBjBcTd4HXj7IB7Yt4gxLbKqk7EXFWy-PuGB6QtI28qRjE5Vob-l44UmBH6L8aXInoSk=3D@proton.me>
[not found] ` <xDZdaNASwweJSIjFLVJidZYfsMsle8RuX0G74BWggmIBRZaMgUaPjJLtj5s6BRNr1XObrie1JV7dQ8w6h9h=5FhyBPOEnydBc2F9kCsEmDE80=3D@protonmail.com>
[not found] ` <doSPUSJvChwux9prI1puFj9OMI=5FZeCeIEb1KKhnlp6G=5FwnpkvZmo3FZvvMRvaLAhzQFF2NS1Ad1tHDWfnmf6ytLI7oMotciw64hUZkHoI68=3D@proton.me>
[not found] ` <sHzHpzprjPTKHmfSy0Oes6FGD1nd=5FM36z2SiY3LDHmh3dI2YQWSfy-Xu4cZDe9nbEgihL0o9yZN7PEx6=5FrsEyPTcX-nJOTtiM2DX8SVOES4=3D@wuille.net>
[not found] ` <jVpYczjMUwILN76cjc9LSoXttkuOrkClgAX6gwtlQ4-lVEcGFKD8tEp72zhTCzCqmOdyrkyuoyGF2DA-p5WebDgmgXyAGpBnH6mYRGvl1-I=3D@proton.me>
[not found] ` <=5Fz6=5FJUmphCkUYvI6gemSFMD9Sb=5FrDL03IQbtZQCNlk6pmioGEQBir=5FgMyZCfticFa8Ttfc0xoFHdxR07=5FMNuAfBu8do=5Fh5IDf2apVk1w1BM=3D@wuille.net>
[not found] ` <E2-B=5FJaZeZg3tFHhiGcp-Mitl34-=5FuxcTVga5ogSMKOfeCvjHuzox7EXNw6GdlC4ggEIehP2elA3xnmvBSvIMnNu-QSHqGW81MzvD8BKRRI=3D@proton.me>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='81QWqov2xqthGLjORSKtR2jDDosHG7gjK91LNQ61iIBNRQaJPsu6wTA63d3KjVdROO2VZy5zr3Buo5A8UXb3Ue5E4zc2qWYn65gRxmmFLKg=@wuille.net' \
--to=bitcoin-dev@wuille.net \
--cc=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--cc=darosior@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox