PQC - What is our Goal, Even?

[Matt Corallo]

Its become obvious in recent discussions that a large part of the PQC discussion has people coming at it from very different fundamental goals, and as a result the conversations often talk past each other without making real progress. So instead of doing that more I'd like to write down what I think the actual, short-term goal *is*, what it it is not.

Fundamentally, it seems to me the most reasonable goal is that we should be seeking to increase the number of coins which are reasonably likely to be secured by the time a CRQC exists. Put another way, we should be seeking to minimize the chance that the Bitcoin community feels the need to fork to burn coins by reducing the number of coins which can be stolen to the minimum number [1].

This naturally means focusing on the wallets which are the *least likely* to migrate or otherwise get themselves in a safe spot. Focusing on those who are the most likely to migrate does almost nothing to move the needle on the total number of coins protected, nor, thus, on the probability of a future Bitcoin community feeling the need to burn coins. Sadly, this probably means the "top wallets" that are generally terrible at adopting Bitcoin standards. Wallets which are the top listing on app stores like (currently in the top few in my app store): Bitcoin.com, Trust Wallet, Coinbase Wallet, Blockchain.com, etc. These wallets generally use a single static address (because anything else confuses their users and they get additional support tickets for it!) and put very little time into Bitcoin, focusing instead on other tokens and integrations.

A few non-goals:

* To ensure that advanced setups have the absolute best in post-quantum security. I don't see how this moves the needle on the above goal, and in fact in many cases detracts from the above goal. Of course if we can accomplish this without detracting from the top-line goal above, great.

* To ensure we have the best possible design for the signature scheme bitcoin will be using in a world where a CRQC exists and we've gotten past the mess. We'll almost certainly know a lot more about the security of various schemes and have more options for how to approach the problem by the point we're dealing with the mess of a CRQC being imminent, so it seems like a fools errand to try to predict what we should build for this. But even if we know no more then than we do today, likely ending up with hash-based signatures as the scheme everyone uses, we'll almost certainly be having conversations about additional witness discounts or increased block sizes to compensate for the sudden increase in transaction sizes. Maybe we would decide against such an increase, but there's no question such a conversation would happen and it would be premature to have it today.

Matt

[1] Of course I believe that the lost coin pool is large enough that the Bitcoin community will, almost without question, fork to disable insecure spend paths and burn some coins in the process, but reducing the number of coins burned to the absolute minimum is of course best for everyone.

[Matt Corallo]

[Erik Aronesty]

Yes I agree, Matt.  People are definitely talking past each other.  To me "safe coin maximization at the expense of decentralization and proof" seems like the completely wrong goal in almost every way.

I would like you to bear in mind that there is no reasonable way to a certain that someone is the owner of a coin unless they show proof of that private key.  I think we all can agree there.

And that with the theoretical magical quantum computers compromising private keys they will be no distinction between a coin holder and an attack. There is no possible ZKP that can fix this.

I think the fundamental thing we need to do is provide sovereign and active users the ability to protect their personal coins.  Opting into this protection will occur as the interested users determine that it needs to occur.  This is the only sure way to prevent a premature optimization for a computing paradigm that may never exist 

Maximizing sovereignty Is the entire purpose of a decentralized and peer-to-peer protocol.

Having decentralization and sovereignty be a secondary goal is like ignoring freedom of speech and then pretending to be a democracy. 

--
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+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/05E6D06B-1F72-48F6-B4F3-0225675BCC1F%40mattcorallo.com.

[Matt Corallo]

Hi Erik,

It appears you missed Olaoluwa's posts on this very list where he did exactly the thing you claim is
impossible - build a ZKP which allows someone to prove that they had the private key to a
transaction in a way that no quantum computer can forge!

Matt

> bitcoindev+...@googlegroups.com <mailto:bitcoindev%2Bunsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/05E6D06B-1F72-48F6-

> B4F3-0225675BCC1F%40mattcorallo.com <https://groups.google.com/d/msgid/
> bitcoindev/05E6D06B-1F72-48F6-B4F3-0225675BCC1F%40mattcorallo.com>.

