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 01:45:45 +0000 [thread overview]
Message-ID: <MjCpr-zqQa6GUq9jQH9mWcZ-ClGZ04Q0gCvFRqWt9AOV7fKjSYah5yujwwAFxNkntVooqC_9PyyY9BogZGgt6uQBHO0AGEFGWr_iQnxfbxI=@proton.me> (raw)
In-Reply-To: <6d075872-0db8-4e7b-ac2a-452624c991ad@mattcorallo.com>
[-- Attachment #1.1: Type: text/plain, Size: 9133 bytes --]
Hi Matt,
> Yes, we have to figure out what kind of output type we want, whether P2MR (360), P2TRv2 or just P2TR. There are strong arguments for each. But none of that has any bearing on whether we add hash based signatures to tapscript. We have to add hash based signatures to tapscript first no matter what output type we want!
Apologies, there must be some mixup. I think we agree with each other about this - adding a new PQ opcode to tapscript is always going to be necessary, and our choice of PQ output type doesn't affect that 👍
My earlier clarification was that we must go further: We must add a new output type in order to disentangle opt-in PQC opcodes from any confiscatory soft fork that disables P2TR key-spending. Otherwise, if we only enable the hash-based opcode and do nothing else, then we must disable key spending later or else the opcode is useless.
So the two concepts are not completely independent. Adding hash-based signatures to tapscript necessitates a new opt-in output type that we can standardize quantum-resistant wallets under. Similarly, adding a quantum-resistant output type doesn't seem very useful without a quantum safe way to authorize spending.
=======
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.
> 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].
It is a mistake to compromise on long-term design choices [^2] to please quantum-skeptics, because:
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.
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.
[^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.
On Monday, April 13th, 2026 at 9:23 AM, Matt Corallo <lf-lists@mattcorallo.com> wrote:
>
>
> On 4/10/26 8:20 PM, Ethan Heilman wrote:
> > > IMO even something like P2MR's additional cost will strongly discourage adoption.
> >
> > I don't agree.
> >
> > Over time as quantum attacks become a bigger and bigger concern for holders, wallets will want to
> > show that they can offer security against CRQCs. This is especially true for wallets focused on high
> > value Bitcoin outputs. Even if someone thinks there is only a 2% chance they lose all their Bitcoin
> > because of a quantum computer, that 2% chance will keep them up at night.
> >
> > P2MR would have 17.25 more vBytes, an 11% overhead.
> >
> > P2TR 1 input, 2 output - key path spend. 154 vbytes
> > P2MR 1 input, 2 output - spending a schnorr sig leaf of a P2MR output with two leafs: 1. PQ sig leaf
> > and 2. Schnorr sig leaf. 171.25 vbytes
> >
> > I'm stacking the deck against P2MR here. Under some circumstances P2MR has lower fees than P2TR.
> >
> > It is hard to imagine someone holding significant quantities of Bitcoin not wanting to pay 50
> > sats to ensure their Bitcoin isn't stolen by a quantum computer.
>
> Right, but I think we're focusing on two very different groups. The "holds significant quantities of
> Bitcoin" group I'm much less worried about vs the "holds some quantity of Bitcoin in an average
> consumer Bitcoin wallet". The first group includes institutions, funds, and people relatively "into"
> bitcoin - they're paying attention, (hopefully) using decent wallet software, holding funds in cold
> storage, and aren't fee-sensitive. But this group is going to have no problem migrating no matter
> what the solution is - the institutions and funds camp can migrate in a few days in an urgent
> scenario and the long-term holder with a significant portion of their net-wroth in Bitcoin is also,
> likely, paying reasonably close attention to Bitcoin and can react quickly.
>
> Because those groups are quite capable of reacting quickly, I don't really buy that they're the
> "target market" for short-term PQC in Bitcoin. 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.
> 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. Importantly, the decisions here are made by the developers of
> the software, generally not the actual end users holding Bitcoin.
>
> To put it a different way, the goal of adding PQC to Bitcoin is *not* to "give people an option to
> migrate" but rather to "make use of the PQC scheme the default" across the ecosystem. The former may
> get the migration process started, yes, but it does not ease the future community's difficulties
> materially - the slower-to-migrate coins will still be just as stuck as before and just as much
> Bitcoin will be available to steal by a theoretical CRQC. 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.
>
> Of course that isn't to say that P2MR might not also make sense in addition, but focusing only on
> that misunderstands the goal.
>
> 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/6d075872-0db8-4e7b-ac2a-452624c991ad%40mattcorallo.com.
>
--
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/MjCpr-zqQa6GUq9jQH9mWcZ-ClGZ04Q0gCvFRqWt9AOV7fKjSYah5yujwwAFxNkntVooqC_9PyyY9BogZGgt6uQBHO0AGEFGWr_iQnxfbxI%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 1:52 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 [this message]
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
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='MjCpr-zqQa6GUq9jQH9mWcZ-ClGZ04Q0gCvFRqWt9AOV7fKjSYah5yujwwAFxNkntVooqC_9PyyY9BogZGgt6uQBHO0AGEFGWr_iQnxfbxI=@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