On Apr 17, 2026, at 18:04, Ethan Heilman <eth3rs@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
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.
--
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/600f95eb-04e8-470d-b6df-cf725e48d1b5%40mattcorallo.com.