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: Sat, 18 Apr 2026 20:29:18 -0400 [thread overview]
Message-ID: <2b8d2a1b-9e9c-4918-9ac7-4bdcb15f5886@mattcorallo.com> (raw)
In-Reply-To: <sMhLbmV30g91LFREGHE2JfcnoPYAOeUXZpOdeP7rY7aqBDpx0BP4avqHHKIu2JXU5ba5N2CgPDvxe_2lzDqHJsz9bsSInuaqZ5SSstrFJsE=@proton.me>
On 4/18/26 11:44 AM, conduition wrote:
> I think I maybe under-stated my concern over the no-address-reuse requirement for P2MR. We've
> been trying to convince wallets to not reuse addresses for 15+ years and have not only had no
> success, popular wallets have been actively migrating the opposite direction instead. In the
> face of address reuse, P2MR has zero advantages over P2TRv2.
>
>
> I think we agree that merely spec-ing out P2MR as "not safe to reuse" in a BIP will be insufficient
> to prevent all address reuse. We also agree that /reused /P2MR and P2TRv2 share the same security
> profile, with or without a future EC restriction (which can be applied to either output type).
>
> But we seem to disagree in our conclusions. You believe that because of this overlap in security
> profiles, that we therefore ought to prefer P2TRv2 - presumably because of its short-term
> efficiency. I think that's a huge leap of logic. The overall security profile of P2TRv2 and P2MR are
> wildly different and you are only taking a subset of P2MR's profile into account.
>
> To reach your conclusion that P2TRv2 is preferable, you'd need to assume that the vast majority
> users who migrate to P2MR will reuse addresses - vast enough of a majority that the short-term
> efficiency savings of P2TRv2 key-spending outweighs the safety of the (presumed) tiny minority of
> users who actually use P2MR properly.
>
> We have historical evidence this assumption won't hold. Take a look at Project Eleven's bitcoin risk
> list metrics dashboard <https://www.projecteleven.com/bitcoin-risq-list/metrics>. The volume of
> bitcoin exposed today due to address reuse is only a minority fraction of the overall supply - about
> 5 million BTC at present. Still significant, but not an overwhelming majority by any means. We have
> no reason to expect everyone will suddenly start reusing addresses consistently with P2MR, at least
> not any more than they already do.
>
> If anything, address-reuse will reduce, and not just because we ask them to. If you look at the
> highest-value addresses at fault of address-reuse today, they are mostly corporate cold wallets:
> binance, robinhood, bitfinex, tether, etc, and these make up a significant chunk of those 5 million
> exposed coins. We can reasonably expect those players to use P2MR properly out of self-interest -
> These coins will be the lowest-hanging fruit targets if they fail to do so.
>
> So yes, even after taking address reuse into account, P2MR is more secure than P2TRv2, and
> personally I think the safety delta between them is wide enough to excuse the minor handicap in
> P2MR's pre-quantum efficiency.
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.
Sure, in any solution set here there is going to be coins lost, but if someone did the work to
migrate, having a high % chance of screwing it up isn't an interesting scenario to consider -
bitcoin is simply dead in that case.
> P2MR is also asking them to overhaul a UX decision they made with lots of user feedback on top
> of that.
>
>
> That's fair, it would be a difficult challenge to some low-effort wallets not to receive coins to
> vulnerable addresses. But this argument implies EC spending on P2MR isn't restricted in time -
> otherwise there is nothing to exploit when addresses are reused, and so address reuse wouldn't
> matter. Under this same implication, P2TRv2 fares even worse. Concretely:
>
> * If EC spending is restricted, then both P2MR and P2TRv2 have exactly the same security profile
> and address reuse does not matter.
>
> * If EC spending isn't restricted, then both address formats are vulnerable when reused, and
> P2TRv2 exposure is worse because even those who /don't/ reuse addresses are vulnerable.>
> In other words, P2MR is the Nash equilibrium of a prisoner's dilemma square [^1].
>
> * P2MR: addresses with hidden EC spend paths are safe
> * P2TRv2: everyone is vulnerable
> * P2MR with EC restriction: everyone is safe
> * P2TRv2 with EC restriction: everyone is safe
>
>
> Whether EC restriction happens or not, you always get the same or better security by choosing P2MR.
> EC restriction is the only step which can secure reused addresses of either P2MR or P2TRv2 [^2].
Right, see above. Who cares if NN% of people used P2MR, accidentally had some address reuse, and now
their coins are stolen? Bitcoin is over. Great, some exchanges managed to protect their coins and
probably some long-term holders, but a ton didn't, due to no direct fault of their own. What in the
hell is the point of bitcoin if so many lost coins without fault?
> Thus, if you firmly believe that many wallets will reuse addresses and want to mitigate the
> vulnerability that follows, then the choice between output types should not weigh on your mind. Your
> goal should be to push everyone to commit to an EC-restricting soft fork later (maybe have a look at
> BIP361 and contribute to that). The details of what output type is deployed don't factor in. Again:
> the only difference between P2MR and P2TRv2 there is that P2TRv2 /needs a future soft fork to
> restrict EC spending/, while with P2MR this is optional, but still desirable (since some wallets
> will mistakenly reuse addresses either way).
The selection of output types matters for other reasons, certainly the only consideration is not who
will select which output type.
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/2b8d2a1b-9e9c-4918-9ac7-4bdcb15f5886%40mattcorallo.com.
next prev parent reply other threads:[~2026-04-19 1:51 UTC|newest]
Thread overview: 13+ 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 [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-04-15 16:37 Matt Corallo
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=2b8d2a1b-9e9c-4918-9ac7-4bdcb15f5886@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