From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 28 May 2026 15:20:41 -0700 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wSj5i-0005Bz-MQ for bitcoindev@gnusha.org; Thu, 28 May 2026 15:20:41 -0700 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-43b5aed6fb9sf7950936fac.1 for ; Thu, 28 May 2026 15:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1780006832; x=1780611632; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=zDMM85Wyi6UEPDlYCTbBI60loQ9Qcofc+nrhcWjC3qA=; b=RUSm16rGHNzNF1x4T1Mh+ZdcaaHEazQ3FYzWFnYajrAFM4Ivs43bPscw88/1ujskdJ tUXIPs0BuBum08EkUNO4ZuGvBB7XC5JMYuBgJ7tRBAPSVvdYb+yFL3MqM6wIE+CEGnos wQ9trjzo+fwi8QtwyyPSlEpXXDc21yeIDUGeqNwp3Ng0av0tJBqa8/neQ3o+l40qyzdb o8bJqBZDQmr5JdTxmxnDmeXFBObLywQnTwc3f5S15g1C+XLxslTIkn+l2nofnkRpcblV RaxVqOMhnFafTWD5C3boEzxevfPIxMVXLYVjQH6umqGJEsYRXIEdbTfIBr6L0+uFqEF+ nngQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780006832; x=1780611632; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=zDMM85Wyi6UEPDlYCTbBI60loQ9Qcofc+nrhcWjC3qA=; b=PLzI6uH0w+9mFC+a2O5GSjFyfiBgkD65l2wrPvVkg3gOsk0ITMZz6UIGtqmzmK1yyQ S9JqO1kInxHoi2dHaM5UTTc0Zlnb8YuMGlQUmITduieCa/ZPhHpYArsqM4sKmO0wdgrI 1SNCP53UWlWEgC2QkACO6ElJwpkxrCSzLO8JoBGmeW3ABj5P6qEidvEE4aNqYwLKW7MH 2+NEu+uhwYhA0lS5zwYTA05ALjoh+Wfpib6e7ChmIg9ENN0s8X+bQcKn8lgzuv0+DUCx 4VLANa+BSWqO26IEafDJrRv9vAd/2dW1xos2RcBXJQIIimarEoShthsb+PhHiR46354d YVkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780006832; x=1780611632; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=zDMM85Wyi6UEPDlYCTbBI60loQ9Qcofc+nrhcWjC3qA=; b=E7jI2Cdp/76SR0SjOZKsYRdHvkIOsj6Bx4wurb5uI8M7ViC7B7sL4T9rc73vn2Owsn rs2pVbfxbMCAJxEuo36KuR0nAljQGXjaOUNCuDPPuFOtJfmshnWW5tmYlVZ9n+q6UQ9s ZnvgrJLm+qGKm7VoYWXXBu01svwoy2QQ+YvVvGkTu8f3mgmpp8y3ZFlFmjBFD6KrtbEU jactH4g5B7iR2zaY3pWlAPh4NYtntT/aXbfprfFkBA6pcEGv6h06QYWAxak7VOVfnZzb twQXIowZZ173Lt9MuDkh/R8JECdcTsixALVhN1Kus3pcDUWvF87Oqq/uOnQjgGzx1fcw bN6Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ9u+CWmRsHV0L8TjYXX8HCWbJVTlk6bC3xGUHQsItSFE1Rvb2rWAX4H6yuJStq6jCOrQ43kwQ4IoJMT@gnusha.org X-Gm-Message-State: AOJu0YwgmPFG+Sx2H4yoU8AcQl6PrmrxWPNGq4LJqqu0YGEneFzbeTja sQXGF2BSULf4wdIO/SuRr/zp/dKxyP4PC0cYtE7cirqGtytwrX02nA1d X-Received: by 2002:a05:6871:341a:b0:43a:9746:e20 with SMTP id 586e51a60fabf-43c8c6ac630mr37337fac.25.1780006832188; Thu, 28 May 2026 15:20:32 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMPifYdSGZ08bEG11Ne85Efnn7/wRMVONwt/zuMEnMlEhQ==" Received: by 2002:a05:6871:61c7:b0:430:2c03:d0f5 with SMTP id 586e51a60fabf-43c5149e810ls1007050fac.0.-pod-prod-05-us; Thu, 28 May 2026 15:20:23 -0700 (PDT) X-Received: by 2002:a05:6808:c291:b0:482:4dbd:4fde with SMTP id 5614622812f47-485e6a67ecemr357859b6e.19.1780006823923; Thu, 28 May 2026 15:20:23 -0700 (PDT) Received: by 2002:a05:690c:a6c3:b0:7d0:63a3:69e7 with SMTP id 00721157ae682-7dc324939bfms7b3; Thu, 28 May 2026 15:13:13 -0700 (PDT) X-Received: by 2002:a05:690c:6e12:b0:7bb:712:a754 with SMTP id 00721157ae682-7de466e5677mr1203767b3.5.1780006392898; Thu, 28 May 2026 15:13:12 -0700 (PDT) Date: Thu, 28 May 2026 15:13:12 -0700 (PDT) From: Louise Michel To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <_3mqxJvqmo5uwzca07-KxjxELdI5NAL0rajqITUDVdVdSojG1ajcTYOZdlmbnQCOUKsxGEj8onXRUvaTXW4g_gH9qZvIvpY1ZHZkpgpaoXs=@proton.me> <3TguePkqzkPWZeuW8j7nrZnDnhmDpYfIh22hbInFeyVRwPX0Ohh7wjsptoNMnJAKwysYUGaGOaQVVx7se5WEeO-nmUEpcWUC_jKBWQrx4tI=@protonmail.com> Subject: Re: [bitcoindev] PQC - What is our Goal, Even? MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_134386_864842122.1780006392229" X-Original-Sender: barsonneck@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_134386_864842122.1780006392229 Content-Type: multipart/alternative; boundary="----=_Part_134387_771098129.1780006392229" ------=_Part_134387_771098129.1780006392229 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gosh, what a ton of words have been spilled on this. xD Address re-use has serious privacy implications, and it should be=20 discouraged if for no other reason than that. Of course, users are free to= =20 re-use addresses if they really want to. As for bitcoin outputs, users have the option to use P2TR today and into=20 the future, for as long as they want. It is a very good option. At some point, some users may decide they no longer trust the security of= =20 the key-path spend and perhaps even ECC signatures generally. Those users= =20 might wish to retain the flexibility of the script-tree functionality from= =20 P2TR and get rid of the overhead from the ECC key-path spend that they no= =20 longer trust (and possibly can't even use). For these users P2MR is a=20 superior option. P2TRv2 just gets us to this same point in a different way= =20 and while retaining the aforementioned cruft. There is fundamentally no=20 difference in privacy or in security between a P2TRv2 output and P2MR=20 output in the limit, if one assumes that a CRQC one day exists. P2TRv2 is= =20 simply larger and more expensive. P2TRv2 also tries to time Q-day, which is= =20 a fools errand. Far better to simply provide the better option and allow=20 users and wallets to decide for themselves when to switch.=20 In the world where Q-day comes, then rational actors use some Taproot-esque= =20 script-path spending output with a disabled key-path (P2MR or P2TRv2), or= =20 maybe they use another script-based, hashed output type. In such a world,= =20 P2MR is objectively more economical that P2TR/P2TRv2, it is PQ-resistant=20 right from day one, smaller, and doesn't sacrifice on privacy or security.= =20 If that world never materializes, then P2TR remains the superior solution= =20 that it is today. It is a supreme irony that this argument is occurring between proponents of= =20 P2TRv2 who want to disable (and for some reason retain) the key-path spend= =20 of Taproot and proponents of BIP-360, which is a literal copypasta of=20 Taproot with the key-path spend hacked out of it.=20 be well, Louise=20 On Thursday, May 21, 2026 at 12:17:56=E2=80=AFPM UTC-6 conduition wrote: > Hi Antoine, > > My point is that Taproot incentivizes users of advanced contracts to make= =20 > their Script usage indistinguishable from other usages. > > > I think I see what you mean. Matt made this point earlier. P2TR encourage= s=20 > the use of the key-spending path because its cost is forced on the user,= =20 > who must intentionally opt-out of using it (NUMS point), while with P2MR= =20 > the user can choose to save space by omitting a cooperative BIP340 leaf= =20 > script. Then they'd have a script tree with just a single spending path f= or=20 > some complex and easily-fingerprintable script which reduces their and=20 > 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=20 > funnel would be small, so the effect on privacy for everyone else woul= d be=20 > negligible. For a single-leaf script tree to be more efficient than a= =20 > two-leaf script tree, the difference between witness sizes for the=20 > cooperative vs uncooperative spending paths would have to be less than= 32=20 > bytes. Any larger and it now pays to include a cooperative path. The l= arger=20 > the difference, the more well-incentivized a cooperative spending path= =20 > would be. Though this rules out extraneous factors like development ef= fort,=20 > but still I expect the incentivized demographic will be tiny. > > > > 2. This property can be argued as a feature: P2MR has some advantage= =20 > over P2TR in efficiency, under certain scenarios. It gives P2MR a reas= on to=20 > exist even if CRQCs never appear. You're framing this property as a=20 > negative because of the privacy implications, but we should consider t= he=20 > positives as well. > > > > 3. Finally, compared to the integrity of the UTXO set, this is a=20 > bikeshed-level design goal. If we have to risk the security of=20 > *everyone's* coins, and commit ourselves to perfectly timing a=20 > follow-up soft-fork that disables P2TRv2 key-spending, then the privac= y=20 > gain is not worth it. > > > Still, maybe we don't have to take that risk to get the incentive=20 > structure we want. > > *What if we modified P2MR to require trees of at least depth 1?* This=20 > way, the user *must* bear the cost of at least two spending paths anyway,= =20 > so they might as well use one for an everyone-agrees BIP340 path. This=20 > mirrors the incentive structure of P2TR's non-optional key-spend path. > > 99% of users (those building P2MR addresses properly) would not be=20 > affected by this change anyway, because quantum-resistant hybrid addresse= s=20 > would be the specified standard for consumer wallets, and those wallets= =20 > would already have at least two script leaves. The downside of this is a= =20 > loss of efficiency after Q-day, for wallets which may only need a single = PQ=20 > 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 < > daro...@protonmail.com> wrote: > > Hi Conduition, > > My point is that Taproot incentivizes users of advanced contracts to make= =20 > their Script usage indistinguishable from other usages. I believe this is= a=20 > desirable property because privacy is a common good, and because users=20 > usually do not need to reveal differences in their spending conditions. > > If P2MR is made available you will immediately see usage from people that= =20 > are not interested in migrating to PQ cryptography, but simply do not wan= t=20 > to pay the cost of revealing the internal key in Taproot script path=20 > 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= =20 > would be necessary to provide any PQ migration guarantee, extremely du= bious. > > > Therefore i think alternatives that preserve Taproot's properties, like= =20 > P2TRv2, are preferable. > > Best, > Antoine > On Tuesday, May 19th, 2026 at 10:04 PM, 'conduition' via Bitcoin=20 > Development Mailing List wrote: > > Hi Antoine, thanks for chiming in.=20 > > There are additional drawbacks to P2MR as specified in the current versio= n=20 > of BIP360. Bitcoin users activated Taproot a little over 5 years ago, who= se=20 > stated benefits include indistinguishable outputs between users of Script= =20 > paths and non-Script paths, hide whether a Script path was present when= =20 > keypath is used, and incentivize using such keypath in the first place=20 > (i.e. "doing the right thing"). I don't think we should throw all that ou= t=20 > 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=20 > in-use with hybrid PQC, it will have the same practical privacy profile a= s=20 > P2TR prior to Q-Day, and an 'everyone-agrees' path using BIP340 keys woul= d=20 > still be almost as well-incentivized. > > For anyone who does truly need the savings of key-path spending, P2TR=20 > still exists and can be used. Nothing is being "thrown away" - you'd just= =20 > need to ensure that any coins on P2TR addresses are moved to P2MR before= =20 > Q-day. > > Matt's arguing about maximizing the number of users/utxos safely migrated= ,=20 > not share of supply, so i don't think this is a valid counterpoint.=20 > The Milton-Shikhelman report from July 2025 estimated over 60% of existin= g=20 > UTxOs reuse an address. > > > Ahh, I misunderstood. I'd be very curious to know more about the=20 > demographics of those address-reusing UTXOs. If they're controlled by=20 > exchanges or other big-bag-holders, then they're more likely to migrate i= n=20 > time. If not, well... At least BIP32 rescue protocols should be able to= =20 > cover most of them, since most end-users hold coins in BIP32 wallets. > > regards, > conduition=20 > > > On Monday, April 20th, 2026 at 3:51 PM, 'Antoine Poinsot' via Bitcoin=20 > Development Mailing List wrote: > > Hi Conduition, > > Just a couple points on address reuse. > > On Saturday, April 18th, 2026 at 11:59 AM, 'conduition' via Bitcoin=20 > Development Mailing List wrote: > > I think I maybe under-stated my concern over the no-address-reuse=20 > requirement for P2MR. We've been trying to convince wallets to not reuse= =20 > addresses for 15+ years and have not only had no success, popular wallets= =20 > have been actively migrating the opposite direction instead. In the face = of=20 > 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=20 > BIP will be insufficient to prevent all address reuse. We also agree that= =20 > *reused *P2MR and P2TRv2 share the same security profile, with or without= =20 > 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= =20 > this overlap in security profiles, that we therefore ought to prefer P2TR= v2=20 > - presumably because of its short-term efficiency. I think that's a huge= =20 > leap of logic. The overall security profile of P2TRv2 and P2MR are wildly= =20 > 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= =20 > that the vast majority users who migrate to P2MR will reuse addresses -= =20 > vast enough of a majority that the short-term efficiency savings of P2TRv= 2=20 > key-spending outweighs the safety of the (presumed) tiny minority of user= s=20 > who actually use P2MR properly. > > > There are additional drawbacks to P2MR as specified in the current versio= n=20 > of BIP360. Bitcoin users activated Taproot a little over 5 years ago, who= se=20 > stated benefits include indistinguishable outputs between users of Script= =20 > paths and non-Script paths, hide whether a Script path was present when= =20 > keypath is used, and incentivize using such keypath in the first place=20 > (i.e. "doing the right thing"). I don't think we should throw all that ou= t=20 > 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 Pr= oject=20 > Eleven's bitcoin risk list metrics dashboard=20 > . The volume of= =20 > bitcoin exposed today due to address reuse is only a minority fraction of= =20 > the overall supply - about 5 million BTC at present. Still significant, b= ut=20 > not an overwhelming majority by any means. We have no reason to expect=20 > everyone will suddenly start reusing addresses consistently with P2MR, at= =20 > least not any more than they already do. > > > Matt's arguing about maximizing the number of users/utxos safely migrated= ,=20 > not share of supply, so i don't think this is a valid counterpoint. The M= ilton-Shikhelman=20 > report from July 2025 estimated over 60% of existing UTxOs reuse an=20 > address > . > > If anything, address-reuse will reduce, and not just because we ask them= =20 > to. If you look at the highest-value addresses at fault of address-reuse= =20 > today, they are mostly corporate cold wallets: binance, robinhood,=20 > bitfinex, tether, etc, and these make up a significant chunk of those 5= =20 > million exposed coins. We can reasonably expect those players to use P2MR= =20 > properly out of self-interest - These coins will be the lowest-hanging=20 > fruit targets if they fail to do so. > > So yes, even after taking address reuse into account, P2MR is more secure= =20 > than P2TRv2, and personally I think the safety delta between them is wide= =20 > 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= =20 > user feedback on top of that. > > > That's fair, it would be a difficult challenge to some low-effort wallets= =20 > not to receive coins to vulnerable addresses. But this argument implies E= C=20 > spending on P2MR isn't restricted in time - otherwise there is nothing to= =20 > exploit when addresses are reused, and so address reuse wouldn't matter.= =20 > Under this same implication, P2TRv2 fares even worse. Concretely: > > > - If EC spending is restricted, then both P2MR and P2TRv2 have exactly= =20 > the same security profile and address reuse does not matter.=20 > =20 > > - If EC spending isn't restricted, then both address formats are=20 > vulnerable when reused, and P2TRv2 exposure is worse because even thos= e who=20 > *don't* reuse addresses are vulnerable. > =20 > > In other words, P2MR is the Nash equilibrium of a prisoner's dilemma=20 > square [^1].=20 > > > - 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= =20 > security by choosing P2MR. EC restriction is the only step which can secu= re=20 > reused addresses of either P2MR or P2TRv2 [^2]. > > Thus, if you firmly believe that many wallets will reuse addresses and=20 > want to mitigate the vulnerability that follows, then the choice between= =20 > output types should not weigh on your mind. Your goal should be to push= =20 > everyone to commit to an EC-restricting soft fork later (maybe have a loo= k=20 > at BIP361 and contribute to that). The details of what output type is=20 > deployed don't factor in. Again: the only difference between P2MR and=20 > P2TRv2 there is that P2TRv2 *needs a future soft fork to restrict EC=20 > spending*, while with P2MR this is optional, but still desirable (since= =20 > some wallets will mistakenly reuse addresses either way). > > regards, > conduition > > [^1]: You can expand that prisoner's dilemma square into a cube by asking= =20 > whether a CRQC will be invented or not, and P2MR is still a strictly bett= er=20 > choice even if no CRQC appears - with or without EC restriction - because= =20 > of its better script-path efficiency. > > [^2]: For those rare few wallets who are: (1) willing to upgrade, (2) NOT= =20 > willing to use fresh addresses, and (3) NOT willing to depend on future= =20 > activation of an EC restriction, then these wallets can choose to use=20 > hybrid address formats which use ECC and hash-based sigs in the same=20 > locking script. This allows them to reuse addresses at the cost of=20 > efficiency. With a stateful signature (e.g. XMSS/SHRINCS), they'd be addi= ng=20 > a few hundred bytes to their witnesses, and they'd be able to reuse the= =20 > address thousands to millions of times. I could picture corporate=20 > cold-wallets using this technique, but maybe not retail wallets. > On Friday, April 17th, 2026 at 6:38 PM, Matt Corallo < > lf-l...@mattcorallo.com> wrote: > > > > On Apr 17, 2026, at 18:04, Ethan Heilman wrote: > > =EF=BB=BF > > > We've been trying to convince wallets to not reuse addresses for 15+=20 > years and have not only had no success, popular wallets have been activel= y=20 > migrating the opposite direction instead. > > There is a huge difference between, we would prefer you don't reuse=20 > addresses because privacy loss although privacy is hard to maintain anywa= ys=20 > and if you reuse addresses in this context a CRQC may steal your user's= =20 > funds. > > Wallets are likely to be more responsive here than in the past because th= e=20 > stakes are much higher. > > > More, maybe. But I think you=E2=80=99re drastically underestimating to wh= at extent=20 > address reuse is baked into many flows. > > For example most funds or very large holders have a pre-defined list of= =20 > addresses that they=E2=80=99re allowed to send to (basically exchange acc= ounts to=20 > sell), and have processes in place to ensure everyone cross validates tha= t=20 > the address is on the list. > > Yes, it=E2=80=99s possible to redo these, but people won=E2=80=99t, they= =E2=80=99ll just presume=20 > that they can move the funds again before a CRQC. And many of them can, o= f=20 > course - the large funds probably would be about to move in a few days or= =20 > weeks - but I=E2=80=99m quite confident it=E2=80=99ll get normalized pret= ty quickly=E2=80=A6 > > > 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=20 > those users preferred to use insecure wallets, you still protected 99% of= =20 > the other P2MR coins. > > > Yes but we=E2=80=99re still back to square one - there=E2=80=99s still wa= llets relying on=20 > a disable-EC soft fork before a CRQC. > > I am NOT suggesting or proposing this, but one could require that any P2M= R=20 > output whose EC pubkey has been leaked on-chain due to address reuse can= =20 > only be spent through the quantum safe leaf. If the community decides thi= s=20 > is wallets advertising PQ functionality aren't actually PQ safe because= =20 > this allow address reuse then one could solve the address reuse problem i= n=20 > this manner. > > > Yes, i mean I think P2MR would be way more exciting if we had an efficien= t=20 > way to enforce addresses as single use directly in consensus. I=E2=80=99m= not,=20 > however, aware of one. > > All told, it seems better to communicate to wallets and users that wallet= s=20 > which allow EC address reuse aren't PQ safe. If a wallet doesn't want to= =20 > provide PQ safety why would they put in the engineering effort to support= =20 > P2MR and PQ sigs.=20 > > > Because there will be marketing for =E2=80=9CPQ safe=E2=80=9D and no one = (but us) will=20 > actually care about the distinction or bugs :). > > Matt > > On Fri, Apr 17, 2026, 17:02 Matt Corallo wrote: > >> >> >> On 4/16/26 1:34 PM, conduition wrote: >> > Hi List, >> >=20 >> >> Fundamentally, it seems to me the most reasonable goal is that we=20 >> should be seeking to increase the number of coins which are reasonably= =20 >> likely to be secured by the time a CRQC exists. Put another way, we shou= ld=20 >> be seeking to minimize the chance that the Bitcoin community feels the n= eed=20 >> to fork to burn coins by reducing the number of coins which can be stole= n=20 >> to the minimum number [1]. >> >=20 >> > I think that's a reasonable goal which we all share, but is not the=20 >> only goal. Real-life isn't about min-maxing a single metric of success. >> >=20 >> > For instance, imagine we deploy P2TRv2, and we get EVERYONE to migrate= =20 >> to it before a CRQC appears. We maxed out our stated success metric. But= we=20 >> might not disable P2TRv2 key-spending in a timely manner. If the future= =20 >> community fails to deploy at the right time, a CRQC can steal at least a= s=20 >> much bitcoin as they could've before the migration, if not more. We maxe= d=20 >> out our success metric but still failed, so that metric must not be our= =20 >> only goal. >> >=20 >> > That's why we should achieve your stated goal only as a consequence of= =20 >> a more general but less easily-quantifiable goal: to design an optimal,= =20 >> flexible, and long-term-secure PQ migration path. If we standardize this= =20 >> and make code available to help, migration will come as a natural=20 >> consequence, as will other desirable goals like "not letting a CRQC scre= w=20 >> us all over", and "enabling long-term cryptographic agility". >> >> Sure, there are limitations of the goal as I stated, but your suggested= =20 >> alternative here isn't=20 >> actually a concreate goal. "optimal, flexible, and long-term-secure"=20 >> isn't something we can optimize=20 >> for :) >> >> > If we can agree on that, then any further disagreement will be due to = a=20 >> difference of opinion as to what is "optimal" or "flexible", and the=20 >> correct trade-offs to make on security. We all weigh different propertie= s=20 >> with different values. >> >=20 >> > For instance, I put more weight on conclusive security of P2MR, wherea= s=20 >> 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=20 >> requirement for P2MR. We've been=20 >> trying to convince wallets to not reuse addresses for 15+ years and have= =20 >> not only had no success,=20 >> popular wallets have been actively migrating the opposite direction=20 >> instead. In the face of address=20 >> reuse, P2MR has zero advantages over P2TRv2. >> >> > There are also differences of faith. Matt puts more faith in the futur= e=20 >> community to activate follow-up soft forks. I put more faith in wallet= =20 >> developers following standards and in users proactively migrating to=20 >> PQ-safe wallets. >> >=20 >> > Based on Matt's previous emails, I think we both share the same LACK o= f=20 >> faith that a majority of the UTXO set will migrate in time, and we also= =20 >> share the goal of mitigating that. >> >=20 >> >=20 >> >> This naturally means focusing on the wallets which are the *least=20 >> likely* to migrate or otherwise get themselves in a safe spot. Focusing = on=20 >> those who are the most likely to migrate does almost nothing to move the= =20 >> needle on the total number of coins protected, nor, thus, on the=20 >> probability of a future Bitcoin community feeling the need to burn coins= . >> >=20 >> > Also agreed. >> >=20 >> >=20 >> > I didn't find any public statements from your cited examples about=20 >> quantum security posture. Since it seems important to understand the=20 >> wallets' stances in this dilemma, I posted a tweet tagging 8 major=20 >> multi-chain wallets [2] including the 3 wallets you cited as examples. I= 'm=20 >> curious what they'll say. >> >=20 >> > Having worked with such wallets before, my expectation is that they'll= =20 >> follow whatever is standardized, as long as it gives them more market sh= are=20 >> and as long as they can "npm install whatever" to implement it. I'm not= =20 >> trivializing here - These devs are just spread much thinner than those= =20 >> building single-chain wallets. >> >> Sure but no new key scheme is going to be an "npm install whatever" - it= =20 >> requires a rewrite of a=20 >> bunch of key derivation and backup schemes. P2MR is also asking them to= =20 >> overhaul a UX decision they=20 >> made with lots of user feedback on top of that. >> >> > The harder question to answer is whether the major wallets make the PQ= =20 >> output type the default for receiving Bitcoin. Big software companies ar= e=20 >> typically very concerned about bugs in new code paths, and they weigh th= is=20 >> risk against the benefits of any new feature. When deploying new feature= s=20 >> as default, they often do so using A/B testing and incremental rollout= =20 >> techniques. So the earlier question shouldn't be binary. It becomes: How= =20 >> quickly will major wallets roll out PQ outputs as default? >> >> Fair, true point. >> >> > Rollout pace will depend on the personal views of the wallets'=20 >> corporate executives and technical advisors. They will weigh the risk of= =20 >> introducing new, riskier, less-efficient code paths against the risk of = a=20 >> CRQC appearing in the near future. We and other users can try to lobby= =20 >> them, but ultimately each wallet's decision makers must eventually convi= nce=20 >> themselves the CRQC risk is greater. Some will move too slowly, and many= =20 >> will likely regret their choices one way or another. >> >=20 >> > I believe we cannot effectively optimize away a problem like this by= =20 >> tempting decision-makers with slightly lower fees, since that's not all= =20 >> they are worried about. I believe we especially should not try to do so = at=20 >> the expense of conclusive PQ security and long-term optimization. >> >=20 >> > I think the crux of the P2TRv2 vs P2MR disagreement here is that Matt= =20 >> believes P2TRv2 will induce wallets to roll out default PQ outputs=20 >> meaningfully faster than P2MR would, and that this trumps arguments abou= t=20 >> post-quantum security or efficiency. >> >> No, its far from just about fees. Its also about maintaining the goals= =20 >> that we had going into=20 >> taproot. And a bit that P2MR doesn't accomplish anything unless much of= =20 >> the ecosystem changes their=20 >> processes substantially. >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/600f95eb-04e8-470d-b6df-cf7= 25e48d1b5%40mattcorallo.com >> . >> > > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/sMhLbmV30g91LFREGHE2JfcnoPYA= OeUXZpOdeP7rY7aqBDpx0BP4avqHHKIu2JXU5ba5N2CgPDvxe_2lzDqHJsz9bsSInuaqZ5SSstr= FJsE%3D%40proton.me > . > > > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/kkdcg1Bo7GsRcpH5gDpfZ1WZR-ul= fI5JRUKFa8cWla7CaWGtbQxgcE-nGZBOQeXKpepfSh8eVhE-x2-fOXExE9x2b2V21m6kact8e4C= SzNQ%3D%40protonmail.com > . > > > --=20 > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/_3mqxJvqmo5uwzca07-KxjxELdI5= NAL0rajqITUDVdVdSojG1ajcTYOZdlmbnQCOUKsxGEj8onXRUvaTXW4g_gH9qZvIvpY1ZHZkpgp= aoXs%3D%40proton.me > . > > > > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= c4424995-59d5-43b1-85d7-0390f89fede0n%40googlegroups.com. ------=_Part_134387_771098129.1780006392229 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gosh, what a ton of words have been spilled on this. xD

Address = re-use has serious privacy implications, and it should be discouraged if fo= r no other reason than that. Of course, users are free to re-use addresses = if they really want to.

As for bitcoin outputs, users have = the option to use P2TR today and into the future, for as long as they want.= It is a very good option.

At some point, some u= sers may decide they no longer trust the security of the key-path spend and= perhaps even ECC signatures generally. Those users might wish to retain th= e flexibility of the script-tree functionality from P2TR and get rid of the= overhead from the ECC key-path spend that they no longer trust (and possib= ly can't even use). For these users P2MR is a superior option. P2TRv2 just = gets us to this same point in a different way and while retaining the afore= mentioned cruft. There is fundamentally no difference in privacy or in secu= rity between a P2TRv2 output and P2MR output in the limit, if one assumes t= hat a CRQC one day exists. P2TRv2 is simply larger and more expensive. P2TR= v2 also tries to time Q-day, which is a fools errand. Far better to simply = provide the better option and allow users and wallets to decide for themsel= ves when to switch.=C2=A0

In the world where Q-day comes, then r= ational actors use some Taproot-esque script-path spending output with a di= sabled key-path (P2MR or P2TRv2), or maybe they use another script-based, h= ashed output type. In such a world, P2MR is objectively more economical tha= t P2TR/P2TRv2, it is PQ-resistant right from day one, smaller, and doesn't = sacrifice on privacy or security. If that world never materializes, then P2= TR remains the superior solution that it is today.

It is a supre= me irony that this argument is occurring between proponents of P2TRv2 who w= ant to disable (and for some reason retain) the key-path spend of Taproot a= nd proponents of BIP-360, which is a literal copypasta of Taproot with the = key-path spend hacked out of it.=C2=A0

be well,
Louise= =C2=A0

On Thursday, May 21, 2026 at 12:17:56=E2=80=AFPM UTC-6 conduition = wrote:
Hi Antoine,

My point is that Taproot incentivizes users of advanced con= tracts to make their Script usage indistinguishable from other usages.
<= span>
I th= ink 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 mu= st 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. The= n they'd have a script tree with just a single spending path for some c= omplex and easily-fingerprintable script which reduces their and everyone e= lse's anonymity set. I'll call this the 'single-leaf' patte= rn.

I have three arguments against th= is point as a justification for P2TRv2:

  1. The number of people who are going to fit into t= his 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 efficien= t 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 wou= ld be. Though this rules out extraneous factors like development effort, bu= t still I expect the incentivized demographic will be tiny.

    1. This property ca= n 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 neve= r appear. You're framing this property as a negative because of the pri= vacy implications, but we should consider the positives as well.
    <= div>
    Finally, compared to the integr= ity of the UTXO set, this is a bikeshed-level design goal. If we have to ri= sk the security of=C2=A0everyone's=C2=A0coins, and = commit ourselves to perfectly timing a follow-up soft-fork that disables P2= TRv2 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?=C2=A0This way, the user=C2=A0must=C2=A0= 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 stru= cture of P2TR's non-optional key-spend path.

<= /div>
99% of users (those building P2MR addresses properly) would n= ot be affected by this change anyway, because quantum-resistant hybrid addr= esses would be the specified standard for consumer wallets, and those walle= ts would already have at least two script leaves.=C2=A0The 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 conce= rn about incentives?

regards,<= /div>conduition
On Wednesday, May 20th, 2026 at 12:49 PM, Antoine Poinsot <daro...@protonmail.com> wrote:=
Hi C= onduition,
=
My poi= nt is that Taproot incentivizes users of advanced contracts to make their S= cript usage indistinguishable from other usages. I believe this is a desira= ble 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 th= e internal key in Taproot script path spends. This does two things:
  • <= span>this preemptively abandons some of the benefits of Taproot;
  • this makes any future s= oft 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 propert= ies, like P2TRv2, are preferable.

Best,
Antoine=
On Tuesday, May 19th, 2026 at 10:04 PM, 'conduition' via Bi= tcoin Development Mailing List <bitco...@googlegroups.com> wrote:
Hi A= ntoine, thanks for chiming in.=C2=A0

There are additional drawbacks to P2MR as specified in the curren= t 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 presen= t when keypath is used, and incentivize using such keypath in the first pla= ce (i.e. "doing the right thing"). I don't think we should th= row 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 i= n-use with hybrid PQC, it will have the same practical privacy profile as P= 2TR prior to Q-Day, and an 'everyone-agrees' path using BIP340 keys= would still be almost as well-incentivized.

For a= nyone who does truly need the savings of key-path spending, P2TR still exis= ts and can be used. Nothing is being "thrown away" - you'd ju= st need to ensure that any coins on P2TR addresses are moved to P2MR before= Q-day.

Matt's arguing about maximizing the number of us= ers/utxos safely migrated, not share of supply, so i don't think this i= s a valid counterpoint. The=C2=A0Milton-Shikhelman report from July 2025 es= timated 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-reusi= ng 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 B= IP32 rescue protocols should be able to cover most of them, since most end-= users hold coins in BIP32 wallets.

=
regards,
conduition=C2=A0


On Monday, April 20th, 2026 at 3:51 PM, 'Antoine Poinsot' v= ia Bitcoin Development Mailing List <bitco...@googlegroups.com> wrote:
Hi C= onduition,
=
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 P2M= R. We've been=C2=A0trying to convince wallets to not reus= e addresses for 15+ years and have not only had no success, popular wallets= have been actively migrating the opposite direction instead. In the face o= f address=C2=A0reuse, P2MR has zero advantages over P2TRv2.

I think we agree that merely spec-ing out P2MR as &= quot;not safe to reuse" in a BIP will be insufficient to prevent all a= ddress reuse. We also agree that reused=C2=A0P2MR and P2TRv2 share t= he same security profile, with or without a future EC restriction (which ca= n 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 therefor= e 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 P= 2TRv2 and P2MR are wildly different and you are only taking a subset of P2M= R'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 saving= s of P2TRv2 key-spending outweighs the safety of the (presumed) tiny minori= ty of users who actually use P2MR properly.

There are additional drawbacks to P= 2MR as specified in the current version of BIP360. Bitcoin users activated = Taproot a little over 5 years ago, whose stated benefits include indistingu= ishable outputs between users of Script paths and non-Script paths, hide wh= ether 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 ther= e are other ways of mitigating CRQC risks.

We have historical evid= ence this assumption won't hold. Take a look at Project Eleven's bitcoin risk list metrics dashboard. The volume o= f bitcoin exposed today due to address reuse is only a minority fraction of= the overall supply - about 5 million BTC at present. Still significant, bu= t not an overwhelming majority by any means. We have no reason to expect ev= eryone will suddenly start reusing addresses consistently with P2MR, at lea= st not any more than they already do.

Matt's arguing about maximizing the n= umber of users/utxos safely migrated, not share of supply, so i don't t= hink this is a valid counterpoint. The=C2=A0Milton-Shikhelman report = from July 2025 estimate= d over 60% of existing UTxOs reuse an address.

If any= thing, address-reuse will reduce, and not just because we ask them to. If y= ou look at the highest-value addresses at fault of address-reuse today, the= y 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-i= nterest - 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 P2= TRv2, and personally I think the safety delta between them is wide enough t= o excuse the minor handicap in P2MR's pre-quantum efficiency.

P2MR is also asking them to overhaul a= UX decision they=C2=A0made with lots of user feedback on top = of that.

That's fair, it would be a difficult chall= enge to some low-effort wallets not to receive coins to vulnerable addresse= s. But this argument implies EC spending on P2MR isn't restricted in ti= me - otherwise there is nothing to exploit when addresses are reused, and s= o address reuse wouldn't matter. Under this same implication, P2TRv2 fa= res even worse. Concretely:

  • If EC spending is restricted, then both P= 2MR and P2TRv2 have exactly the same security profile and address reuse doe= s not matter.=C2=A0
  • If EC spending isn'= ;t restricted, then both address formats are vulnerable when reused, and P2= TRv2 exposure is worse because even those who don't=C2=A0reuse a= ddresses are vulnerable.

In other words, P2MR is the Nash equilibrium of a prisoner's d= ilemma square [^1].=C2=A0

  • P2MR: addresses with hidden= EC spend paths are safe
  • P2TRv2: everyone is vulnerabl= e
  • P2MR with EC restriction: everyone is safe
  • P2TRv2 with EC restriction: everyone is safe

Whether EC restriction happens or not, you al= ways get the same or better security by choosing P2MR. EC restriction is th= e only step which can secure reused addresses of either P2MR or P2TRv2 [^2]= .

Thus, if you firmly beli= eve that many wallets will reuse addresses and want to mitigate the vulnera= bility 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-restr= icting 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: t= he only difference between P2MR and P2TRv2 there is that P2TRv2 needs a = future soft fork to restrict EC spending, while with P2MR this is optio= nal, but still desirable (since some wallets will mistakenly reuse addresse= s either way).

regards,
conduition
=

[^1]: You can expand that prisoner's di= lemma 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 o= r without EC restriction - because of its better script-path efficiency.

=
[^2]:=C2=A0For those rare few wallets who are: (1) w= illing to upgrade, (2) NOT willing to use fresh addresses, and (3) NOT will= ing 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 cos= t 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 corporat= e cold-wallets using this technique, but maybe not retail wallets.
On Friday, April 17th, 2026 at 6:38 PM, Matt Corallo <lf-l...@mattcorallo.co= m> wrote:


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

=EF=BB=BF

> 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, w= e would prefer you don't reuse addresses because privacy loss although = privacy is hard to maintain anyways and if you reuse addresses in this cont= ext a CRQC may steal your user's funds.

Wallets are likely to be more responsive here than in t= he past because the stakes are much higher.
<= div>
More, maybe. But I think you=E2=80=99re drastically unde= restimating to what extent address reuse is baked into many flows.

For example most funds or very large holders have a pre-de= fined list of addresses that they=E2=80=99re 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.

Y= es, it=E2=80=99s possible to redo these, but people won=E2=80=99t, they=E2= =80=99ll 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 m= ove in a few days or weeks - but I=E2=80=99m quite confident it=E2=80=99ll = get normalized pretty quickly=E2=80=A6

<= div dir=3D"ltr">
> In the face of add= ress reuse, P2MR has zero advantages over P2TRv2.
It's not binary. If say 1% of coins in P2MR h= ave address reuse because those users preferred to use insecure wallets, yo= u still protected 99% of the other P2MR coins.

Yes but we=E2=80=99re still back to square one - ther= e=E2=80=99s still wallets relying on a disable-EC soft fork before a CRQC.<= /div>
I am NOT suggesting or proposing this, but one could require t= hat 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 de= cides this is wallets advertising PQ functionality aren't actually PQ s= afe 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=E2=80=99m n= ot, however, aware of one.

All told, it seems better to commun= icate to wallets and users that wallets which allow EC address reuse aren&#= 39;t PQ safe. If a wallet doesn't want to provide PQ safety why would t= hey put in the engineering effort to support P2MR and PQ sigs.=C2=A0
<= /div>

Because there will be marketing= for =E2=80=9CPQ safe=E2=80=9D and no one (but us) will actually care about= the distinction or bugs :).

Matt

On Fri, Apr 17, 2026, 17:02 Matt Corallo <lf-l...@mattcora= llo.com> 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 like= ly to be secured by the time a CRQC exists. Put another way, we should be s= eeking 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 t= he minimum number [1].
>
> I think that's a reasonable goal which we all share, but is not th= e only goal. Real-life isn't about min-maxing a single metric of succes= s.
>
> 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 w= e might not disable P2TRv2 key-spending in a timely manner. If the future c= ommunity fails to deploy at the right time, a CRQC can steal at least as mu= ch 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 on= ly goal.
>
> That's why we should achieve your stated goal only as a consequenc= e 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 consequen= ce, as will other desirable goals like "not letting a CRQC screw us al= l over", and "enabling long-term cryptographic agility".

Sure, there are limitations of the goal as I stated, but your suggested alt= ernative here isn't
actually a concreate goal. "optimal, flexible, and long-term-secure&qu= ot; 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 differ= ent properties with different values.
>
> For instance, I put more weight on conclusive security of P2MR, wherea= s 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 requireme= nt for P2MR. We've been
trying to convince wallets to not reuse addresses for 15+ years and have no= t 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 futur= e community to activate follow-up soft forks. I put more faith in wallet de= velopers following standards and in users proactively migrating to PQ-safe = wallets.
>
> Based on Matt's previous emails, I think we both share the same LA= CK of faith that a majority of the UTXO set will migrate in time, and we al= so 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 ne= edle 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 walle= ts' stances in this dilemma, I posted a tweet tagging 8 major multi-cha= in wallets [2] including the 3 wallets you cited as examples. I'm curio= us what they'll say.
>
> Having worked with such wallets before, my expectation is that they= 9;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 thinne= r than those building single-chain wallets.

Sure but no new key scheme is going to be an "npm install whatever&quo= t; - it requires a rewrite of a
bunch of key derivation and backup schemes. P2MR is also asking them to ove= rhaul 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 a= s default, they often do so using A/B testing and incremental rollout techn= iques. So the earlier question shouldn't be binary. It becomes: How qui= ckly will major wallets roll out PQ outputs as default?

Fair, true point.

> Rollout pace will depend on the personal views of the wallets' cor= porate executives and technical advisors. They will weigh the risk of intro= ducing new, riskier, less-efficient code paths against the risk of a CRQC a= ppearing in the near future. We and other users can try to lobby them, but = ultimately each wallet's decision makers must eventually convince thems= elves the CRQC risk is greater. Some will move too slowly, and many will li= kely regret their choices one way or another.
>
> I believe we cannot effectively optimize away a problem like this by t= empting 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 meaningf= ully faster than P2MR would, and that this trumps arguments about post-quan= tum 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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoin= dev/600f95eb-04e8-470d-b6df-cf725e48d1b5%40mattcorallo.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/sMhLbmV3= 0g91LFREGHE2JfcnoPYAOeUXZpOdeP7rY7aqBDpx0BP4avqHHKIu2JXU5ba5N2CgPDvxe_2lzDq= HJsz9bsSInuaqZ5SSstrFJsE%3D%40proton.me.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/kkdcg1Bo7GsRcpH5gDpfZ1WZR-ulfI5JRUKFa8cWla7CaWGtbQxgcE-nGZBOQeXKpepfSh8e= VhE-x2-fOXExE9x2b2V21m6kact8e4CSzNQ%3D%40protonmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/_3mqxJvq= mo5uwzca07-KxjxELdI5NAL0rajqITUDVdVdSojG1ajcTYOZdlmbnQCOUKsxGEj8onXRUvaTXW4= g_gH9qZvIvpY1ZHZkpgpaoXs%3D%40proton.me.


--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/c4424995-59d5-43b1-85d7-0390f89fede0n%40googlegroups.com.
------=_Part_134387_771098129.1780006392229-- ------=_Part_134386_864842122.1780006392229--