>
> --
> 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+...@googlegroups.com <mailto:bitcoindev+...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/

> CAJowKgLKkSrzKGZAe2sSgCafjKx_U%2BoWz%2B-FxSb%2BAtppAayQXA%40mail.gmail.com <https://
> groups.google.com/d/msgid/bitcoindev/CAJowKgLKkSrzKGZAe2sSgCafjKx_U%2BoWz%2B-
> FxSb%2BAtppAayQXA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Erik Aronesty]

>   you missed Olaoluwa's posts 

No, I didn't miss them. They're irrelevant.   The base-case assumption is that the quantum assumption isn't attempting to forge a signature based on a public key.  It has the private key.

In which case there is no proof that can help.

[Erik Aronesty]

The assumption  Olaoluwa made is that there was a seed derivation at all.  Most of the exposed early coins don't have this.

[conduition]

Hi List,

> Fundamentally, it seems to me the most reasonable goal is that we should be seeking to increase the number of coins which are reasonably likely to be secured by the time a CRQC exists. Put another way, we should be seeking to minimize the chance that the Bitcoin community feels the need to fork to burn coins by reducing the number of coins which can be stolen to the minimum number [1].

I think that's a reasonable goal which we all share, but is not the only goal. Real-life isn't about min-maxing a single metric of success.

For instance, imagine we deploy P2TRv2, and we get EVERYONE to migrate to it before a CRQC appears. We maxed out our stated success metric. But we might not disable P2TRv2 key-spending in a timely manner. If the future community fails to deploy at the right time, a CRQC can steal at least as much bitcoin as they could've before the migration, if not more. We maxed out our success metric but still failed, so that metric must not be our only goal.

That's why we should achieve your stated goal only as a consequence of a more general but less easily-quantifiable goal: to design an optimal, flexible, and long-term-secure PQ migration path. If we standardize this and make code available to help, migration will come as a natural consequence, as will other desirable goals like "not letting a CRQC screw us all over", and "enabling long-term cryptographic agility".

If we can agree on that, then any further disagreement will be due to a difference of opinion as to what is "optimal" or "flexible", and the correct trade-offs to make on security. We all weigh different properties with different values.

For instance, I put more weight on conclusive security of P2MR, whereas Matt puts more weight on fee-efficiency and "privacy" of P2TRv2 [^1].

There are also differences of faith. Matt puts more faith in the future community to activate follow-up soft forks. I put more faith in wallet developers following standards and in users proactively migrating to PQ-safe wallets.

Based on Matt's previous emails, I think we both share the same LACK of faith that a majority of the UTXO set will migrate in time, and we also share the goal of mitigating that.

> This naturally means focusing on the wallets which are the *least likely* to migrate or otherwise get themselves in a safe spot. Focusing on those who are the most likely to migrate does almost nothing to move the needle on the total number of coins protected, nor, thus, on the probability of a future Bitcoin community feeling the need to burn coins.

Also agreed.


I didn't find any public statements from your cited examples about quantum security posture. Since it seems important to understand the wallets' stances in this dilemma, I posted a tweet tagging 8 major multi-chain wallets [2] including the 3 wallets you cited as examples. I'm curious what they'll say.

Having worked with such wallets before, my expectation is that they'll follow whatever is standardized, as long as it gives them more market share and as long as they can "npm install whatever" to implement it. I'm not trivializing here - These devs are just spread much thinner than those building single-chain wallets.

The harder question to answer is whether the major wallets make the PQ output type the default for receiving Bitcoin. Big software companies are typically very concerned about bugs in new code paths, and they weigh this risk against the benefits of any new feature. When deploying new features as default, they often do so using A/B testing and incremental rollout techniques. So the earlier question shouldn't be binary. It becomes: How quickly will major wallets roll out PQ outputs as default?

