From: Matt Corallo <lf-lists@mattcorallo.com>
To: conduition <conduition@proton.me>
Cc: Ethan Heilman <eth3rs@gmail.com>, bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] PQC - What is our Goal, Even?
Date: Sun, 19 Apr 2026 12:37:32 -0400 [thread overview]
Message-ID: <71374026-6365-45fa-8168-ff1c8cb83dc9@mattcorallo.com> (raw)
In-Reply-To: <MPXPgim-vthykBFwesBlyBfxPxeE9SVEulMF_EmwSp8GB4lZQLzdFu5QCTPpYwX1O-T8ZWqqIQiRwBdw4frjnDH9JzBaRx2cnoS40MUhGAw=@proton.me>
On 4/19/26 12:27 PM, conduition wrote:
> Hi Matt, thanks for elaborating. But I think you didn't address the overall point of my last email, which is that address reuse is a null argument in the P2MR vs P2TRv2 debate.
>
> What difference does it make if wallets use P2MR or P2TRv2 when they reuse addresses? EC pubkeys are exposed on-chain either way. The only diff is that in reused-P2MR, EC pubkeys are exposed slightly later at spend time, rather than at receive time.
>
> Even if you take the highly pessimistic view that 100% of P2MR usage will always be through reused addresses, then those coins would be no more secure in P2TRv2 than they were in P2MR. To protect coins in this context, an EC restriction is needed either way, and that can be applied equally to either P2MR or P2TRv2.
Correct, I did not address the question of "why is P2TRv2 better", I was highlighting that I don't
think, from a "quantum security" point of view, P2MR is any *different*. If I read your email right
you were suggesting that both P2MR and P2TRv2 are equivalent in a "many reused addresses" case, but
also claiming that because some addresses are not reused P2MR should be preferable because at least
"the people who did it right" retain ownership of their coins. I reject that view entirely.
I believe I've mentioned in previous mails that I think P2TRv2 is better than P2MR, if only
marginally, in a world where they're equivalent from a "quantum security" PoV - P2TRv2 might retain
somewhat more script privacy, is marginally more efficient, and trivially retains (what exists of)
existing taproot wallet implementation, rather than requiring more engineering build-out.
In the extreme, the "well you were using it wrong" responses to address reuse in P2MR that have
already cropped up might reduce the likelihood of saving the coins of wallets that have reused
addresses, which is also a negative, but maybe you could argue that they're equivalent by having an
updated BIP spell it out.
>> I think the gap between our views is that I don't buy that the "percentage harm reduction" outcome is all that interesting. Sure, there's some % where it certainly is, but its probably in the 99+% range, not in the 75-90% range. I think maybe the biggest gap is I just don't find any "solution" that results in 10-20% of bitcoin (*especially* active bitcoin people hold keys to that made some progress in migrating but maybe screwed up address reuse) being stolen as at all interesting. If we manage to get 90% of active coins secured and then 10-20% of active wallets get some of their funds stolen, have we actually accomplished something grand, or is Bitcoin's reputation so shot that we might as well pack it up and go work on some new fresh chain that is PQC from day one? I'm fairly confident the answer is the second, not just in that "we"'ve failed, but that the market will see it the same way.
>
> Am I reading this right? You think it'd be better to abandon the entire chain if a CRQC can steal more than 10% of the active coin supply? That's a bleak outlook. I hope you change your mind on this. I hope even more that we can prevent such theft from happening in the first place. But again, debating P2TRv2 and P2MR is irrelevant to that goal if you assume address reuse will be rampant and exploitable.
Yes, you are reading me right. I genuinely don't see why we should care about a bitcoin if some
nontrivial portion of wallets *that "upgraded" to be quantum-secure* get their funds stolen by a
quantum computer. The amount of reputational damage from this isn't trivial, but maybe more
importantly what on earth do we think the point of bitcoin is if its genuinely that hard to secure?
>> In a world where there's material address reuse, and those folks are using P2MR, suddenly it becomes "their fault" for "using it wrong" (even in cases when it isn't).
>
> People will blame whoever they like. Our concern isn't to direct the blame for theft correctly; Our concern is to reduce theft by deploying the right upgrades. If CRQCs become a threat and too many pubkeys are exposed, we deploy a restriction on EC spending. If we can do that on P2TRv2, we can do it on P2MR too.
>
>> On address reuse, as far as I'm aware, its driven by at least three factors
>
> All address reuse scenarios, including the examples you gave, can be protected by restricting EC spending regardless of whether we deploy P2MR or P2TRv2 as a first step.
Sure, my point was only that they're totally equivalent, and thus we should consider the decision
based on other factors.
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/71374026-6365-45fa-8168-ff1c8cb83dc9%40mattcorallo.com.
next prev parent reply other threads:[~2026-04-19 17:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 16:37 Matt Corallo
2026-04-15 18:08 ` Erik Aronesty
2026-04-16 11:17 ` Matt Corallo
2026-04-16 16:28 ` Erik Aronesty
2026-04-16 16:31 ` Erik Aronesty
2026-04-16 17:34 ` 'conduition' via Bitcoin Development Mailing List
2026-04-17 20:44 ` Matt Corallo
2026-04-17 21:28 ` Ethan Heilman
2026-04-18 0:37 ` Matt Corallo
2026-04-18 15:44 ` 'conduition' via Bitcoin Development Mailing List
2026-04-18 16:34 ` Erik Aronesty
2026-04-19 0:29 ` Matt Corallo
2026-04-19 12:57 ` Erik Aronesty
2026-04-19 13:36 ` Matt Corallo
2026-04-19 16:27 ` 'conduition' via Bitcoin Development Mailing List
2026-04-19 16:37 ` Matt Corallo [this message]
2026-04-19 19:43 ` Matt Corallo
2026-04-20 20:20 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
-- strict thread matches above, loose matches on Subject: below --
2026-04-15 16:37 Matt Corallo
2026-04-20 18:04 ` '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=71374026-6365-45fa-8168-ff1c8cb83dc9@mattcorallo.com \
--to=lf-lists@mattcorallo.com \
--cc=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--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