From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Ethan Heilman <eth3rs@gmail.com>,
Antoine Poinsot <darosior@protonmail.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] In defense of a PQ output type
Date: Tue, 14 Apr 2026 18:56:30 +0000 [thread overview]
Message-ID: <FK4r4I9x1v2s7NWZWm26e7rhmove8ckpdjJ4l6hwhpEomvIHxqVFgFws5ElDhIBnhaALGfTqaAj2NchrX0T8i4vYvUuxyh19sPmcrqG_Sy8=@proton.me> (raw)
In-Reply-To: <42806684-3cc4-42e2-8052-43288a93e91e@mattcorallo.com>
[-- Attachment #1.1: Type: text/plain, Size: 18030 bytes --]
Hi Matt,
> Right but you didn't contend with my point at all, only ignored it. Its great that you can move your coins into something so that your coins aren't stolen but...who cares? If a huge % of outstanding bitcoin supply is being stolen that impacts you just as much as if your own coins were being stolen!
I don't think I ignored anything, but maybe I just didn't understand your point.
To me, your point seems to be (I'm summarizing here) that "Nobody will migrate to P2MR before Q-day because it is slightly worse than P2TR until Q-day". And your conclusion is, in your own words:
> Thus, ISTM the focus *has* to be on something that has minimal drawbacks - not losing the script policy privacy of P2TR, low or no fee overhead, etc.
This seems to imply you're arguing that at least some of those same people (who wouldn't use P2MR) WOULD migrate to P2TRv2, because it is exactly as good as P2TR until Q-Day.
I respectfully disagree with this argument, and I gave my reasoning as to why in my last reply. To review:
- P2MR is quantum-secure by default.
- P2MR is more efficient long-term.
- P2MR does not commit us to carrying legacy crypto cruft past its shelf-life.
- P2MR and P2TRv2 are both equivalent to quantum-skeptics, who have no incentive to migrate either way.
- The short-term efficiency difference in P2MR and P2TRv2 is a negligible trade-off to anyone who ISN'T a total quantum-skeptic.
- Fee-sensitive users are online and adaptive, and can use P2TR until Q-day; They do not need P2TRv2 any more than fee-insensitive users.
- P2MR has utility even if Q-day never comes.
- Also, I failed to make this point in my last reply: P2MR and P2TRv2 have the same privacy profile AFAICT, assuming both commit to a hash-based fallback leaf script.
Therefore, P2MR is the better long-term choice.
If we assume Bitcoin will survive long into the future after CRQCs appear, then we should favor the best long-term design choices over short-term compromises. Thus, we should deploy P2MR and NOT deploy P2TRv2.
> But what about someone who sees quantum computers as 90% FUD that might happen eventually but won't for 50 years but still gets users nagging them about it and support for importing some new seedphrase format that derives a SHRINCS key in addition to the EC ones? That's much less of a straw man and way more realistic - and also a place where someone might do the work (or, well, merge a PR if its done for them) but probably won't if they're building a consumer wallet that is used by some to transact regularly (but, let's face it, used primarily by some people who put some money in and then forgot about it for five years).
Very specific. You're talking about wallet developers here, right? Exchanges? Bitcoin businesses in general etc? And you're saying that the people running these businesses and building the wallets - those who are being "nagged" to implement something that the rest of the cryptographic world has already starting rolling out in production [1] - You're saying that a subclass of these people - those who are "mostly" skeptical of quantum hype - WOULD implement P2TRv2, but WOULDN'T implement P2MR?
It's debatable how big that subclass would be, especially given the current landscape. But even if one confidently sees CRQCs as 50 years away, then I'd refer back to my earlier response, and argue that any such skeptical developer has no reason to implement either P2MR or P2TRv2 today, apart from compatibility with other software which DOES implement them. If "nagging" is the only motivation a dev or business owner has to implement a PQ output type, then one need not distinguish between the two. They'd just implement whatever is standardized to please their users, and carry on with their day.
If I'm being a little more realistic, most wallet devs will follow whatever is standardized just to get more market share. I somehow doubt devs will turn up their noses and say "it's not efficient enough, I won't implement that even if a large chunk of my customers are clamoring for it."
I think this reveals the source of our disagreement. In your arguments, you are placing a lot of weight on the importance of pre-quantum fee-efficiency in the new output type, so much so that you seem to think devs would willingly ignore a potential existential threat to save users a few sats per transaction.
But maybe look at it this way:
- Whether quantum computers are 5, 10, 50 years or more away, anyone who truly cares about a few extra sats per TX can continue to use P2TR when actively transacting pre-Q-Day, and use P2MR for high-security cold storage. The result is mostly the same as if we deployed P2TRv2. Yes, there is some risk of being caught with your pants down on Q-day, but the same is true of P2TRv2 because we might not time the key-spend disabling follow-up fork correctly.
- Mining fees are a part of everyday life for Bitcoiners, and the pre-quantum fee difference between P2TR and P2MR is NOTHING compared to the fee spike we'll all have to endure after Q-day, no matter what fancy cryptography we may end up using by then. There are far more important things we can optimize.
> Again, you ignore that the impact is global, not local. Yes, quantum-skeptics have to be brought along over time if you want to have any hope of bitcoin actually being relevant.
Our job is not to proselytize and convince people that the quantum threat is real, nor is it even to encourage migration by design. Our job is to prepare an optimal migration path in case the threat is real. If CRQCs do appear, everyone will want to migrate to PQC sooner or later. If they do not, everyone moves on with their lives and the new output type becomes a relic (in P2MR's case, an occasionally useful one).
Even if you feel your job IS to convince and migrate as many users as possible, I would argue it'll be hard to convince anyone to migrate to an address format that isn't PQ-safe by default. Bitcoiners trust code, not promises, and P2TRv2 is only PQ-safe if you trust its promise of a future soft fork, while its code would be PQ-vulnerable by default. And the only benefit to accepting this risk seems to be a trivial discount in fees pre-Q-day. I don't speak for everyone of course, but personally I'd rather keep my cold-storage coins on a P2WSH address than on P2TRv2, because at least then I know for sure a CRQC will have a hard time stealing my coins regardless of what upgrades the community does or doesn't deploy in the future.
> Sure, but any short term hash-based signature migration path is really not intended as the final state anyway - if Bitcoin is stuck with only hash based signatures and a CRQC exists in 20 years that's a pretty terrible outcome. Hopefully by the time a CRQC becomes a real threat we have much more confidence in lattice-based systems (or whatever PQC is popular then) and we can add whatever output type makes sense at that point.
I agree about hash-based sigs not being the endgame. Though, this doesn't mean P2MR isn't. We're talking about output types here, not opcodes. I would argue P2MR remains useful regardless of the cryptography we use: lattice, isogeny, hash-based, multivariate, whatever. Merkle trees have been around for almost 50 years and seem hard to beat.
For instance, we could reconstruct P2TR using isogenies [2], but would we really want to? Using today's witness discount levels, it would actually be MORE efficient overall to spend with SQIsign inside a P2MR tree, than it would be to use SQIsign to key-spend with some hypothetical "Pay-to-supersingular-curve" output type [^3]. I realize I'm kinda trashing my own research by saying this, but it shows how hard it is to beat P2MR, even if you can accept new cryptographic assumptions and the accompanying performance penalties.
Even if we do someday find some novel cryptosystem which permits rerandomization, and we design a new output type as efficient and performant as P2TR but in a post-quantum context, is the systemic risk really worth saving a few vbytes - a small fraction of the entire witness? If so, how many decades or centuries need to pass for everyone else to share that confidence?
Personally I think we should learn our lesson from this P2TR debacle, and encourage users to hide public keys behind hash functions from now on, and to bolster riskier algorithms with hash-based fallback keys, so that we always have at least one layer of protection between keys and any novel cryptanalytic breakthroughs. Posting our plain pubkeys on-chain does sometimes have fun benefits, but the drawbacks are deadly serious.
Until SHA256 collision resistance is broken, I'd expect P2MR is probably the pinnacle of secure PQ address formats, and even then we'd probably end up reimplementing P2MR with some newer hash function. Hopefully someday someone proves me wrong, but we can only engineer with what we know today, and today P2MR seems the most optimal conservative option for long-term security and cryptographic agility.
> And with them they will take bitcoin's value...
If you're really worried about a supply glut caused by CRQCs stealing and dumping them, then debating about P2TRv2 and P2MR is a distraction. IMO, most coins will probably not migrate before Q-Day regardless of what output types we deploy, because many coins are held by dead hands, or by living hands who just don't read the news.
If this concerns you (and it concerns me too), then saving a few vbytes per spend pre-Q-day is trivial by comparison, and optimizing it will make little impact on the integrity of the UTXO set after Q-day. I would instead suggest you pursue the retroactive area of research (rescue protocols, quantum canaries, hourglass, exposure statistics, etc). This is a domain where real impact can be made to mitigate the risk of a supply glut when/if CRQCs appear. Opportunities abound. We would be glad of the help :)
========
Anyways, I appreciate the good-spirited debate, but to save myself time I don't think I'll continue replying. I've laid out my argument for P2MR pretty clearly and I feel it is as convincing as I can make it. I'd be happy to acknowledge any misunderstanding I may have had about your earlier points in favor of P2TRv2.
As to the original subject of the email thread, and Antoine's original points, seems like we are all in agreement.
regards,
conduition
[1]: https://blog.cloudflare.com/pq-2025/
[2]: https://conduition.io/cryptography/isogenies-intro/
[^3]: SQIsign signatures are 148 bytes, pubkeys are 65 bytes. Situation 1, key-spending P2SC: a 65 byte pubkey goes on-chain in a witness program, and the spender provides a 148 byte signature in the witness. Total weight: 65*4 + 148 = 408, AKA 102 vbytes. Situation 2, script-spending with P2MR: a 32 byte merkle root goes on-chain in a witness program, and the spender provides a 67 byte script (65 byte pubkey + 2 bytes of script), a 32-byte merkle node (for alternative script spend paths), and a 148 byte signature in the witness. Total weight: 32*4 + 67 + 32 + 148 = 375 = 93.75 vbytes. Notice in situation 1 the user who creates the output actually pays MORE in fees than user who spends the output.
Smart business owners listen to what the market demands, and leave their personal opinions at the door. If the market demands they add quantum-safe addresses, they'll do it sooner or later.
This... seems like a lot of "what-if". I think it maybe reveals the source of our disagreement. In your arguments, you are placing a lot of weight on the importance of pre-quantum fee-efficiency, whereas in my arguments, I am placing more weight on conclusive quantum-security and long-term fee-efficiency.
On Tuesday, April 14th, 2026 at 10:33 AM, Matt Corallo <lf-lists@mattcorallo.com> wrote:
>
>
> On 4/13/26 9:45 PM, conduition wrote:
> > =======
> >
> > At the risk of this thread further devolving into a debate around P2MR and P2TRv2...
> >
> >> Our goal is to get as many wallets migrated as possible, which really means focusing on the wallets that are likely to take the longest to migrate.
> >
> > I can't speak for others, but my goal is to design and deploy a secure and efficient soft-fork upgrade package so that myself and other bitcoin users may retain control of our bitcoins in a world where the future security of the ECDLP is uncertain. Encouraging adoption is a secondary goal which follows immediately if we design the upgrade well.
> >
> > I personally don't see P2TRv2 as a suitable path towards this goal, because it still depends on ECDLP. At best, P2TRv2 PROMISES to be quantum-secure later, at the chaotic whim of the future Bitcoin community. Personally, I would rather keep my coins on P2WPKH than on P2TRv2. No: If we are going to have a PQ soft fork, it should be conclusive, self-contained, and require no follow up. Otherwise, we haven't actually fixed the core uncertainty we need to address.
>
> Right but you didn't contend with my point at all, only ignored it. Its great that you can move your
> coins into something so that your coins aren't stolen but...who cares? If a huge % of outstanding
> bitcoin supply is being stolen that impacts you just as much as if your own coins were being stolen!
> Pieter put this very well in his "The limitations of cryptographic agility in Bitcoin" thread.
>
> >> That includes both "consumer" wallets which may be infrequently used by people who bought a pile of bitcoin and touch it once every few years as well as those who are quantum-skeptical and will see no reason to upgrade until its urgent.
> >
> > Low-frequency users aren't fee sensitive, almost by definition, so I don't see them caring much about the minor witness size increase of P2MR compared to P2TR.
> >
> > As for quantum-skeptical users, I see no reason why they would migrate their coins to ANY quantum-resistant output type, whether P2TRv2 or P2MR. To someone who today sees quantum computers as 100% FUD with zero room for doubt, they will see any PQ output type as a slightly worse version of whatever they use today. So I don't really understand why it would be so important to encourage this class of user to migrate. They won't - not until their world-view about the quantum threat changes.
> >
> > If and when their attitude does change, then a few vbytes of overhead compared to P2TR won't deter them - not with an existential threat motivating them to migrate. If fees DO deter them, then they're probably an active high-frequency user like a miner or exchange, who can keep tabs on the situation and continue to grind savings out of P2TR until the very last minute [^1].
>
> But what about someone who sees quantum computers as 90% FUD that might happen eventually but won't
> for 50 years but still gets users nagging them about it and support for importing some new
> seedphrase format that derives a SHRINCS key in addition to the EC ones? That's much less of a straw
> man and way more realistic - and also a place where someone might do the work (or, well, merge a PR
> if its done for them) but probably won't if they're building a consumer wallet that is used by some
> to transact regularly (but, let's face it, used primarily by some people who put some money in and
> then forgot about it for five years).
>
> > It is a mistake to compromise on long-term design choices [^2] to please quantum-skeptics, because:
>
> Again, you ignore that the impact is global, not local. Yes, quantum-skeptics have to be brought
> along over time if you want to have any hope of bitcoin actually being relevant.
>
> > 1. If the quantum threat is indeed real, then sooner or later, whether by theft or migration, this class of bitcoin user will no longer exist.
>
> And with them they will take bitcoin's value...
>
> > 2. On the other hand, if CRQCs turn out to be not-so-relevant after all, then everyone becomes a quantum-skeptic, and we can all return to P2TR while the new PQ output type slowly fades into obscurity.
> >
> > Note in scenario (2), P2MR actually still has utility: P2MR can be used as a more-efficient way to construct script-path-only addresses, without the need to commit to a NUMS point. P2TRv2 has no such secondary utility.
> >
> > regards,
> > conduition
> >
> >
> > [^1]: By the way Matt, I think it's a mistake to assume that large corporate users are not fee-sensitive. If anything they are more fee-sensitive than Joe-Average - When you conduct thousands of transactions per day, 10% larger witnesses could mean a lot.
>
> Sure, their hot wallet that is probably true, but also not super interesting - they can/will migrate
> their hot wallet over the course of an hour if/when Q-day starts to be a real threat.
>
> > [^2]: P2TRv2 is a compromise in the long-term compared to P2MR, because after key-spending is disabled, P2TRv2 is strictly worse than P2MR: It would have worse performance and larger witnesses, more cryptographic complexity, and it commits us to carry legacy ECC as cruft well into the future.
>
> Sure, but any short term hash-based signature migration path is really not intended as the final
> state anyway - if Bitcoin is stuck with only hash based signatures and a CRQC exists in 20 years
> that's a pretty terrible outcome. Hopefully by the time a CRQC becomes a real threat we have much
> more confidence in lattice-based systems (or whatever PQC is popular then) and we can add whatever
> output type makes sense at that point.
>
> Matt
>
--
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/FK4r4I9x1v2s7NWZWm26e7rhmove8ckpdjJ4l6hwhpEomvIHxqVFgFws5ElDhIBnhaALGfTqaAj2NchrX0T8i4vYvUuxyh19sPmcrqG_Sy8%3D%40proton.me.
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
next prev parent reply other threads:[~2026-04-14 19:02 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-09 18:58 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-04-09 20:31 ` [bitcoindev] " Dplusplus
2026-04-09 21:17 ` [bitcoindev] " Olaoluwa Osuntokun
2026-04-09 22:46 ` Matt Corallo
2026-04-10 17:03 ` 'conduition' via Bitcoin Development Mailing List
2026-04-10 20:33 ` Matt Corallo
2026-04-11 0:20 ` Ethan Heilman
2026-04-11 1:04 ` 'Hayashi' via Bitcoin Development Mailing List
2026-04-11 1:25 ` Antoine Riard
2026-04-13 14:21 ` 'Hayashi' via Bitcoin Development Mailing List
2026-04-15 19:05 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-04-15 19:14 ` Erik Aronesty
2026-04-15 20:16 ` محمد الوصابي
2026-04-13 14:02 ` Matt Corallo
2026-04-14 1:45 ` 'conduition' via Bitcoin Development Mailing List
2026-04-14 12:36 ` Thomas Suau
2026-04-14 14:51 ` 'conduition' via Bitcoin Development Mailing List
2026-04-14 15:50 ` thomas suau
2026-04-14 19:09 ` 'conduition' via Bitcoin Development Mailing List
2026-04-14 15:33 ` Matt Corallo
2026-04-14 18:56 ` 'conduition' via Bitcoin Development Mailing List [this message]
2026-04-14 20:04 ` Matt Corallo
2026-04-15 11:02 ` Matt Corallo
2026-04-15 14:36 ` Ethan Heilman
2026-04-15 15:17 ` Matt Corallo
2026-04-15 16:01 ` Ethan Heilman
2026-04-15 16:03 ` Matt Corallo
2026-04-15 16:26 ` Ethan Heilman
2026-04-15 16:36 ` Matt Corallo
2026-04-15 20:19 ` Anthony Towns
2026-04-15 21:50 ` Matt Corallo
2026-04-15 23:30 ` Anthony Towns
2026-04-16 11:15 ` Matt Corallo
2026-04-16 11:19 ` Garlo Nicon
2026-04-15 18:15 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
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='FK4r4I9x1v2s7NWZWm26e7rhmove8ckpdjJ4l6hwhpEomvIHxqVFgFws5ElDhIBnhaALGfTqaAj2NchrX0T8i4vYvUuxyh19sPmcrqG_Sy8=@proton.me' \
--to=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--cc=darosior@protonmail.com \
--cc=eth3rs@gmail.com \
--cc=lf-lists@mattcorallo.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