Rollout pace will depend on the personal views of the wallets' corporate executives and technical advisors. They will weigh the risk of introducing new, riskier, less-efficient code paths against the risk of a CRQC appearing in the near future. We and other users can try to lobby them, but ultimately each wallet's decision makers must eventually convince themselves the CRQC risk is greater. Some will move too slowly, and many will likely regret their choices one way or another.

I believe we cannot effectively optimize away a problem like this by tempting decision-makers with slightly lower fees, since that's not all they are worried about. I believe we especially should not try to do so at the expense of conclusive PQ security and long-term optimization.

I think the crux of the P2TRv2 vs P2MR disagreement here is that Matt believes P2TRv2 will induce wallets to roll out default PQ outputs meaningfully faster than P2MR would, and that this trumps arguments about post-quantum security or efficiency.

Whereas in my opinion, all we can do is build the best PQ standards we can, and encourage wallets to migrate once they're worried enough by the CRQC risks and ready to accept some mild trade-offs. That "best PQ standard" is, long-term, P2MR.

> There is no possible ZKP that can fix this.

There are several techniques which can.

regards,
conduition

[^1]: I still have yet to hear a decent argument as to why P2TRv2 is meaningfully more private than P2MR.
[2]: https://x.com/conduition_io/status/2044804746687525012

> To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c495b375-ebf5-4d9d-a9f6-a9d9922fd3dc%40mattcorallo.com.
>

[Matt Corallo]

On 4/16/26 1:34 PM, conduition wrote:
> Hi List,
>
>> Fundamentally, it seems to me the most reasonable goal is that we should be seeking to increase the number of coins which are reasonably likely to be secured by the time a CRQC exists. Put another way, we should be seeking to minimize the chance that the Bitcoin community feels the need to fork to burn coins by reducing the number of coins which can be stolen to the minimum number [1].
>
> I think that's a reasonable goal which we all share, but is not the only goal. Real-life isn't about min-maxing a single metric of success.
>
> For instance, imagine we deploy P2TRv2, and we get EVERYONE to migrate to it before a CRQC appears. We maxed out our stated success metric. But we might not disable P2TRv2 key-spending in a timely manner. If the future community fails to deploy at the right time, a CRQC can steal at least as much bitcoin as they could've before the migration, if not more. We maxed out our success metric but still failed, so that metric must not be our only goal.
>
> That's why we should achieve your stated goal only as a consequence of a more general but less easily-quantifiable goal: to design an optimal, flexible, and long-term-secure PQ migration path. If we standardize this and make code available to help, migration will come as a natural consequence, as will other desirable goals like "not letting a CRQC screw us all over", and "enabling long-term cryptographic agility".

Sure, there are limitations of the goal as I stated, but your suggested alternative here isn't
actually a concreate goal. "optimal, flexible, and long-term-secure" isn't something we can optimize
for :)

> If we can agree on that, then any further disagreement will be due to a difference of opinion as to what is "optimal" or "flexible", and the correct trade-offs to make on security. We all weigh different properties with different values.
>
> For instance, I put more weight on conclusive security of P2MR, whereas Matt puts more weight on fee-efficiency and "privacy" of P2TRv2 [^1].

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.

> There are also differences of faith. Matt puts more faith in the future community to activate follow-up soft forks. I put more faith in wallet developers following standards and in users proactively migrating to PQ-safe wallets.
>
> Based on Matt's previous emails, I think we both share the same LACK of faith that a majority of the UTXO set will migrate in time, and we also share the goal of mitigating that.
>
>
>> This naturally means focusing on the wallets which are the *least likely* to migrate or otherwise get themselves in a safe spot. Focusing on those who are the most likely to migrate does almost nothing to move the needle on the total number of coins protected, nor, thus, on the probability of a future Bitcoin community feeling the need to burn coins.
>
> Also agreed.
>
>
> I didn't find any public statements from your cited examples about quantum security posture. Since it seems important to understand the wallets' stances in this dilemma, I posted a tweet tagging 8 major multi-chain wallets [2] including the 3 wallets you cited as examples. I'm curious what they'll say.
>
> Having worked with such wallets before, my expectation is that they'll follow whatever is standardized, as long as it gives them more market share and as long as they can "npm install whatever" to implement it. I'm not trivializing here - These devs are just spread much thinner than those building single-chain wallets.

