From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 18 Apr 2026 08:59:24 -0700 Received: from mail-oo1-f57.google.com ([209.85.161.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wE84o-0002wv-AR for bitcoindev@gnusha.org; Sat, 18 Apr 2026 08:59:24 -0700 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-6853c2438b9sf3173712eaf.3 for ; Sat, 18 Apr 2026 08:59:22 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776527956; cv=pass; d=google.com; s=arc-20240605; b=Ummi7Xha6N4zCD9cbrexvFIv9ITe1DwM98fxI04NQ35RtT5OSBFWgzEnlI7l1/o8Xg I3c0eYeSIuyVHfSLzvA1q0+INpvIR3xqVW4bkrfJfH3IPXBJ3SpyrYB+B2Uwzr7vZTkQ edFd9IfmTGtR7tWawLDuV23Q8pR4ikPXAAnYpJrpE+2qGp9g7Ei6hytqaSRQDSj/dSLJ bP7fXWm2YspapceNMcXz4o8yIZHvlqSxblDKSXr6yrMdeYm42ipGVOKvS9GW/Qz9VpQF pLBOEJfeHEuINRE6vs+LxC6r/x1bc75Rh4lTApHUzAYTQW+JzCp30dQoHIdeWe4yF59i 6DGg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=dfCr/zK8V2Th3CrL9W4tMail7pFrVyWiqwiNaOoSIzs=; fh=1LVVe5neXEYnTT2ZcmAMAjpn0hmh5gLKTfCwxaMdNcg=; b=f+NgNZUaFhP61aqNZbvtv6OehGFGTvw/N/WCiH7KJdMOgk+dG0tJGhoRXJyMYkpplt 0fOLLs0R/qbeWf+bNe7PAWMlSdrOSo6TnXzjoACHghVGb1Dhn5Rw/7AMgcyimQOMzHjK MgusObMf9l8LFwUrzQAaE/J437Faa/BvNTwrF+iDa3H5S0v+/tzFr+wbwwUVlVRIbWSK PhOBiKPXgDKQ4fCyF5006OoGcuiSL4dPtf00bdL2xHeV7Hfe4+F7xWCQ1uKITsWB5e69 HkeZNvRfeKH4CqAnPwW9pVDBiTQjfRw+ZGuG0O8HiaUq3U4ZgWugx7ysUBx9WkniO0Rv 5wLA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=lri4RMfk; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.101 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776527956; x=1777132756; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=dfCr/zK8V2Th3CrL9W4tMail7pFrVyWiqwiNaOoSIzs=; b=Zsd9ekNCaWG9XXuh2eS3/sSlshbAGLk/LTjt/KiEqCQH9GVyvYzYrpQKNaYs3Vfsyc Wb1jgEoREiDndcTFdbXpuuixWerFT7dAq/4m6VYAazp+RqDEwQ1VkQfmt4r8JMGMeGEQ inUq0uhYXqJjPftf0g9yU3MlpJs6Xj8od6GZ2hLzjSptDkM69M2H2Fgm2aekwqs77zD2 r7BtTGJj5GSFAFoFuCDKvpsmLFG0B3uRRkiTK5CnyfCqMgO+Rw0ZYEB19H8Zx4/a5oAL HvQULjGMnCwOMR8gWW6yTlIYtfsZjor2X8G/jRIT1bgTbJXjhmRhf68ATpMHvs1HQ+Td gvKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776527956; x=1777132756; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dfCr/zK8V2Th3CrL9W4tMail7pFrVyWiqwiNaOoSIzs=; b=JVVgsYk39sITg74Tu+1rGoabZf/ZrjeMg+0nntlmWTajDWxs2xILkxJzzml5mFHKB1 azOcRiJxsdLDZfrlSrzLSdZH+0xLN3bweAcy2nmfKu/HYUhKlotsFgiuub3fHBQl8ENt GuS+O6ENhMYaJjJNKU3+866Ql+aqToEy/eMC/htdhjUWqU+tktLaAYUnPisS9QXuFEmN CGLs8wJCpLYhA7DEKro8hboWas/BvSOS970bUC593DkyoCWfOgiWQfoEpLlGonWehn6s lDaz7cam7tEgdw4vpWx3b1dPZQhCUtMdo0qBufN89DVBwO0eQ+mfnnDEPxQyhYI5SGtv m1cQ== X-Forwarded-Encrypted: i=2; AFNElJ+rG5MrhbhTAYVJB3ZANjua+xB4/sou/OhSg3nqE+suGH+RUCI1FoD6LZR++EFgA2Voz49KBcNk9WnK@gnusha.org X-Gm-Message-State: AOJu0YzFAbXmdIVW5sPGfkcOMgwqSTTmVQdXqp5NoXLI11zou9smMquL zMp7Lg4H/HakhZJ030cSslIKu9gWcLNb3znbJoX21Ds7hmdxWsTaICrX X-Received: by 2002:a05:6820:3097:b0:67e:dab:7cf3 with SMTP id 006d021491bc7-69462c22471mr4092536eaf.0.1776527956006; Sat, 18 Apr 2026 08:59:16 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiLShOQULzNDkO+jq1a5VzqiJFifnWpEllGg19QlbuWpgw==" Received: by 2002:a05:6820:2213:b0:681:a657:a767 with SMTP id 006d021491bc7-6943c7e1fa2ls1544170eaf.1.-pod-prod-05-us; Sat, 18 Apr 2026 08:59:10 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ9rsX/ws8eucNbrhl15LxSf0WrHmSGNnerOC0v7bqYqyJmItgA3GVNwYEjLx+ua/Agpo40I6ho00oXB@googlegroups.com X-Received: by 2002:a05:6808:2381:b0:467:9ca:4b8a with SMTP id 5614622812f47-4799c937f6emr3770908b6e.11.1776527950731; Sat, 18 Apr 2026 08:59:10 -0700 (PDT) Received: by 2002:ab3:5e87:0:b0:2f6:91ae:47ef with SMTP id a1c4a302cd1d6-2f8b07088dfmsc7a; Sat, 18 Apr 2026 08:44:26 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ/gxLlrq1aP1iBFRUne40spVX2nATdVwA3JvItprdaG7vDzlT+z3vk30JYEk6TyYMdqL4PrzrMRH7YG@googlegroups.com X-Received: by 2002:a05:6512:1389:b0:5a4:4ea:9977 with SMTP id 2adb3069b0e04-5a4172b7a30mr3085323e87.8.1776527064824; Sat, 18 Apr 2026 08:44:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776527064; cv=none; d=google.com; s=arc-20240605; b=TZsA15xfhW9+XTSSyWlIyJdI6izxtkgZ2gR/vXGFe53rSS7N0zCHEdm8oPIR9mAoah 5lFBjggJ+JFw13oPf+tGsK4UZjhc6QAIigorMh3ahoPHqJ6JnsFw6ma/Wr2ZpU7LEwYr zpX0YJ917FKxQtNdiluvcTCbh3XbuldZ0Xipwlc86Vu8sZRplT46WnSLjEtQyC292kKO FglOwzsgVig22iaRKZRw+1BXWW08CDsu+1cQ8hgZV6/M/+oYoP2vI0dUyTuMNUSsslfg SR5EX8/lKossuydtZ8PiA9+y3pM/378dmDjiG2CysEA2EJX9dfIs1yzQ1CkLF2lCBJdi Lubg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=uwNdBi+iOUN9X2cZIg1mvdty5mQBkSSYaiAq8t7YqD8=; fh=Zx4A60ukjp0cUYPpa6G/R9KgTfY6PyDKNzahPHW/bC4=; b=NAVFJcXjq8pgu2YOOTP8pz0LrGFZzUWAUHjH+N6bgW+3xU0Cr/3fjFhVvWl5VVf60C H8U2u6M2foCdZnB6VCm9SRFK8yVCVFlXxNBl4wEkXdetTU56y4Y8KB31Ytmd2Q3wjWdZ cJNos8NyQez4JolyYvq+UfQUam0DutdKfykjODlX0jv+wBiB6vZ5pVEVl4/0wF2m3xq5 ajaWikh4OPm1cQPFbpcUxNFNBIOvYmnHLKxe55alRd7Vb1KxxzV1BvzWu/R12S7VPunn prfNKkrpn78Ec7EGHMqQbmGcmOUDykUPOIVE70QnZjdIVp+pQAIw0PMj0Yty9Be9edeW JmjQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=lri4RMfk; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.101 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-106101.protonmail.ch (mail-106101.protonmail.ch. [79.135.106.101]) by gmr-mx.google.com with ESMTPS id 2adb3069b0e04-5a4187d7a5esi73098e87.6.2026.04.18.08.44.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Apr 2026 08:44:24 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.101 as permitted sender) client-ip=79.135.106.101; Date: Sat, 18 Apr 2026 15:44:18 +0000 To: Matt Corallo From: "'conduition' via Bitcoin Development Mailing List" Cc: Ethan Heilman , Erik Aronesty , bitcoindev@googlegroups.com Subject: Re: [bitcoindev] PQC - What is our Goal, Even? Message-ID: In-Reply-To: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 7501f383ac64fcb37a86b6e5a3eee2182e1a1858 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------808ba3a7a6bb7896e7d3d66a64c7bb9ea76dbbf014d9dab8ce37c254e5fe33f9"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=lri4RMfk; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.101 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition 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: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------808ba3a7a6bb7896e7d3d66a64c7bb9ea76dbbf014d9dab8ce37c254e5fe33f9 Content-Type: multipart/mixed;boundary=---------------------24ed6232ecac05e8632d4f071a0085e7 -----------------------24ed6232ecac05e8632d4f071a0085e7 Content-Type: multipart/alternative;boundary=---------------------e267dd95b18334c0d1b823c0e4ec43bd -----------------------e267dd95b18334c0d1b823c0e4ec43bd Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > I think I maybe under-stated my concern over the no-address-reuse require= ment for P2MR. We've been=C2=A0trying to convince wallets to not reuse addr= esses for 15+ years and have not only had no success, popular wallets have = been actively migrating the opposite direction instead. In the face of addr= ess=C2=A0reuse, 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 r= eused=C2=A0P2MR 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 thi= s 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 diffe= rent 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 th= at 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-s= pending outweighs the safety of the (presumed) tiny minority of users who a= ctually use P2MR properly. We have historical evidence this assumption won't hold. Take a look at Proj= ect Eleven's bitcoin risk list metrics dashboard. The volume of bitcoin exp= osed 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 over= whelming majority by any means. We have no reason to expect everyone will s= uddenly start reusing addresses consistently with P2MR, at least not any mo= re than they already do. If anything, address-reuse will reduce, and not just because we ask them to= . If you look at the highest-value addresses at fault of address-reuse toda= y, they are mostly corporate cold wallets: binance, robinhood, bitfinex, te= ther, 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 the= y fail to do so. So yes, even after taking address reuse into account, P2MR is more secure t= han P2TRv2, and personally I think the safety delta between them is wide en= ough to excuse the minor handicap in P2MR's pre-quantum efficiency. > P2MR is also asking them to overhaul a UX decision they=C2=A0made with lo= ts of user feedback on top of that. That's fair, it would be a difficult challenge to some low-effort wallets n= ot to receive coins to vulnerable addresses. But this argument implies EC s= pending on P2MR isn't restricted in time - otherwise there is nothing to ex= ploit when addresses are reused, and so address reuse wouldn't matter. Unde= r this same implication, P2TRv2 fares even worse. Concretely: - If EC spending is restricted, then both P2MR and P2TRv2 have exactly th= e same security profile and address reuse does not matter.=C2=A0 - If EC spending isn't restricted, then both address formats are vulnerab= le when reused, and P2TRv2 exposure is worse because even those who don't= =C2=A0reuse addresses are vulnerable. =20 In other words, P2MR is the Nash equilibrium of a prisoner's dilemma square= [^1].=C2=A0 - 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 se= curity by choosing P2MR. EC restriction is the only step which can secure r= eused 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 tha= t P2TRv2 needs a future soft fork to restrict EC spending, while with P2MR = this is optional, but still desirable (since some wallets will mistakenly r= euse addresses either way). regards, conduition [^1]: You can expand that prisoner's dilemma square into a cube by asking w= hether 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 o= f its better script-path efficiency. [^2]:=C2=A0For 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 hybr= id address formats which use ECC and hash-based sigs in the same locking sc= ript. 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 byt= es 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 techn= ique, but maybe not retail wallets. On Friday, April 17th, 2026 at 6:38 PM, Matt Corallo wrote: >=20 >=20 >=20 > > On Apr 17, 2026, at 18:04, Ethan Heilman wrote: >=20 > > =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. > >=20 > > There is a huge difference between, we would prefer you don't reuse add= resses because privacy loss although privacy is hard to maintain anyways an= d if you reuse addresses in this context a CRQC may steal your user's funds= . > >=20 > > Wallets are likely to be more responsive here than in the past because = the stakes are much higher. >=20 >=20 > More, maybe. But I think you=E2=80=99re drastically underestimating to wh= at extent address reuse is baked into many flows. >=20 > For example most funds or very large holders have a pre-defined list of a= ddresses that they=E2=80=99re allowed to send to (basically exchange accoun= ts to sell), and have processes in place to ensure everyone cross validates= that the address is on the list. >=20 > Yes, 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 t= o move in a few days or weeks - but I=E2=80=99m quite confident it=E2=80=99= ll get normalized pretty quickly=E2=80=A6 >=20 >=20 > > > In the face of address reuse, P2MR has zero advantages over P2TRv2. > >=20 > > 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 t= he other P2MR coins. >=20 >=20 > Yes but we=E2=80=99re still back to square one - there=E2=80=99s still wa= llets relying on a disable-EC soft fork before a CRQC. >=20 >=20 > > I am NOT suggesting or proposing this, but one could require that any P= 2MR output whose EC pubkey has been leaked on-chain due to address reuse ca= n only be spent through the quantum safe leaf. If the community decides thi= s is wallets advertising PQ functionality aren't actually PQ safe because t= his allow address reuse then one could solve the address reuse problem in t= his manner. >=20 >=20 > Yes, i mean I think P2MR would be way more exciting if we had an efficien= t way to enforce addresses as single use directly in consensus. I=E2=80=99m= not, however, aware of one. >=20 >=20 > > All told, it seems better to communicate to wallets and users that wall= ets which allow EC address reuse aren't PQ safe. If a wallet doesn't want t= o provide PQ safety why would they put in the engineering effort to support= P2MR and PQ sigs.=C2=A0 >=20 >=20 > 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 :). >=20 > Matt >=20 >=20 > > On Fri, Apr 17, 2026, 17:02 Matt Corallo wro= te: > >=20 > > >=20 > > >=20 > > > 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 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 migr= ate to it before a CRQC appears. We maxed out our stated success metric. Bu= t we might not disable P2TRv2 key-spending in a timely manner. If the futur= e 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 onl= y 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 a= nd make code available to help, migration will come as a natural consequenc= e, as will other desirable goals like "not letting a CRQC screw us all over= ", and "enabling long-term cryptographic agility". > > >=20 > > > Sure, there are limitations of the goal as I stated, but your suggest= ed alternative here isn't > > > actually a concreate goal. "optimal, flexible, and long-term-secure" = isn't something we can optimize > > > for :) > > >=20 > > > > 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 c= orrect trade-offs to make on security. We all weigh different properties wi= th different values. > > > > > > > > For instance, I put more weight on conclusive security of P2MR, whe= reas Matt puts more weight on fee-efficiency and "privacy" of P2TRv2 [^1]. > > >=20 > > > I think I maybe under-stated my concern over the no-address-reuse req= uirement for P2MR. We've been > > > trying to convince wallets to not reuse addresses for 15+ years and h= ave not only had no success, > > > popular wallets have been actively migrating the opposite direction i= nstead. In the face of address > > > reuse, P2MR has zero advantages over P2TRv2. > > >=20 > > > > There are also differences of faith. Matt puts more faith in the fu= ture community to activate follow-up soft forks. I put more faith in wallet= developers following standards and in users proactively migrating to PQ-sa= fe wallets. > > > > > > > > Based on Matt's previous emails, I think we both share the same LAC= K of faith that a majority of the UTXO set will migrate in time, and we als= o 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 wallet= s' stances in this dilemma, I posted a tweet tagging 8 major multi-chain wa= llets [2] including the 3 wallets you cited as examples. I'm curious what t= hey'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 s= hare and as long as they can "npm install whatever" to implement it. I'm no= t trivializing here - These devs are just spread much thinner than those bu= ilding single-chain wallets. > > >=20 > > > 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. > > >=20 > > > > The harder question to answer is whether the major wallets make the= PQ output type the default for receiving Bitcoin. Big software companies a= re typically very concerned about bugs in new code paths, and they weigh th= is risk against the benefits of any new feature. When deploying new feature= s as default, they often do so using A/B testing and incremental rollout te= chniques. So the earlier question shouldn't be binary. It becomes: How quic= kly will major wallets roll out PQ outputs as default? > > >=20 > > > Fair, true point. > > >=20 > > > > Rollout pace will depend on the personal views of the wallets' corp= orate executives and technical advisors. They will weigh the risk of introd= ucing new, riskier, less-efficient code paths against the risk of a CRQC ap= pearing in the near future. We and other users can try to lobby them, but u= ltimately 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 b= y tempting decision-makers with slightly lower fees, since that's not all t= hey are worried about. I believe we especially should not try to do so at t= he expense of conclusive PQ security and long-term optimization. > > > > > > > > I think the crux of the P2TRv2 vs P2MR disagreement here is that Ma= tt believes P2TRv2 will induce wallets to roll out default PQ outputs meani= ngfully faster than P2MR would, and that this trumps arguments about post-q= uantum security or efficiency. > > >=20 > > > No, its far from just about fees. Its also about maintaining the goal= s that we had going into > > > taproot. And a bit that P2MR doesn't accomplish anything unless much = of the ecosystem changes their > > > processes substantially. > > >=20 > > > -- > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+unsubscribe@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/600f95eb-04e8-470d-b6df-cf725e48d1b5%40mattcorallo.com. --=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/= sMhLbmV30g91LFREGHE2JfcnoPYAOeUXZpOdeP7rY7aqBDpx0BP4avqHHKIu2JXU5ba5N2CgPDv= xe_2lzDqHJsz9bsSInuaqZ5SSstrFJsE%3D%40proton.me. -----------------------e267dd95b18334c0d1b823c0e4ec43bd Content-Type: multipart/related;boundary=---------------------ebcf60bc806e7c41d89d29f8b4b9f3b2 -----------------------ebcf60bc806e7c41d89d29f8b4b9f3b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think I maybe under-stated my concern over the no-address-reuse re= quirement for P2MR. We've been trying to convince wallet= s to not reuse addresses for 15+ years and have not only had no success, po= pular wallets have been actively migrating the opposite direction instead. = In the face of address reuse, P2MR has zero advantages ove= r 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 P2M= R and P2TRv2 share the same security profile, with or without a future EC r= estriction (which can be applied to either output type).

