From: Matt Corallo <lf-lists@mattcorallo.com>
To: Ethan Heilman <eth3rs@gmail.com>
Cc: conduition <conduition@proton.me>,
Antoine Poinsot <darosior@protonmail.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] In defense of a PQ output type
Date: Mon, 13 Apr 2026 10:02:10 -0400 [thread overview]
Message-ID: <6d075872-0db8-4e7b-ac2a-452624c991ad@mattcorallo.com> (raw)
In-Reply-To: <CAEM=y+UYBQoocr95ucutw_9QoTuyRcpGPTf_1wgazzK3nbFyyQ@mail.gmail.com>
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.
next prev parent reply other threads:[~2026-04-13 14:23 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 [this message]
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
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=6d075872-0db8-4e7b-ac2a-452624c991ad@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