From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 18 Apr 2026 09:44:05 -0700 Received: from mail-ot1-f64.google.com ([209.85.210.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wE8m3-0003QT-Vp for bitcoindev@gnusha.org; Sat, 18 Apr 2026 09:44:05 -0700 Received: by mail-ot1-f64.google.com with SMTP id 46e09a7af769-7dbe11b1f03sf3930712a34.0 for ; Sat, 18 Apr 2026 09:44:03 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1776530637; cv=pass; d=google.com; s=arc-20240605; b=AWdTwOKOBiY0Xw12Im+Z1NsUloq4YPZAOP36VaK82zz0IOthFIswG26kLuKl6Vspm/ ONKgBNMFuQ4asQIo6sU3yBs6vc833X4LOiyO6EMlfguMJ15mMkUJkpM9AtQiEhgzsb4z QuyJ122sVqFNUnNYaIa5vPDwZovMqT3vL2fg1mRd0xvnTs3ejjO82gUZGGPsDhFcQ/0E 0rYTopyt19PX5iQlUw42s8IH5Aolrm0eqKWvog0N+y9toIsjKwcb3Yf4VfSGrkZXiNTG yLMU/ebrO4LTvi2Oj6l0BdT62+RcSlpidaocTGU4vzH/o6pK8cSmSl84feOgCng7ujS4 3EzA== ARC-Message-Signature: i=3; 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature; bh=4DCibTfujnwr+U4lh2s4FWfbA3MX0Q6u4ywOg/vMhko=; fh=WHVFnrPKV2ioqEiqCpc5pLU7qte2B/myyCGaB6L4BTs=; b=Qg4eQ0SlMzkYQopLm+t2gKy5QflLOq2X62SIb3lB8DNLGVC+vJopOe9jsuERnDrRK+ 5Q6++StVM3fsyhdBHM9KFyn9ULDSHvwrGvHnDUCDF8903Z8O8rz/eLP0+8NWr2jDvVnf s8LfzEi5/+w4aXTQvUcNn2V//YMGe6yXuRK1F98Uc9GlWfyHsaL8rvdJtI4/tmwrbr1r 2hI10eOf7D7b6C6/vcQVZln+8CHSkB4KFEpwo486cHEZw1nhzS4bGdadNAn0F/Eypm2k 8tg6y3/EPtJJzD7CqtK6vJGj6oAnOy0iWlE2t0QROgL+/T1WjuQQGaSTQr6UPKlUQpXN a3Xg==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@q32-com.20251104.gappssmtp.com header.s=20251104 header.b=cbiZzTZh; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776530637; x=1777135437; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=4DCibTfujnwr+U4lh2s4FWfbA3MX0Q6u4ywOg/vMhko=; b=ZJBI8qXD9ecfBfeLm2fE2gAd3Cs3EGly01TKShjQjJryxprq95Uk5B1DQssf13yY9M BPo6JtOIQ7auh82Q3FIyV3tHQ1aFGSHi3iJASmsnFXt5HsX3BoH+d6F9tZDV/HLf8r9J P5nO7uybxyEfUtKXSoMU0gNQ3t6ljInFEM79sAnFp/+HGFDlGUlamZ4JxFWYhZK9MKk3 dwkkBJEvip679mW0Zb9rnAFy3p9UZPdCtkPR8gDtUYJGUiiQwEi/G6cR/bPqNdlWCbG6 QKwfZN5dQvP2jL5pzQsJVZbwDbLeF1eiQ32YdJGbeDLVio1rJAWZ11K4ASkEwUZIWqZg Xeog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776530637; x=1777135437; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=4DCibTfujnwr+U4lh2s4FWfbA3MX0Q6u4ywOg/vMhko=; b=HUvE5/GogXHDS2o48nSJTE1/cyUC16xl3I9UuAXgZRUvP7kd5if7TLJ8GGvZBXO/0Q 8Cxt6v1J3NLahP1DsK5BaZvhJ1lGYgr6DTyscQ+/OUM9qCAOtreOYEZhdm791eil19y3 WropGU9geybJcOu93k7wj0D03BHifG7esE3CxIWTOOZhSRk4v27QKBnM9be80vJIblw+ dGD2jsTieSx5ml8U0zaJ7pcfpKTIwXUbI1VUoSnAgXmyWzoWnIp5FD8yT9iRhJAal+3J T2bkUt6MvnSCbtQ8OnmWWoqjIbjaN49TO254JrzRDOW2yQyL2UcTbUQQ8gmLT9/zwY1n vpWw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ/kTQ/ZTlRHplz0ArADhEfThTbgLIU9taiYZEN0d9c5tydpVlexA1D9qZXj/SGIWnd+0rfnBQ3PoMIO@gnusha.org X-Gm-Message-State: AOJu0Yw7PzyZSySYuerDtXNSHuXaGi3562R8mux7XbX6g3tUn3Dr0+T8 V6O1sq3o1xeE1UcOkf9puwXya+JWhSRj7+XtVxnnza9ICvWOVTkvepxb X-Received: by 2002:a05:6820:4dc7:b0:692:16e:4e85 with SMTP id 006d021491bc7-69462ef236amr4178946eaf.49.1776530637409; Sat, 18 Apr 2026 09:43:57 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKVczJjv36l93vILS4jqspQmfzQYLYrLPr3XZnjIUnrww==" Received: by 2002:a05:6871:14c:b0:41c:64c3:46be with SMTP id 586e51a60fabf-4280c4cdcd4ls1788024fac.1.-pod-prod-07-us; Sat, 18 Apr 2026 09:43:52 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ+zF3wnv/9PTDJ4FVUi2pPPlNf2bRqVzJFY3Cnoykt+ZDy392qY40MFZtVgnheScB3isOJhc2aSsJ7p@googlegroups.com X-Received: by 2002:a05:6808:690b:b0:46a:746c:2d53 with SMTP id 5614622812f47-4799c917825mr3762693b6e.2.1776530632473; Sat, 18 Apr 2026 09:43:52 -0700 (PDT) Received: by 2002:a05:6402:3094:b0:672:bd1b:222f with SMTP id 4fb4d7f45d1cf-672c169bb1cmsa12; Sat, 18 Apr 2026 09:35:12 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ9E/RX/jXtWSA5g5RlYl/vgFZ1KtLpup+s2YFm1h5xnem44TDXkavMsfmTQtvPyIBLNlOXbZ+T+zpIK@googlegroups.com X-Received: by 2002:a05:6402:26d2:b0:672:641a:3692 with SMTP id 4fb4d7f45d1cf-672bfdc8c07mr3458378a12.13.1776530110914; Sat, 18 Apr 2026 09:35:10 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776530110; cv=pass; d=google.com; s=arc-20240605; b=U5RZq/EcKMgIAXjIbW2yEGb8mnbXwNMN14GTFdvlYQrY3u3hTQbjgWZS27UyoST2k9 9gIq5h/E4ayj/8Y4UNzHSG31mxkej6wGQUaMwKrmuL3o9gUllbXgcR1EEzcZGMqAtYVL JTsFcPY6m052GV4tjoOh1etXuCIZIYWc8k6opDUgsy7Trs1RoPjzhsNeBhkVTQ9RayVd nIKHUNw0mDyFxXCxqpAQxDJjGvtq3vMjsgqo+32eQX+mqCdGXtwgf6XOgUDvvnoonJ88 dHnr6YuNsca/LbqNmVLrdpXqFzyGSf5zWjlD1eVhSP9zliqmkLFA4d8Z40wrCrTOCnVo 4+XA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=gZScdqjlpylJSCgsGnK/RYRGhoPkxK6v9/NrOtXHSkk=; fh=TjcfzZJnFOC693/vDK5fsXr4Lrj2wnt/mpDXBD8w4qw=; b=Vwm25BRl2lEQajZEuI0rSDoeZplgDyvQaeZplaPRuF+P9IOZ6SGUYtzN9W07x8Zq0W 93V/ZY/PJRRbp8/HNSOLtVWL4SUuGSlxImxuLQFllaQaD+cVqNb6ZMd2PO8AsUR9PFWw dzD7KSRe22R7ukeD1bEr13bepPPoukyH/9qYpANMDQGQHRTIkpmg+tl1pGCPGCr8pPor oxP+x1ee+soctfS3K9FDBca3iYEod2SMMnmoACoHaWpMGj1qGWvuG40BQqbSXHB/Szut 4XIBIr6aH0aeZXwi5iO0fgB0r8hVyRgy2hNF7sLsufdmjMnyiBnGLPDJZgZp0bBCj4BH XG4Q==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@q32-com.20251104.gappssmtp.com header.s=20251104 header.b=cbiZzTZh; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com. [2a00:1450:4864:20::230]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-672c43ba22bsi95210a12.0.2026.04.18.09.35.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Apr 2026 09:35:10 -0700 (PDT) Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) client-ip=2a00:1450:4864:20::230; Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-38ce8a5bc20so18177351fa.1 for ; Sat, 18 Apr 2026 09:35:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776530110; cv=none; d=google.com; s=arc-20240605; b=YSZ3iP7bGiKIFK9yw2PxDCBGMEDhRdTDXJ/Q5fSRgp+W6llPT1KKQUWO94kpIbmzsh /vO8n1vYmjHbsLAtQ8FC1/1VpETw890DvJxP50546yDBNNfQELFJNx6mothDvvDXZtXT zvMQpCrwVzgfEGzHo3hAZnXh93RIfMJl/T2ZsynSYru+ZmiwdkmlkQxvPJ2a37NLIPOI uYNORZe91WfuVni67rDz2BD99DNF5eQ21ei/hv1191nJ90naEe699tXxhomQgZMk/WBx efB3NmSd1EgoSblk/7JQaKaPwRbzRf42yHd1MN6ScyvdjulK2jkph/3UvE4+XMsCDwgz pCUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=gZScdqjlpylJSCgsGnK/RYRGhoPkxK6v9/NrOtXHSkk=; fh=TjcfzZJnFOC693/vDK5fsXr4Lrj2wnt/mpDXBD8w4qw=; b=IAMLN3wsVEkx4WGU4LP7b8yGxIaGKseh0dXU8Z4cS+KIxdFzSmFVJRcKv+nWUIRi+o pHmjGDkMj1irG7kd0GsM/ZTXzesBMu0PmLQXqIS8nJLBO8kMwK0xgUvelh96xiG4NJUj pet1KA8PaXv1K479wIlD0Oo4BqcFY8YCOif8GdTnn+aqp6dWPTfrrE8wa0YvLfbdc+9t NVXEEOBokuD/xf3ivRJ2uR80kf392GDu4aU3ne//qA2il+Cc7mRD4/yPOw+qGz9gAKFx 389dWG4FODteB1F3FdEBP6F9nAbwmmTr1nZ6Ggs/BWQMXHUzWKmpjMT4xlbX/rQR4a03 YEag==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AFNElJ8044xDbVlfi+SV2PsERD2znGvyAMvgmJi0Lyh58v65ysB5DUleRUtuLx8AsoJaTKJpghMHQA9mqPhe@googlegroups.com X-Gm-Gg: AeBDiet+HWFgnRIsTHzh+TXt8+qS8xA48PcLSpeeduLBgaFQUfFygSd8gg743zNAfeF eT0BWdCAYM6KoymH2qWHsqr/1hA7YtoiTDMbHuBzRfdsxfKQNyPmAwzIYlMPUD44B7WoCvL/j0+ wlif4BwqEoQFbhQw4kytvwQr2xgHUK2BPXEndC9K1iwnxwJFa6f8xQxa+ff9BNTtPdkPgNHFG2t TLIU4nLF5Zt2Wrc3+toGsFCMEhRWb2D6jXN0xcu4RAWvV2AG8o5CE7l2JQJSjsKWTaNS2xcPKe3 MUuUc+lpg5gCRxhI840g5AgBDzjqEepVOc/Clkgs42GwI7fdlUg= X-Received: by 2002:a05:6512:138e:b0:5a2:c0f1:17d2 with SMTP id 2adb3069b0e04-5a4172c336amr2239667e87.10.1776530109657; Sat, 18 Apr 2026 09:35:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Sat, 18 Apr 2026 09:34:58 -0700 X-Gm-Features: AQROBzA0naZFzKYArXTn3Mye4pUPNQMVi_FhjtFdPGTX6QXQUa0pTHxi0WWcHpM Message-ID: Subject: Re: [bitcoindev] PQC - What is our Goal, Even? To: conduition Cc: Matt Corallo , Ethan Heilman , bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="0000000000001e786b064fbea67e" X-Original-Sender: erik@q32.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@q32-com.20251104.gappssmtp.com header.s=20251104 header.b=cbiZzTZh; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::230 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.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.7 (/) --0000000000001e786b064fbea67e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable P2MR is superior in another way. If quantum never happens (a very real possibility), P2MR is genuinely broadly useful and more secure in other ways. In other words, it wouldn't have been a waste of everyone's time. On Sat, Apr 18, 2026 at 8:44=E2=80=AFAM conduition w= rote: > I think I maybe under-stated my concern over the no-address-reuse > requirement for P2MR. We've been trying to convince wallets to not reuse > addresses for 15+ years and have not only had no success, popular wallets > have been actively migrating the opposite direction instead. In the face = of > address reuse, P2MR has zero advantages over P2TRv2. > > > I think we agree that merely spec-ing out P2MR as "not safe to reuse" in = a > BIP will be insufficient to prevent all address reuse. We also agree that > *reused *P2MR and P2TRv2 share the same security profile, with or without > a future EC restriction (which can be applied to either output type). > > But we seem to disagree in our conclusions. You believe that because of > this overlap in security profiles, that we therefore ought to prefer P2TR= v2 > - presumably because of its short-term efficiency. I think that's a huge > leap of logic. The overall security profile of P2TRv2 and P2MR are wildly > different and you are only taking a subset of P2MR's profile into account= . > > To reach your conclusion that P2TRv2 is preferable, you'd need to assume > that the vast majority users who migrate to P2MR will reuse addresses - > vast enough of a majority that the short-term efficiency savings of P2TRv= 2 > key-spending outweighs the safety of the (presumed) tiny minority of user= s > who actually use P2MR properly. > > We have historical evidence this assumption won't hold. Take a look at Pr= oject > Eleven's bitcoin risk list metrics dashboard > . The volume of > bitcoin exposed today due to address reuse is only a minority fraction of > the overall supply - about 5 million BTC at present. Still significant, b= ut > not an overwhelming majority by any means. We have no reason to expect > everyone will suddenly start reusing addresses consistently with P2MR, at > least not any more than they already do. > > If anything, address-reuse will reduce, and not just because we ask them > to. If you look at the highest-value addresses at fault of address-reuse > today, they are mostly corporate cold wallets: binance, robinhood, > bitfinex, tether, etc, and these make up a significant chunk of those 5 > million exposed coins. We can reasonably expect those players to use P2MR > properly out of self-interest - These coins will be the lowest-hanging > fruit targets if they fail to do so. > > So yes, even after taking address reuse into account, P2MR is more secure > than P2TRv2, and personally I think the safety delta between them is wide > enough to excuse the minor handicap in P2MR's pre-quantum efficiency. > > P2MR is also asking them to overhaul a UX decision they made with lots of > user feedback on top of that. > > > That's fair, it would be a difficult challenge to some low-effort wallets > not to receive coins to vulnerable addresses. But this argument implies 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. > Under this same implication, P2TRv2 fares even worse. Concretely: > > > - If EC spending is restricted, then both P2MR and P2TRv2 have exactly > the same security profile and address reuse does not matter. > > > - If EC spending isn't restricted, then both address formats are > vulnerable when reused, and P2TRv2 exposure is worse because even thos= e who > *don't* reuse addresses are vulnerable. > > > In other words, P2MR is the Nash equilibrium of a prisoner's dilemma > square [^1]. > > > - P2MR: addresses with hidden EC spend paths are safe > - P2TRv2: everyone is vulnerable > - P2MR with EC restriction: everyone is safe > - P2TRv2 with EC restriction: everyone is safe > > > Whether EC restriction happens or not, you always get the same or better > security by choosing P2MR. EC restriction is the only step which can secu= re > reused addresses of either P2MR or P2TRv2 [^2]. > > Thus, if you firmly believe that many wallets will reuse addresses and > want to mitigate the vulnerability that follows, then the choice between > output types should not weigh on your mind. Your goal should be to push > everyone to commit to an EC-restricting soft fork later (maybe have a loo= k > at BIP361 and contribute to that). The details of what output type is > deployed don't factor in. Again: the only difference between P2MR and > P2TRv2 there is that P2TRv2 *needs a future soft fork to restrict EC > spending*, while with P2MR this is optional, but still desirable (since > some wallets will mistakenly reuse addresses either way). > > regards, > conduition > > [^1]: You can expand that prisoner's dilemma square into a cube by asking > whether a CRQC will be invented or not, and P2MR is still a strictly bett= er > choice even if no CRQC appears - with or without EC restriction - because > of its better script-path efficiency. > > [^2]: For those rare few wallets who are: (1) willing to upgrade, (2) NOT > willing to use fresh addresses, and (3) NOT willing to depend on future > activation of an EC restriction, then these wallets can choose to use > hybrid address formats which use ECC and hash-based sigs in the same > locking script. This allows them to reuse addresses at the cost of > efficiency. With a stateful signature (e.g. XMSS/SHRINCS), they'd be addi= ng > a few hundred bytes to their witnesses, and they'd be able to reuse the > address thousands to millions of times. I could picture corporate > cold-wallets using this technique, but maybe not retail wallets. > On Friday, April 17th, 2026 at 6:38 PM, Matt Corallo < > lf-lists@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+ > years and have not only had no success, popular wallets have been activel= y > migrating the opposite direction instead. > > There is a huge difference between, we would prefer you don't reuse > addresses because privacy loss although privacy is hard to maintain anywa= ys > and if you reuse addresses in this context a CRQC may steal your user's > funds. > > Wallets are likely to be more responsive here than in the past because th= e > stakes are much higher. > > > More, maybe. But I think you=E2=80=99re drastically underestimating to wh= at extent > address reuse is baked into many flows. > > For example most funds or very large holders have a pre-defined list of > addresses that they=E2=80=99re allowed to send to (basically exchange acc= ounts to > sell), and have processes in place to ensure everyone cross validates tha= t > 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 many of them can, o= f > 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 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 > 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 wa= llets relying on > a disable-EC soft fork before a CRQC. > > I am NOT suggesting or proposing this, but one could require that any P2M= R > 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 thi= s > is wallets advertising PQ functionality aren't actually PQ safe because > this allow address reuse then one could solve the address reuse problem i= n > this manner. > > > 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. > > All told, it seems better to communicate to wallets and users that wallet= s > which allow EC address reuse aren't PQ safe. If a wallet doesn't want to > provide PQ safety why would they put in the engineering effort to support > P2MR and PQ sigs. > > > Because there will be marketing for =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 wrote= : > >> >> >> On 4/16/26 1:34 PM, conduition wrote: >> > Hi List, >> > >> >> Fundamentally, it seems to me the most reasonable goal is that we >> should be seeking to increase the number of coins which are reasonably >> likely to be secured by the time a CRQC exists. Put another way, we shou= ld >> be seeking to minimize the chance that the Bitcoin community feels the n= eed >> to fork to burn coins by reducing the number of coins which can be stole= n >> to the minimum number [1]. >> > >> > I think that's a reasonable goal which we all share, but is not the >> only goal. Real-life isn't about min-maxing a single metric of success. >> > >> > For instance, imagine we deploy P2TRv2, and we get EVERYONE to migrate >> to it before a CRQC appears. We maxed out our stated success metric. But= we >> might not disable P2TRv2 key-spending in a timely manner. If the future >> community fails to deploy at the right time, a CRQC can steal at least a= s >> much bitcoin as they could've before the migration, if not more. We maxe= d >> out our success metric but still failed, so that metric must not be our >> only goal. >> > >> > That's why we should achieve your stated goal only as a consequence of >> a more general but less easily-quantifiable goal: to design an optimal, >> flexible, and long-term-secure PQ migration path. If we standardize this >> and make code available to help, migration will come as a natural >> consequence, as will other desirable goals like "not letting a CRQC scre= w >> us all over", and "enabling long-term cryptographic agility". >> >> Sure, there are limitations of the goal as I stated, but your suggested >> alternative here isn't >> actually a concreate goal. "optimal, flexible, and long-term-secure" >> isn't something we can optimize >> for :) >> >> > If we can agree on that, then any further disagreement will be due to = a >> difference of opinion as to what is "optimal" or "flexible", and the >> correct trade-offs to make on security. We all weigh different propertie= s >> 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 >> requirement for P2MR. We've been >> trying to convince wallets to not reuse addresses for 15+ years and have >> not only had no success, >> popular wallets have been actively migrating the opposite direction >> instead. In the face of address >> reuse, P2MR has zero advantages over P2TRv2. >> >> > There are also differences of faith. Matt puts more faith in the futur= e >> community to activate follow-up soft forks. I put more faith in wallet >> developers following standards and in users proactively migrating to >> PQ-safe wallets. >> > >> > Based on Matt's previous emails, I think we both share the same LACK o= f >> faith that a majority of the UTXO set will migrate in time, and we also >> share the goal of mitigating that. >> > >> > >> >> This naturally means focusing on the wallets which are the *least >> likely* to migrate or otherwise get themselves in a safe spot. Focusing = on >> those who are the most likely to migrate does almost nothing to move the >> needle on the total number of coins protected, nor, thus, on the >> probability of a future Bitcoin community feeling the need to burn coins= . >> > >> > Also agreed. >> > >> > >> > I didn't find any public statements from your cited examples about >> quantum security posture. Since it seems important to understand the >> wallets' stances in this dilemma, I posted a tweet tagging 8 major >> multi-chain wallets [2] including the 3 wallets you cited as examples. I= 'm >> curious what they'll say. >> > >> > Having worked with such wallets before, my expectation is that they'll >> follow whatever is standardized, as long as it gives them more market sh= are >> and as long as they can "npm install whatever" to implement it. I'm not >> trivializing here - These devs are just spread much thinner than those >> building single-chain wallets. >> >> Sure but no new key scheme is going to be an "npm install whatever" - it >> requires a rewrite of a >> bunch of key derivation and backup schemes. P2MR is also asking them to >> overhaul a UX decision they >> made with lots of user feedback on top of that. >> >> > The harder question to answer is whether the major wallets make the PQ >> output type the default for receiving Bitcoin. Big software companies ar= e >> 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 >> techniques. So the earlier question shouldn't be binary. It becomes: How >> quickly will major wallets roll out PQ outputs as default? >> >> Fair, true point. >> >> > Rollout pace will depend on the personal views of the wallets' >> corporate executives and technical advisors. They will weigh the risk of >> introducing new, riskier, less-efficient code paths against the risk of = a >> CRQC appearing in the near future. We and other users can try to lobby >> them, but ultimately each wallet's decision makers must eventually convi= nce >> themselves the CRQC risk is greater. Some will move too slowly, and many >> will likely regret their choices one way or another. >> > >> > I believe we cannot effectively optimize away a problem like this by >> tempting decision-makers with slightly lower fees, since that's not all >> they are worried about. I believe we especially should not try to do so = at >> the expense of conclusive PQ security and long-term optimization. >> > >> > I think the crux of the P2TRv2 vs P2MR disagreement here is that Matt >> believes P2TRv2 will induce wallets to roll out default PQ outputs >> meaningfully faster than P2MR would, and that this trumps arguments abou= t >> post-quantum security or efficiency. >> >> No, its far from just about fees. Its also about maintaining the goals >> that we had going into >> taproot. And a bit that P2MR doesn't accomplish anything unless much of >> the ecosystem changes their >> processes substantially. >> >> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> 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 "= 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/= CAJowKgJnVpdZfEcMmE69LpnGTPYk%3DJsKEK9e%2B39-O8QafPf1kQ%40mail.gmail.com. --0000000000001e786b064fbea67e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
P2MR is superior in another=C2=A0way.=C2=A0 If quantum nev= er happens (a very real possibility), P2MR is genuinely broadly useful and = more secure in other ways.

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

On Sat, Apr 18, 2026 = at 8:44=E2=80=AFAM conduition <c= onduition@proton.me> wrote:
I= think I maybe under-stated my concern over the no-address-reuse requiremen= t for P2MR. We've been=C2=A0trying to convince wallets to= not reuse addresses for 15+ years and have not only had no success, popula= r wallets have been actively migrating the opposite direction instead. In t= he face of address=C2=A0reuse, P2MR has zero advantages over P2= TRv2.

I think we agree that merely spec-ing out = P2MR as "not safe to reuse" in a BIP will be insufficient to prev= ent all address reuse. We also agree that reused=C2=A0P2MR and P2TRv2 share th= e 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 b= elieve that because of this overlap in security profiles, that we therefore= ought to prefer P2TRv2 - presumably because of its short-term efficiency. = I think that's a huge leap of logic. The overall security profile of P2= TRv2 and P2MR are wildly different and you are only taking a subset of P2MR= 's profile into account.

To reach your conclusion that P2TRv2 is preferable, you'd n= eed to assume that the vast majority users who migrate to P2MR will reuse a= ddresses - vast enough of a majority that the short-term efficiency savings= of P2TRv2 key-spending outweighs the safety of the (presumed) tiny minorit= y of users who actually use P2MR properly.

We have historical evidence this assumption won&#= 39;t hold. Take a look at Project Eleven's bitcoin risk list metrics= dashboard. The volume of bitcoin exposed today due to address reuse is= only a minority fraction of the overall supply - about 5 million BTC at pr= esent. Still significant, but not an overwhelming majority by any means. We= have no reason to expect everyone will suddenly start reusing addresses co= nsistently with P2MR, at least not any more than they already do.

If anything, address-reuse= will reduce, and not just because we ask them to. If you look at the highe= st-value addresses at fault of address-reuse today, they are mostly corpora= te cold wallets: binance, robinhood, bitfinex, tether, etc, and these make = up a significant chunk of those 5 million exposed coins. We can reasonably = expect those players to use P2MR properly out of self-interest - These coin= s will be the lowest-hanging fruit targets if they fail to do so.

So yes, even after taking = address reuse into account, P2MR is more secure than P2TRv2, and personally= I think the safety delta between them is wide enough to excuse the minor h= andicap 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 challenge to some low-= effort wallets not to receive coins to vulnerable addresses. But this argum= ent implies EC spending on P2MR isn't restricted in time - otherwise th= ere is nothing to exploit when addresses are reused, and so address reuse w= ouldn't matter. Under this same implication, P2TRv2 fares even worse. C= oncretely:
=
  • If EC spending is restricted, then both P2MR and P2TRv2 ha= ve exactly the same security profile and address reuse does not matter.=C2= =A0
  • If EC spending isn't restricted, t= hen both address formats are vulnerable when reused, and P2TRv2 exposure is= worse because even those who don't=C2=A0reuse addresses are vul= nerable.

In othe= r words, P2MR is the Nash equilibrium of a prisoner's dilemma square [^= 1].=C2=A0

  • P2MR: addresses with hidden EC spend paths ar= e safe
  • P2TRv2: everyone is vulnerable
  • <= span>P2MR with EC restriction: everyone is safe
  • P2TRv2= with EC restriction: everyone is safe

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

Thus, if you firmly believe that many wall= ets will reuse addresses and want to mitigate the vulnerability that follow= s, 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 l= ater (maybe have a look at BIP361 and contribute to that). The details of w= hat output type is deployed don't factor in. Again: the only difference= between P2MR and P2TRv2 there is that P2TRv2 needs a future soft fork t= o restrict EC spending, while with P2MR this is optional, but still des= irable (since some wallets will mistakenly reuse addresses either way).

regards,
conduition

[^1]: You can expand that prisoner's dilemma square into = a cube by asking whether a CRQC will be invented or not, and P2MR is still = a strictly better choice even if no CRQC appears - with or without EC restr= iction - because of 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 f= uture 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 locki= ng script. This allows them to reuse addresses at the cost of efficiency. W= ith a stateful signature (e.g. XMSS/SHRINCS), they'd be adding a few hu= ndred bytes to their witnesses, and they'd be able to reuse the address= thousands to millions of times. I could picture corporate cold-wallets usi= ng this technique, but maybe not retail wallets.
On Friday, April 17th, 2026 at 6:38 PM, Matt Corallo <lf-lists@mattcorallo.co= m> wrote:


On Apr 17, 2026, at 18:04, Ethan Heilman = <eth3rs@gmail.com<= /a>> wrote:


More, maybe. But I think you=E2=80=99re drastically underestimatin= g to what extent address reuse is baked into many flows.

For example most funds or very large holders have a pre-defined list= of addresses that they=E2=80=99re allowed to send to (basically exchange a= ccounts to sell), and have processes in place to ensure everyone cross vali= dates 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 j= ust presume that they can move the funds again before a CRQC. And many of t= hem can, of course - the large funds probably would be about to move in a f= ew days or weeks - but I=E2=80=99m quite confident it=E2=80=99ll get normal= ized pretty 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 addres= s reuse because those users preferred to use insecure wallets, you still pr= otected 99% of the other P2MR coins.

<= blockquote type=3D"cite">
I am NOT suggesting or proposing this, but one could require that any P2= MR output whose EC pubkey has been leaked on-chain due to address reuse can= only be spent through the quantum safe leaf. If the community decides this= is wallets advertising PQ functionality aren't actually PQ safe becaus= e this allow address reuse then one could solve the address reuse problem i= n this manner.

Yes, i mea= n I think P2MR would be way more exciting if we had an efficient way to enf= orce addresses as single use directly in consensus. I=E2=80=99m not, howeve= r, aware of one.

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

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

Matt



On 4/16/26 1:34 PM, conduition wrote:
> Hi List,
>
>> Fundamentally, it seems to me the most reasonable goal is that we = should be seeking to increase the number of coins which are reasonably 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+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/CAJowKgJnVpdZfEcMmE69LpnGTPYk%3DJsKEK9e%2B39-O8QafPf1kQ%= 40mail.gmail.com.
--0000000000001e786b064fbea67e--