But we seem to dis= agree in our conclusions. You believe that because of this overlap in secur= ity 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 ove= rall security profile of P2TRv2 and P2MR are wildly different and you are o= nly 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 o= f the (presumed) tiny minority of users who actually use P2MR properly.

We have hi= storical evidence this assumption won't hold. Take a look at Project Eleven's bitcoin risk lis= t 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 add= resses consistently with P2MR, at least not any more than they already do.<= /div>

If anyt= hing, address-reuse will reduce, and not just because we ask them to. If yo= u look at the highest-value addresses at fault of address-reuse today, they= are mostly corporate cold wallets: binance, robinhood, bitfinex, tether, e= tc, 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-in= terest - 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 secur= e 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 wallet= s not to receive coins to vulnerable addresses. But this argument implies E= C 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. U= nder this same implication, P2TRv2 fares even worse. Concretely:

  • If EC spending is restricted, then both P2MR and P= 2TRv2 have exactly the same security profile and address reuse does not mat= ter. 
  • If EC s= pending isn't restricted, then both address formats are vulnerable when reu= sed, 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 i= s safe

Whether EC restricti= on happens or not, you always get the same or better security by choosing P= 2MR. EC restriction is the only step which can secure reused addresses of e= ither P2MR or P2TRv2 [^2].