Sure but no new key scheme is going to be an "npm install whatever" - it requires a rewrite of a
bunch of key derivation and backup schemes. P2MR is also asking them to overhaul a UX decision they
made with lots of user feedback on top of that.

> The harder question to answer is whether the major wallets make the PQ output type the default for receiving Bitcoin. Big software companies are typically very concerned about bugs in new code paths, and they weigh this risk against the benefits of any new feature. When deploying new features as default, they often do so using A/B testing and incremental rollout techniques. So the earlier question shouldn't be binary. It becomes: How quickly will major wallets roll out PQ outputs as default?

Fair, true point.

> Rollout pace will depend on the personal views of the wallets' corporate executives and technical advisors. They will weigh the risk of introducing new, riskier, less-efficient code paths against the risk of a CRQC appearing in the near future. We and other users can try to lobby them, but ultimately each wallet's decision makers must eventually convince themselves the CRQC risk is greater. Some will move too slowly, and many will likely regret their choices one way or another.
>
> I believe we cannot effectively optimize away a problem like this by tempting decision-makers with slightly lower fees, since that's not all they are worried about. I believe we especially should not try to do so at the expense of conclusive PQ security and long-term optimization.
>
> I think the crux of the P2TRv2 vs P2MR disagreement here is that Matt believes P2TRv2 will induce wallets to roll out default PQ outputs meaningfully faster than P2MR would, and that this trumps arguments about post-quantum security or efficiency.

No, its far from just about fees. Its also about maintaining the goals that we had going into
taproot. And a bit that P2MR doesn't accomplish anything unless much of the ecosystem changes their
processes substantially.

[Ethan Heilman]

> 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.

There is a huge difference between, we would prefer you don't reuse addresses because privacy loss although privacy is hard to maintain anyways and if you reuse addresses in this context a CRQC may steal your user's funds.

Wallets are likely to be more responsive here than in the past because the stakes are much higher.

> In the face of address reuse, P2MR has zero advantages over P2TRv2.

It's not binary. If say 1% of coins in P2MR have address reuse because those users preferred to use insecure wallets, you still protected 99% of the other P2MR coins.

I am NOT suggesting or proposing this, but one could require that any P2MR output whose EC pubkey has been leaked on-chain due to address reuse can only be spent through the quantum safe leaf. If the community decides this is wallets advertising PQ functionality aren't actually PQ safe because this allow address reuse then one could solve the address reuse problem in this manner.

All told, it seems better to communicate to wallets and users that wallets which allow EC address reuse aren't PQ safe. If a wallet doesn't want to provide PQ safety why would they put in the engineering effort to support P2MR and PQ sigs. 

--
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+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/600f95eb-04e8-470d-b6df-cf725e48d1b5%40mattcorallo.com.

[Matt Corallo]

On Apr 17, 2026, at 18:04, Ethan Heilman <eth...@gmail.com> wrote:



> 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.

There is a huge difference between, we would prefer you don't reuse addresses because privacy loss although privacy is hard to maintain anyways and if you reuse addresses in this context a CRQC may steal your user's funds.

Wallets are likely to be more responsive here than in the past because the stakes are much higher.

More, maybe. But I think you’re drastically underestimating to what extent address reuse is baked into many flows.

For example most funds or very large holders have a pre-defined list of addresses that they’re allowed to send to (basically exchange accounts to sell), and have processes in place to ensure everyone cross validates that the address is on the list.

Yes, it’s possible to redo these, but people won’t, they’ll just presume that they can move the funds again before a CRQC. And many of them can, of course - the large funds probably would be about to move in a few days or weeks - but I’m quite confident it’ll get normalized pretty quickly…

> In the face of address reuse, P2MR has zero advantages over P2TRv2.

It's not binary. If say 1% of coins in P2MR have address reuse because those users preferred to use insecure wallets, you still protected 99% of the other P2MR coins.

