From: Ethan Heilman <eth3rs@gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.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: Wed, 15 Apr 2026 10:36:24 -0400 [thread overview]
Message-ID: <CAEM=y+X7n4iHUHwBEfEggQQeM5FCU2Jt3CFrdZChNd2i3-CgQg@mail.gmail.com> (raw)
In-Reply-To: <3e14b17a-5920-4814-a86d-fca39ad2329e@mattcorallo.com>
[-- Attachment #1: Type: text/plain, Size: 19446 bytes --]
The proposal is P2MR with PQ sigs and no Schnorr address reuse. Address
reuse in this setting should be treated as security vulnerability.
> As such, P2MR with a EC-based key for short-term efficiency reasons has
the same quantum security as P2TR or P2TRv2.
This is incorrect.
1. As long as the Schnorr pubkey has not been leaked by the wallet. The
wallet is PQ safe.
2. Even if the Schnorr pubkey has been leaked by the wallet, if the PQ leaf
hash is not publicly known it is safe against long exposure attacks.
P2TR is **always** vulnerable to short and long exposure attacks. There is
no better wallet hygiene that can fix this.
You are comparing:
P2MR + PQ signatures: A wallet messing up their implementation of PQ safe
transactions and introducing a vulnerability and weakening a subset of
outputs. If implemented correctly 100% of the outputs are safe.
vs.
P2TR: A design where 100% of outputs are vulnerable even if the
implementation is perfect.
These aren't the same thing at all, nor do they provide the same security.
On Wed, Apr 15, 2026, 07:02 Matt Corallo <lf-lists@mattcorallo.com> wrote:
> Oh, apologies, I was in a bit of a rush yesterday and forgot the most
> important reason why P2MR
> doesn't help at all - address reuse.
>
> In practice the "long tail" of Bitcoin wallets (which, as noted below are
> most of what we care
> about) do strict address reuse. Mostly a consequence of address-based
> blockchain systems its become
> an expected feature that the address displayed in a wallet is static and
> does not change. As such,
> P2MR with a EC-based key for short-term efficiency reasons has the same
> quantum security as P2TR or
> P2TRv2.
>
> Matt
>
> On 4/14/26 4:04 PM, Matt Corallo wrote:
> > I'm gonna top-post because I think we're too far in the weeds and the
> high-level argument is getting
> > lost. No, of course I do not thing that our job is to "convince" any
> quantum skeptics. What is our
> > job is making sure the *bitcoin system* is ready in case a CRQC does
> become a reality. That means
> > looking at the system as a whole, not individuals. Notably, this means
> that if the decisions we make
> > result in a bitcoin where some people who are super worried about a CRQC
> have migrated but everyone
> > else hasn't, and a CRQC becomes an imminent reality, *we've failed*. In
> such a world, bitcoin
> > becomes largely value-less and the paranoid folks who migrated long ago
> and paid for it have
> > accomplished absolutely nothing. I hope we can at least agree on this
> point.
> >
> > On 4/14/26 2:56 PM, conduition wrote:
> >> 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.
> >
> > Yes, exactly.
> >
> >> 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.
> >
> > This assumes a CRQC.
> >
> >> - P2MR does not commit us to carrying legacy crypto cruft past its
> shelf-life.
> >
> > Nor does P2TRv2? No one is suggesting P2TRv2 becomes some standard that
> all wallets use forever. No
> > matter what we do we carry the "cruft" of P2TR in Bitcoin forever (+/-),
> P2TRv2 has literally zero
> > additional cruft.
> >
> >> - P2MR and P2TRv2 are both equivalent to quantum-skeptics, who have no
> incentive to migrate either
> >> way.
> >
> > See below
> >
> >> - 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.
> >
> > I disagree very strongly with this. This would be true if everyone had
> their own custom-built wallet
> > that they designed to meet their goals exactly. In the real world people
> pick wallets based on many
> > other factors, and developers build wallets for many different users,
> some of which may be fee
> > sensitive and some of which may not be, all of whom will use the same
> default configuration.
> >
> >> - P2MR has utility even if Q-day never comes.
> >
> > I disagree. The overall utility to the Bitcoin system of something like
> P2TR is also the global
> > default that is strongly baked in which results in
> >
> >> - 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.
> >
> > I don't see how this is true in practice. Maybe in a world where
> everyone uses P2MR with a single
> > left-hand leaf at depth one with a single EC schnorr key which is
> musig2, but....come on. The value
> > of taproot is that its design natively adds this *for free* to every
> contracting protocol, and not
> > only adds it for free but *forces* every contracting protocol to carry
> at least some of the cost if
> > they decline to do this. This results in a massive net privacy win
> across the entire Bitcoin
> > ecosystem, and I don't see how you can argue that these things are
> equivalent in practice, just
> > because they could in theory be used in a way where they are in theory.
> >
> >> 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.
> >
> > Not only do I disagree with most of your points here, but I disagree
> that we should be optimizing
> > for a "long-term design" which we intend to be *the* design we use in
> the face of an imminent CRQC.
> > We already know we're not doing that - we're not using lattices or
> isogenies or whatever we'll
> > actually end up using because those things aren't ready. They likely
> will be by the time a CQRC is
> > imminent. If they aren't, we'll almost certainly be back to the drawing
> board on witness discounts
> > and whatever else which will mandate a new address format anyway. There
> is basically zero chance
> > that whatever we do today will be what we end up using "normally" in a
> world with a CRQC.
> >
> >>> 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.
> >
> > I don't think this is "very specific" at all? In fact I think this is
> the *dominant* case. By coin
> > volume, yes, the biggest wallet is Coinbase's custody product. By wallet
> count, the biggest wallet
> > is probably something like Trust Wallet. Its trash, doesn't care about
> Bitcoin, makes many terrible
> > design decisions which are actively hostile to its users, and yet they
> are the ones who actually
> > decide in what way most bitcoin are stored! I don't know what their
> particular view on quantum is,
> > but my sense of most developers is that the view is generally "well,
> it'll happen at some point, but
> > its not totally urgent". Meanwhile, people are almost without question
> going to nag some wallets for
> > "quantum security" once its a thing.
> >
> > You might reasonably disagree with whether they would implement P2TRv2
> vs P2MR, I think its
> > definitely a subtle argument, but I don't think you can reasonably
> disagree that these are exactly
> > the most important constituent here.
> >
> > > 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.
> >
> > It is far from only "pre-quantum fee-effeciency", its also the value for
> the entire Bitcoin system
> > of the privacy taproot offers. But I think the more important argument
> specifically here is the
> > question of what they will make the *default*. In a world with P2MR I
> could absolutely see them
> > implementing a P2MR option which you can opt into in the settings. That
> fails to accomplish our
> > goals entirely. Maybe they also would do the same for P2TR/P2TRv2, but I
> at least think that's
> > somewhat less likely, but in any case better for the bitcoin system
> overall if that's where we land.
> >
> >> 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.
> >
> > See intro. I don't really see how you can reasonably conclude that our
> goal is only to enable a
> > small subset of people to migrate. That way leas only to a total failure
> of the bitcoin system.
> >
> >>> 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.
> >
> > Yes, we probably would. Not because of efficiency but because a goal of
> taproot is *privacy* while
> > offering efficiency for the common (all-sign) case. That is generally
> true across contracting
> > protocols and makes things net-cheaper with a taproot-style system where
> you hit the common case
> > often. This is another reason why P2MR is quite a loss -
> >
> >> 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.
> >
> > As mentioned above if we end up in this situation we're almost certainly
> going to be discussing a
> > P2MRv2 with an additional witness discount, so...
> >
> >>> 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 :)
> >
> > This is fair, and we should do this too, but I don't see how it implies
> we should not also be
> > concerned with ensuring maximum possible migration.
> >
> >
> >> 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.
> >
> > Fair enough. I continue to think we're talking past each other somewhat
> but ultimately I think my
> > concern is for ensuring bitcoin survives, while you're more concerned
> with giving those who are
> > concerned an option to feel warm and fuzzy :).
> >
> >> As to the original subject of the email thread, and Antoine's original
> points, seems like we are
> >> all in agreement.
> > Indeed.
> >
>
>
--
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/CAEM%3Dy%2BX7n4iHUHwBEfEggQQeM5FCU2Jt3CFrdZChNd2i3-CgQg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 22882 bytes --]
next prev parent reply other threads:[~2026-04-15 15:22 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
2026-04-14 20:04 ` Matt Corallo
2026-04-15 11:02 ` Matt Corallo
2026-04-15 14:36 ` Ethan Heilman [this message]
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='CAEM=y+X7n4iHUHwBEfEggQQeM5FCU2Jt3CFrdZChNd2i3-CgQg@mail.gmail.com' \
--to=eth3rs@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--cc=darosior@protonmail.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