Thus, if you firmly believe that many wallets will reuse addresses and wan= t to mitigate the vulnerability that follows, then the choice between outpu= t 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 BIP36= 1 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 th= at P2TRv2 needs a future soft fork to restrict EC spending, while wi= th P2MR this is optional, but still desirable (since some wallets will mist= akenly reuse addresses either way).

regards,
=
conduition

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

[^2]: For those rare few wallets= who are: (1) willing to upgrade, (2) NOT willing to use fresh addresses, a= nd (3) NOT willing to depend on future activation of an EC restriction, the= n 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 addre= sses at the cost of efficiency. With a stateful signature (e.g. XMSS/SHRINC= S), 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 c= orporate cold-wallets using this technique, but maybe not retail wallets.
On Friday, April 17th, 2026 at 6:38 PM, Matt Corallo <lf-lists@m= attcorallo.com> wrote:


On Apr 17, 2026, at 18:04, Ethan Heilman = <eth3rs@gmail.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 wal= lets have been actively migrating the opposite direction instead.

There is a huge difference betwee= n, 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 cont= ext a CRQC may steal your user's funds.

Wallets are likely to be more responsive here than in the p= ast because the stakes are much higher.
=
More, maybe. But I think you=E2=80=99re drastically underest= imating to what extent address reuse is baked into many flows.
For example most funds or very large holders have a pre-define= d list of addresses that they=E2=80=99re allowed to send to (basically exch= ange accounts to sell), and have processes in place to ensure everyone cros= s validates that 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 that they can move the funds again before a CRQC. And ma= ny of them can, of course - the large funds probably would be about to move= in a few days or weeks - but I=E2=80=99m quite confident it=E2=80=99ll get= normalized pretty quickly=E2=80=A6