Yes but we’re still back to square one - there’s still wallets relying on a disable-EC soft fork before a CRQC.

I am NOT suggesting or proposing this, but one could require that any P2MR output whose EC pubkey has been leaked on-chain due to address reuse can only be spent through the quantum safe leaf. If the community decides this is wallets advertising PQ functionality aren't actually PQ safe because this allow address reuse then one could solve the address reuse problem in this manner.

Yes, i mean I think P2MR would be way more exciting if we had an efficient way to enforce addresses as single use directly in consensus. I’m not, however, aware of one.

All told, it seems better to communicate to wallets and users that wallets which allow EC address reuse aren't PQ safe. If a wallet doesn't want to provide PQ safety why would they put in the engineering effort to support P2MR and PQ sigs. 

Because there will be marketing for “PQ safe” and no one (but us) will actually care about the distinction or bugs :).

Matt

[conduition]

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. 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.

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].

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).

regards,

conduition

[^1]: You can expand that prisoner's dilemma square into a cube by asking whether a CRQC will be invented or not, and P2MR is still a strictly better choice even if no CRQC appears - with or without EC restriction - because of its better script-path efficiency.

[^2]: For those rare few wallets who are: (1) willing to upgrade, (2) NOT willing to use fresh addresses, and (3) NOT willing to depend on future activation of an EC restriction, then these wallets can choose to use hybrid address formats which use ECC and hash-based sigs in the same locking script. This allows them to reuse addresses at the cost of efficiency. With a stateful signature (e.g. XMSS/SHRINCS), they'd be adding a few hundred bytes to their witnesses, and they'd be able to reuse the address thousands to millions of times. I could picture corporate cold-wallets using this technique, but maybe not retail wallets.

[Erik Aronesty]

P2MR is superior in another way.  If quantum never happens (a very real possibility), P2MR is genuinely broadly useful and more secure in other ways.

In other words, it wouldn't have been a waste of everyone's time.

[Matt Corallo]

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

[Erik Aronesty]

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.

bit disingenuous tho, right?

technically right but only in a very narrow sense. if you reuse and reveal a pubkey, p2mr and p2trv2 collapse to the same security profile. nobody is arguing that.

but that’s not the same as “p2mr has zero advantage.” it just means you threw away the advantage by using it wrong. before reveal, p2mr is strictly better because there’s no key path sitting there exposed the whole time.

basically the same pattern we already have everywhere. schnorr nonce reuse -> instant loss. bad multisig setup -> instant loss. 

you should say “it has zero advantage for the users that behave badly” 

now, consider materiality.  who is going to use their 400 billion dollar quantum computer to break the law and steal 2btc from someone who failed to use a modern wallet protocol that prevents address reuse under some theoretical future where a P2MR quantum world matters?

so you're down to:  

this is a problem.... but only for people who create their own vulns by failing to follow protocol, and also happen to have an enormous stash

[Matt Corallo]

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

[conduition]

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.

> 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.

> 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.


regards,
conduition



[1]: https://groups.google.com/g/bitcoindev/c/JA3kDl8AmQg/m/kUhTTSpVAwAJ

> --
> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/39f3c26e-2cb5-4dcb-a269-78c793174b2a%40mattcorallo.com.
>

[Matt Corallo]

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

[Matt Corallo]

On 4/19/26 12:37 PM, Matt Corallo wrote:
>>> 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?

