Hi Antoine, > My point is that Taproot incentivizes users of advanced contracts to make > their Script usage indistinguishable from other usages.
I think I see what you mean. Matt made this point earlier. P2TR encourages the use of the key-spending path because its cost is forced on the user, who must intentionally opt-out of using it (NUMS point), while with P2MR the user can choose to save space by omitting a cooperative BIP340 leaf script. Then they'd have a script tree with just a single spending path for some complex and easily-fingerprintable script which reduces their and everyone else's anonymity set. I'll call this the 'single-leaf' pattern. I have three arguments against this point as a justification for P2TRv2: 1. The number of people who are going to fit into this incentive funnel would be small, so the effect on privacy for everyone else would be negligible. For a single-leaf script tree to be more efficient than a two-leaf script tree, the difference between witness sizes for the cooperative vs uncooperative spending paths would have to be less than 32 bytes. Any larger and it now pays to include a cooperative path. The larger the difference, the more well-incentivized a cooperative spending path would be. Though this rules out extraneous factors like development effort, but still I expect the incentivized demographic will be tiny. 2. This property can be argued as a feature: P2MR has some advantage over P2TR in efficiency, under certain scenarios. It gives P2MR a reason to exist even if CRQCs never appear. You're framing this property as a negative because of the privacy implications, but we should consider the positives as well. 3. Finally, compared to the integrity of the UTXO set, this is a bikeshed-level design goal. If we have to risk the security of everyone's coins, and commit ourselves to perfectly timing a follow-up soft-fork that disables P2TRv2 key-spending, then the privacy gain is not worth it. Still, maybe we don't have to take that risk to get the incentive structure we want. What if we modified P2MR to require trees of at least depth 1? This way, the user must bear the cost of at least two spending paths anyway, so they might as well use one for an everyone-agrees BIP340 path. This mirrors the incentive structure of P2TR's non-optional key-spend path. 99% of users (those building P2MR addresses properly) would not be affected by this change anyway, because quantum-resistant hybrid addresses would be the specified standard for consumer wallets, and those wallets would already have at least two script leaves. The downside of this is a loss of efficiency after Q-day, for wallets which may only need a single PQ leaf (no point in using an ECC leaf anymore). Would this assuage your concern about incentives? regards, conduition On Wednesday, May 20th, 2026 at 12:49 PM, Antoine Poinsot <[email protected]> wrote: > Hi Conduition, > > My point is that Taproot incentivizes users of advanced contracts to make > their Script usage indistinguishable from other usages. I believe this is a > desirable property because privacy is a common good, and because users > usually do not need to reveal differences in their spending conditions. > > If P2MR is made available you will immediately see usage from people that are > not interested in migrating to PQ cryptography, but simply do not want to pay > the cost of revealing the internal key in Taproot script path spends. This > does two things: > > - this preemptively abandons some of the benefits of Taproot; > - this makes any future soft fork to disable EC in P2MR context, which > would be necessary to provide any PQ migration guarantee, extremely dubious. > > > Therefore i think alternatives that preserve Taproot's properties, like > P2TRv2, are preferable. > > Best, > Antoine > On Tuesday, May 19th, 2026 at 10:04 PM, 'conduition' via Bitcoin Development > Mailing List <[email protected]> wrote: > > > Hi Antoine, thanks for chiming in. > > > > > > > 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. > > > > > > > > I'm a bit confused by this framing of P2MR. Once P2MR is deployed and > > in-use with hybrid PQC, it will have the same practical privacy profile as > > P2TR prior to Q-Day, and an 'everyone-agrees' path using BIP340 keys would > > still be almost as well-incentivized. > > > > For anyone who does truly need the savings of key-path spending, P2TR still > > exists and can be used. Nothing is being "thrown away" - you'd just need to > > ensure that any coins on P2TR addresses are moved to P2MR before Q-day. > > > > > > > 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. > > > > > > > > Ahh, I misunderstood. I'd be very curious to know more about the > > demographics of those address-reusing UTXOs. If they're controlled by > > exchanges or other big-bag-holders, then they're more likely to migrate in > > time. If not, well... At least BIP32 rescue protocols should be able to > > cover most of them, since most end-users hold coins in BIP32 wallets. > > > > > > regards, > > conduition > > > > > > On Monday, April 20th, 2026 at 3:51 PM, 'Antoine Poinsot' via Bitcoin > > Development Mailing List <[email protected]> wrote: > > > > > Hi Conduition, > > > > > > Just a couple points on address reuse. > > > > > > > > > On Saturday, April 18th, 2026 at 11:59 AM, 'conduition' via Bitcoin > > > Development Mailing List <[email protected]> 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. > > > > > > > > > > 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. > > > > > > > > On Friday, April 17th, 2026 at 6:38 PM, Matt Corallo > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On Apr 17, 2026, at 18:04, Ethan Heilman <[email protected]> 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 Fri, Apr 17, 2026, 17:02 Matt Corallo <[email protected]> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 [email protected]. > > > > > > > To view this discussion visit > > > > > > > https://groups.google.com/d/msgid/bitcoindev/600f95eb-04e8-470d-b6df-cf725e48d1b5%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 [email protected]. > > > > To view this discussion visit > > > > https://groups.google.com/d/msgid/bitcoindev/sMhLbmV30g91LFREGHE2JfcnoPYAOeUXZpOdeP7rY7aqBDpx0BP4avqHHKIu2JXU5ba5N2CgPDvxe_2lzDqHJsz9bsSInuaqZ5SSstrFJsE%3D%40proton.me. > > > > > > -- > > > 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 [email protected]. > > > To view this discussion visit > > > https://groups.google.com/d/msgid/bitcoindev/kkdcg1Bo7GsRcpH5gDpfZ1WZR-ulfI5JRUKFa8cWla7CaWGtbQxgcE-nGZBOQeXKpepfSh8eVhE-x2-fOXExE9x2b2V21m6kact8e4CSzNQ%3D%40protonmail.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 [email protected]. > > To view this discussion visit > > https://groups.google.com/d/msgid/bitcoindev/_3mqxJvqmo5uwzca07-KxjxELdI5NAL0rajqITUDVdVdSojG1ajcTYOZdlmbnQCOUKsxGEj8onXRUvaTXW4g_gH9qZvIvpY1ZHZkpgpaoXs%3D%40proton.me. -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/F0sSI3to9XSYx59YKqcc8WkM99HJwP18Cca56peuOmfMnPFEmptu61Mtjkv4wf8xLgzWbGjDKfyfn9Ipi7OvDuajiWU7NnhmjHhdjFpxOcM%3D%40proton.me.
publickey - [email protected] - 0x474891AD.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
