From: Matt Corallo <lf-lists@mattcorallo.com>
To: conduition <conduition@proton.me>
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 11:33:02 -0400 [thread overview]
Message-ID: <42806684-3cc4-42e2-8052-43288a93e91e@mattcorallo.com> (raw)
In-Reply-To: <MjCpr-zqQa6GUq9jQH9mWcZ-ClGZ04Q0gCvFRqWt9AOV7fKjSYah5yujwwAFxNkntVooqC_9PyyY9BogZGgt6uQBHO0AGEFGWr_iQnxfbxI=@proton.me>
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/42806684-3cc4-42e2-8052-43288a93e91e%40mattcorallo.com.
next prev parent reply other threads:[~2026-04-14 15:54 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 [this message]
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=42806684-3cc4-42e2-8052-43288a93e91e@mattcorallo.com \
--to=lf-lists@mattcorallo.com \
--cc=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--cc=darosior@protonmail.com \
--cc=eth3rs@gmail.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