It was pointed out to me that this was maybe a bit ambiguous. By "active coin supply", I'm really
talking about the coins which did use a PQC wallet, were theoretically "upgraded" to be safe, but
then got screwed anyway, possibly just because of what some other sending wallet did and not any bad
decisions on their (wallet's) part. They still ended up losing funds just because someone else
screwed up.

I also have similar but maybe not as extreme reservations around broader coin supply, but that is a
separate topic.

Matt

[Antoine Riard]

Hi,

> [1] Of course I believe that the lost coin pool is large enough that the Bitcoin community will, almost
> without question, fork to disable insecure spend paths and burn some coins in the process, but reducing
> the number of coins burned to the absolute minimum is of course best for everyone.

I think at this stage the bitcoin community is something like tens of millions of human beings spread
all over the world and coming from a multitude of horizons. I would take the bet that if you go to ask
them one by one they have would have no real idea about quantum risks, and about the "freeze or not
freeze" controversy they would at best shrug at you. So using "totalizing" socioligcal abstractions
like the "Bitcoin community" and rough guessing Pythia of Delphi-like what this "community" wishes
can only look a bit presumptuous to me...

The whole sale pitch of bitcoin for almost two decades, the one that people have argued at meetups,
conferences, online forums, in the media, in documentaries, on IRC, twitch, even in long-form blog
post [0] has been unconfiscatable and censorship-resistant money. Now, we would take the exact opposite
viewpoint and go to evangelize that *actually* your coins could be now massively confiscated or their
spend usage be censored at the protocol-level...All in the name of loosely defined reasons and risks...?
Sadly, I'm not smart enough to get it here.

Cutting through cheap rhetoric, the way the original post is framed can only lead to confusion and misunderstanding.
By saying first the goal should be to increase the number of coins which are going to be reasonably secure
by the time of a CQRC exists, if it exist one day, period, and then immediately it goes to reformulate the
goal as diminishing the likeliness there is a wish among some community stakeholders to freeze non-upgraded
coins to finally say that the goal should be to prioritize the migrations of the structures of wallet the less
likely to migrate.

It's all very confusing and at the end a reader cannot say if the thesis defended is:
- a) to prioritize consensus upgrades to allow coins owners to migrate their stacks to PQ safe schemes
- b) to prioritize the discussion on "freeze or not freeze", its legitimacy or not among protocol experts
- c) to prioritize the migration of wallet structures / services that might be slow to upgrade to PQ safe schemes

About a), it sounds to me reasonable to care about the CQRC risk. After all, the latest Nobel prize
in physics was awarded for works on the foundations of quantum computing. It might turn all like the
ether in the history of physics (i.e vaporware), though so far we're far to have reached a scientific
consensus on the subject [1]. While adding PQ safe schemes at the consensus level is obviously coming with
a price in term of implementation complexity, it's at least something tangible one can argue for or against.
We can then go to discuss all the varieties with EC-and-PQ safe schemes [2], though notably going to
argue on EC-and-PQ one has to assume that EC spend paths are never completely disabled.

About b), in my humble opinion, any argumentation that some coins must be "freeze" on the "price" is a chimera.
As far as I know, none of the bitcoin "technical experts" supporting a "freeze" is sitting on the board of
the FED, the ECB, the PBOC or the BOJ, so there is no way trying to make hand wawy estimation on a given price
level as there is no leverage on the demand (or the mere global offer of fiat money for a fixed amount of bitcoin).

Speaking about technical risks on the long-term viability of the network, realistically I don't see them. Of course,
one deep pocketed attacker could leverage the gains from CQRC exploitation to mount some categories of attacks against
L2s [3], though motivated attackers can already gather the bitcoin amount sufficient to launch that kind of attacks.
And I don't see attacks they could trigger on the base-layer, where they would hold a significant asymmetrical advantage.
If some are upset by the "no freeze" position, they're always free to go to launch their native PQ safe chain.

About c) it's not very our responsibility that some platforms and services are more focus to chase the latest
token mirages or whatever the ico of the day. All we can do is offering convenient PQ safe cryptograpghic schemes
and interface at the consensus levels, the earlier we can reasonably deliver on, all consensus caveats apply and
go to do the reasonable work of technical advocacy to explain how such schemes are working, somehow. If they're
too busy to care about upgrading their technical stack despite the numerous warnings on the subject, let's them
burn. We're not religious missionaries and it's not our role to go to morally reform their high time preferences
economical incentives.

