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 09:36:48 -0400 [thread overview]
Message-ID: <39f3c26e-2cb5-4dcb-a269-78c793174b2a@mattcorallo.com> (raw)
In-Reply-To: <2b8d2a1b-9e9c-4918-9ac7-4bdcb15f5886@mattcorallo.com>
On 4/18/26 8:29 PM, Matt Corallo wrote:
>
>
> 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.
I wanted to expand on my answer here for a moment. I think the reasoning of "well, some people will
be able to use P2MR correctly" isn't just not fixing an interesting problem, I think its somewhat
dangerous.
First of all, the more I think about the address reuse problem (its been a while since I've really
thought about address reuse, so it took a day to come back to me...) the more I don't think its
going away. As you note about a quarter of all coins have an address-reuse issue, and if you remove
the large cold wallets its probably half that again. But when we consider both the uses of Bitcoin
that drive address reuse and look at the chain, there's a lot more risk here than just 1/8 of coins
(not to mention just 1/8 of coins is way too much).
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). Blaming bitcoin users when the
protocol was too hard to use is something we've tried very hard to avoid through engineering that
makes it harder to misuse. Instead, here, we're encouraging it. This doesn't just discourage any
future fork which might disable EC path spends (maybe some of that can be headed off with clear
documentation in a P2MR BIP, but this blaming has already started...), but it encourages a culture
of blaming bitcoin holders for the mistakes made at the protocol layer.
On address reuse, as far as I'm aware, its driven by at least three factors -
* There's the somewhat obnoxious "wallets get user complaints when their address changes cause
they're used to address-based blockchains so wallet devs turn off the address rotation feature to
save on support costs" one which is the most frustrating, and may well drive the most wallets, but
certainly doesn't drive the most coins. Maybe this one is fixable. I'm quite skeptical, but you and
Ethan certainly seem to think it is.
* For funds, family offices, many custodians, and exchange hot wallets, address reuse is an
important security feature - much of the large-bitcoin-wallet industry is built around keeping a
list of allowed addresses (exchange accounts for sales, but also on the flip side a list of their
own wallets which their exchange accounts are limited to withdraw *to*). They have processes in
place to verify every transaction only goes to one of the addresses in their list. When I go to look
at the addresses with the most bitcoin transacted in the last year, there's some cold wallets, but
number two is 1KNm4K8GUK8sMoxc2Z3zU8Uv5FDVjrA72p, which some random website seems to think is jump
trading...it has received a total of 97M bitcoin across its lifetime. Maybe the large players will
rewrite their logic to use a combination of xpubs for EC key generation and a static PQ pubkey,
building the tree as required, but exchanges are gonna struggle with the extra address
generation/chain scanning burden and I'd think would instead just switch to PQ-only and charge the
extra cost as a deposit/withdraw fee, or more likely "use it wrong" and upgrade "when the time
comes", blaming their customers for sending coins to a "revoked address" when they do so. Maybe a
new output type really (finally) needs a new address type that has an expiry date...
* But maybe most importantly, sadly ultimately no one can control when someone else sends them
bitcoin. For spending wallets that are used to receive coins, the sending wallet having a "contacts"
feature or users just reusing an address that was provided to them is enough to potentially screw a
wallet. While the first isn't so common (though certainly growing), the second presumably is
somewhat more. Here too, maybe the solution is just an address format with an expiry date, but of
course that would slow down any migration by probably five years and likely isn't a great tradeoff
either.
* Its probably worth noting that dusting attacks could trigger many wallets to reveal a public key
too soon. Of course any "quantum safe" wallet should handle this in the way Bitcoin Core does -
ensuring it spends all outputs with the same address at once, but this is just one more way relying
on this stuff can so easily go wrong.
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/39f3c26e-2cb5-4dcb-a269-78c793174b2a%40mattcorallo.com.
next prev parent reply other threads:[~2026-04-19 14:06 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 [this message]
2026-04-19 16:27 ` 'conduition' via Bitcoin Development Mailing List
2026-04-19 16:37 ` Matt Corallo
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=39f3c26e-2cb5-4dcb-a269-78c793174b2a@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