> In the face of addres= s reuse, P2MR has zero advantages over P2TRv2.

<= /div>
It's not binary. If say 1% of coins in P2MR have add= ress reuse because those users preferred to use insecure wallets, you still= protected 99% of the other P2MR coins.
=
Yes but we=E2=80=99re still back to square one - there=E2=80= =99s 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 t= his 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 enfo= rce addresses as single use directly in consensus. I=E2=80=99m not, however= , aware of one.

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

Because there will be marketing for =E2=80=9CPQ sa= fe=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-lists@mattcorallo.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 the on= ly 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 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 only g= oal.
>
> 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, fl= exible, 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 alt= ernative 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 corr= ect 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, 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 LACK o= f faith that a majority of the UTXO set will migrate in time, and we also s= hare 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 qua= ntum security posture. Since it seems important to understand the wallets' = stances in this dilemma, I posted a tweet tagging 8 major multi-chain walle= ts [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 shar= e and as long as they can "npm install whatever" to implement it. I'm not t= rivializing here - These devs are just spread much thinner than those build= ing single-chain wallets.

Sure but no new key scheme is going to be an "npm install whatever" - it re= quires 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 quickly= will major wallets roll out PQ outputs as default?

Fair, true point.

> Rollout pace will depend on the personal views of the wallets' corpora= te executives and technical advisors. They will weigh the risk of introduci= ng new, riskier, less-efficient code paths against the risk of a CRQC appea= ring in the near future. We and other users can try to lobby them, but ulti= mately each wallet's decision makers must eventually convince themselves th= e CRQC risk is greater. Some will move too slowly, and many will likely reg= ret 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 "= Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@goo= glegroups.com.
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 &= 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/bitcoindev/sMhLbm= V30g91LFREGHE2JfcnoPYAOeUXZpOdeP7rY7aqBDpx0BP4avqHHKIu2JXU5ba5N2CgPDvxe_2lz= DqHJsz9bsSInuaqZ5SSstrFJsE%3D%40proton.me.
-----------------------ebcf60bc806e7c41d89d29f8b4b9f3b2-- -----------------------e267dd95b18334c0d1b823c0e4ec43bd-- -----------------------24ed6232ecac05e8632d4f071a0085e7 Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------24ed6232ecac05e8632d4f071a0085e7-- --------808ba3a7a6bb7896e7d3d66a64c7bb9ea76dbbf014d9dab8ce37c254e5fe33f9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmnjpsQJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmcsu89t9bdKK1W9tn9E4pJjfsCDK+MDM8E6eXNc lryG3BYhBEdIka0CMtrLdg13a3gpbO2E9rPFAADcrQEAjLldAwNPUXM/rbKh mWkeNKVdgr9LK1pwDXqgNHtJAtMBAOHcRHKoal5fPTXm6cHyTGgGSiPOL7mX MzRcb/syUEYN =MX6p -----END PGP SIGNATURE----- --------808ba3a7a6bb7896e7d3d66a64c7bb9ea76dbbf014d9dab8ce37c254e5fe33f9--