Now, I do not wish to sound too much dismissive for the services operators and plateforms that have massive
amounts of coins to manage, and for which the quantum risk and any price fluctuation could be a real worry.
My answer to this worry is you're free to go to buy paper insurance coverage in the odds tof massive CQRC
exploitations happening 10 or 20 years down the road. Top insurance companies in the world are already able
to insure one hundreds in the year earthquake or flood, political risks and civil unrests so it should be
okay for them to go to insure a one hundred year quantum risk affecting centralized services...[4]

If we take the CQRC threat seriously, at least deserving some mitigation work, personally I prefer to scratch
my head on isogenies and lattices for practical schemes, rather than wasting ourselvces with the "freeze" non-sense.
The Poinsot take in the other thread calling to disentangle the two topics sounds a reasonable and balance viewpoint
to me.

At least that's my humble 2 sats.

Best,
Antoine
OTS hash: 0b266a6f42311bc42c701073e243f69a2ae8ce2ac9b895efcf49f0dd36ec1a07

[0] https://bluematt.bitcoin.ninja/page9/
[1] A contrario, no scientific yet has got a Noble Prize for demonstrating the impossibility of a QC
[2] In the case there is a cryptanalytic wreckage of the PQ safe but not the EC one
[3] https://ariard.github.io/sigsoverflow.html
[4] And if you prefer the more cypherpunk way, it's likely you can achieve the same with some bitvm constructions,
if it holds it's expressivity and security guarantees

[Antoine Poinsot]

Matt,

Thanks for this. I agree it's useful to first debate the goals of a first
migration step, and hopefully get broad agreement on a subset thereof.

The goal you propose rules out a PQ-only output as too expensive. I don't think
it is necessarily so, but it's probably fair that a seamless migration is a
requirement to get the vast majority of users upgraded.

Even taking your goal for granted, the devil is in the tradeoffs. As stated
elsewhere i don't think "we" (tm) should position ourselves as arbiter of who
gets to retain ownership of their coins should some users fail to migrate, which
could be necessary if this was the only dimension to optimize for.

I would also be uncomfortable with a migration strategy that could legitimize
future confiscation. We already start seeing attempts at normalizing it by
renaming it to "deprecation". This, in my view, hurts Bitcoin's perceived value
as much as the prospects of a CRQC materializing before it is ready to face it.

I'd like to also propose another goal. I find it extremely frustrating how black
and white thinking creeps into this discussion, whereby some participants treat
the risk of a CRQC as a certainty, not unlike how others deny it is even a risk
worth considering. I think our migration strategy should focus on maintaining
consensus (at least) until there is more certainty on the progress toward a
CRQC, and to not degrade Bitcoin in the event CRQCs do not become a reality
within the next decade or so.

Best,
Antoine Poinsot

> --
> 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+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CF7A554D-EE6F-4E6B-A670-1D6F72170539%40mattcorallo.com.
>

[Antoine Poinsot]

Hi Conduition,

Just a couple points on address reuse.

On Saturday, April 18th, 2026 at 11:59 AM, 'conduition' via Bitcoin Development Mailing List <bitco...@googlegroups.com> 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.

There are additional drawbacks to P2MR as specified in the current version of BIP360. Bitcoin users activated Taproot a little over 5 years ago, whose stated benefits include indistinguishable outputs between users of Script paths and non-Script paths, hide whether a Script path was present when keypath is used, and incentivize using such keypath in the first place (i.e. "doing the right thing"). I don't think we should throw all that out the window just now, if there are other ways of mitigating CRQC risks.

We have historical evidence this assumption won't hold. Take a look at Project Eleven's bitcoin risk list metrics dashboard. 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.

Matt's arguing about maximizing the number of users/utxos safely migrated, not share of supply, so i don't think this is a valid counterpoint. The Milton-Shikhelman report from July 2025 estimated over 60% of existing UTxOs reuse an address.

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/sMhLbmV30g91LFREGHE2JfcnoPYAOeUXZpOdeP7rY7aqBDpx0BP4avqHHKIu2JXU5ba5N2CgPDvxe_2lzDqHJsz9bsSInuaqZ5SSstrFJsE%3D%40proton.me.