From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 20 Apr 2026 13:51:45 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.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 1wEvap-0005nJ-Kx for bitcoindev@gnusha.org; Mon, 20 Apr 2026 13:51:45 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-41c0b2d17e2sf681814fac.1 for ; Mon, 20 Apr 2026 13:51:43 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776718297; cv=pass; d=google.com; s=arc-20240605; b=UDj88BhnOnTi7rbBGeo1znZ/bTsuBxcyIia4jw4tdjBMzSGRX/xSgmU2iIUPug4RHx niiuPw5lWHn2T7ou+u74Lsq7VRciQAdGVtQ1rBI068+VIyAN1qe3m9bjV/ytk5Dbk4Nn eqZfe/CEp7Zwz+zruVgJRTSjDCoNaf4D5P0DgFqys9zPK7HEbaEfHPRmjePv552PpMl+ +pXipENqQ3WnHNmgqjFLV/xSdxTeieVx26MBeHgXKIUtZ0UrKqMyyfxV963yn8AZ/Hh5 6JiecT4EyRJOH4o/Zycx+5dCByygJCmEm3BWq9qGBJX57ag3yFyPubv1Wi6qA3CmCruM 0fZw== 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=OW5srQmmVxQI/Y+bD04SZ0eHGnhP13abUqdK8+8XI5k=; fh=yjzyejmR3149utCT5fYRxONIRuGc9pobr1laBWhniFQ=; b=P4Yhw2ngnbf4wDmo6CsFhC8K5aYYQCVSuDhIR4R+wH1UcY5K+XJHDE2x5ZxrGwNtdL HtzP0XwytEbJ8v85tOEUOuK7CXp3KdXiRbyZyC/uXt4kcYnGQzj67zFYhRIwgDZ2rktL ADSZ0dHu7KffTZeYqx8KFSzxshgZFo8OagcnBCVrBYPIElRVptUdcHkEh2KwAROy397r sd1wRbXdiu/uytdSMQB5tnuBL5kn79pAkZTZonN6riCj4ox96Cl/taNnpyqbgTmsTHYN An933z02wLXyEA8rmr4Vzs1GHA8zPuxZfyiSZxPX9EJBRULplMPlkCTnyQKCeHVB9Zsb mH4A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=E5vgNxZC; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776718297; x=1777323097; 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=OW5srQmmVxQI/Y+bD04SZ0eHGnhP13abUqdK8+8XI5k=; b=tmWZztOyETEi+5yBzvE5sAjkQueWZnRkW0+hA0IVkAswczscGWSw5P5lURMpuC8Orq QCnHHfI2K2UjHoWj0tWD1wUtLYiSbAtnJ1Ptm/zfvFivYG7IzbiuMSPzTggI6sz1VD6f FZzO2UX6HUZUr20wIFSZvU6rKtiURXEF9fmneTWEPArzrG4kLFj23rmTmrgv5Tq5k51+ je9lUTat2ftTQdPCdEbeBdBIAs3X7GyPxW6NdjuVlx2kofIGxmOQRmtLBq/dryr1wF4h QDlt4jMerxxTI8hFE/xRpTj74AfqzdvaOJdG6PE2RzGYrNPS+PnSgeNSWt0bd+DHIm9n BUrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776718297; x=1777323097; 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=OW5srQmmVxQI/Y+bD04SZ0eHGnhP13abUqdK8+8XI5k=; b=kYy2HgI685XTFVkgbM9xYD/e33Jx5tzTbEyvP2h+0an1gDVE7SUGKoISID6AySiruz FC370u0jFVgYyoI+c/spmq/RI8c31+QQxHCRfA5lxayznsXrDbXI9nchjvOZn9roQ3dM tY/i8nm5nM07hrhJz8wuRjmziqt0zO8lJrT/Cr0zYRDVtoBW49aWGbbp+NjtBtxFlSj/ BHWpBHTNp3MbWqE/YvO2ci4Fph8/EgDR900y1/VgvzYkvSKDuK9VeBy4wbS6eFdj2UsD KJ4VnHz8hO9EiG56IS80Q91FmA4V8W64kPwXs7zJea14a9WK99zGirDTxWizOtoAuz4y PWkQ== X-Forwarded-Encrypted: i=2; AFNElJ9ZVMg6EZIc1hTEcBdcZ2vhMWnjpnsQHzUF1VnRgYATx7fyZQlsUgH8aq87jyJR0tfVOHxEdzQ8nZrL@gnusha.org X-Gm-Message-State: AOJu0YymoOhxhXT3Iwm13YvY5AzDAEq0CYn5DkZAWpB9lan6tx5HqvQ3 zMk3o0hyVhYO776fr0MedZuNI+R9YNjsKhbYkDK7LdvWGx7ndwWYtNxd X-Received: by 2002:a05:6870:1433:b0:42c:193a:478 with SMTP id 586e51a60fabf-42c193ac47cmr1065890fac.2.1776718297225; Mon, 20 Apr 2026 13:51:37 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJbqeqTqbxf93HiSlwRPfmprm0KsfB76UKHC6a2uiAVvQ==" Received: by 2002:a05:6871:14c:b0:41c:64c3:46be with SMTP id 586e51a60fabf-4280c4cdcd4ls2714698fac.1.-pod-prod-07-us; Mon, 20 Apr 2026 13:51:32 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ94aW3kO3le4bkMSUKIieZ8NUZKPtuI/aZmmrk7IhALTulik86vfcsB0Go0s5BCKmL6gAJXr+HD3LKa@googlegroups.com X-Received: by 2002:a05:6808:1907:b0:460:f435:2a71 with SMTP id 5614622812f47-4799cb33adbmr8074254b6e.46.1776718291918; Mon, 20 Apr 2026 13:51:31 -0700 (PDT) Received: by 2002:aa7:cb4a:0:b0:674:9e45:fb5e with SMTP id 4fb4d7f45d1cf-6749e45fd04msa12; Mon, 20 Apr 2026 13:20:21 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+I03o1kfPQAhYGlO5Gt2IedprFQVp6kkX39Jld5RXSYHHKDhJeWLVZP+zHfHC0Nn1cqSXc+erk7YDs@googlegroups.com X-Received: by 2002:a17:907:3f9d:b0:ba5:20b1:7698 with SMTP id a640c23a62f3a-ba520b1773emr596312266b.14.1776716418875; Mon, 20 Apr 2026 13:20:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776716418; cv=none; d=google.com; s=arc-20240605; b=ZCkJ80kT5oJsUZzNKLkcVw7l/HSWkZiZNnpxzwaJbT0nqYigCK+X11sXDDBkvg2XFp Uz+RlcuWyvG4YGGmY6MH+56eW6CuhesMB8xaSwdM2hhGKTb/VVwJsReuBYs7eB30t88p zZSbqERH3aAzVJxd8uq6vyLUgXn3Ifc3/nL4ODkmR8ZhpZQEUgKDqoqB62Zgl2PJetxG TmG2/t+CMXg49HOOHfd+vJvY089SyLMqJOIIr2RGgdFXwuBVNusWO5mijqU1vezHdsgR PPSxiNXBxL3HtvUVtpAwfhG0di6Ddh+TgSz+x+gm4kqPSYEr6MlJVSHPQfl6jFLJmp4c EvDw== 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=ICxBve2j05f4j+DmVZi0UjCyU6MJ2a+JmeBAB7XZ5uA=; fh=wuzCZ0FAbCVPQi0X5sqdzGc1G3sXE3RMs2nfBrKO1jo=; b=PjrYm9YKvT7Y9BsFFtqngkxkTuJb82AzXx704QteX00k6WJGVaBp9OKAgUPhRGuRPp QcD8XVeT+O9/29NRzw/QMvg6RxCl2FagsQwVnLNDOqFgvDRCxTw4iKg6I6uFAG5YiY2E CDPTL99JZmk3HF7E5JshVb4WgtmPKRfsYR4LKJDNzWdI0FdiHH8Hv7RENNXTNc5icwpf sSfhFk818OjRvEJLaHvvXjaE6rdl62thQIoQXZSa1A+7yR+K9jiby5vlYsb+RDyJ6CWn lRW1gnTbezWlRFiKdJd9UDDcEtZ2CIe8q9vhqYJijIq+sCtA93GEQ6QeBicFHbEZhVcg i7wg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=E5vgNxZC; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch. [79.135.106.29]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-ba450f1d937si17576366b.1.2026.04.20.13.20.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Apr 2026 13:20:18 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) client-ip=79.135.106.29; Date: Mon, 20 Apr 2026 20:20:12 +0000 To: conduition From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Cc: Matt Corallo , Ethan Heilman , Erik Aronesty , bitcoindev@googlegroups.com Subject: Re: [bitcoindev] PQC - What is our Goal, Even? Message-ID: In-Reply-To: References: Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 7e4990d9a608013bd24f9218cda5ce58bd70e975 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_Ti9zD5KMSXrEG4NYPaTeNRjqJCI2g5dVonQvOncPXek" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=E5vgNxZC; spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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 (-) --b1=_Ti9zD5KMSXrEG4NYPaTeNRjqJCI2g5dVonQvOncPXek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Conduition, Just a couple points on address reuse. On Saturday, April 18th, 2026 at 11:59 AM, 'conduition' via Bitcoin Develop= ment Mailing List wrote: >> I think I maybe under-stated my concern over the no-address-reuse requir= ement for P2MR. We've been trying to convince wallets to not reuse addresse= s 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 t= his overlap in security profiles, that we therefore ought to prefer P2TRv2 = - presumably because of its short-term efficiency. I think that's a huge le= ap of logic. The overall security profile of P2TRv2 and P2MR are wildly dif= ferent 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 - vas= t enough of a majority that the short-term efficiency savings of P2TRv2 key= -spending outweighs the safety of the (presumed) tiny minority of users who= actually use P2MR properly. There are additional drawbacks to P2MR as specified in the current version = of BIP360. Bitcoin users activated Taproot a little over 5 years ago, whose= stated benefits include indistinguishable outputs between users of Script = paths and non-Script paths, hide whether a Script path was present when key= path 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 win= dow just now, if there are other ways of mitigating CRQC risks. > We have historical evidence this assumption won't hold. Take a look at [P= roject Eleven's bitcoin risk list metrics dashboard](https://www.projectele= ven.com/bitcoin-risq-list/metrics). 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 major= ity 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 a= lready do. Matt's arguing about maximizing the number of users/utxos safely migrated, = not share of supply, so i don't think this is a valid counterpoint. The Mil= ton-Shikhelman report from July 2025 [estimated over 60% of existing UTxOs = reuse an address](https://pq-bitcoin.org/posts/bitcoin-qva-1#fig-reuse-perc= entages). > 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 to= day, they are mostly corporate cold wallets: binance, robinhood, bitfinex, = tether, etc, and these make up a significant chunk of those 5 million expos= ed coins. We can reasonably expect those players to use P2MR properly out o= f self-interest - These coins will be the lowest-hanging fruit targets if t= hey 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 o= f user feedback on top of that. > > That's fair, it would be a difficult challenge to some low-effort wallets= not to receive coins to vulnerable addresses. But this argument implies EC= spending on P2MR isn't restricted in time - otherwise there is nothing to = exploit when addresses are reused, and so address reuse wouldn't matter. Un= der 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. > > - 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 r= euse addresses are vulnerable. > > In other words, P2MR is the Nash equilibrium of a prisoner's dilemma squa= re [^1]. > > - P2MR: addresses with hidden EC spend paths are safe > - P2TRv2: everyone is vulnerable > - P2MR with EC restriction: everyone is safe > - P2TRv2 with EC restriction: everyone is safe > > Whether EC restriction happens or not, you always get the same or better = security by choosing P2MR. EC restriction is the only step which can secure= reused addresses of either P2MR or P2TRv2 [^2]. > > Thus, if you firmly believe that many wallets will reuse addresses and wa= nt to mitigate the vulnerability that follows, then the choice between outp= ut types should not weigh on your mind. Your goal should be to push everyon= e to commit to an EC-restricting soft fork later (maybe have a look at BIP3= 61 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 t= hat P2TRv2 needs a future soft fork to restrict EC spending, while with P2M= R 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 bette= r 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 ac= tivation 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 scrip= t. This allows them to reuse addresses at the cost of efficiency. With a st= ateful 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 mi= llions of times. I could picture corporate cold-wallets using this techniqu= e, but maybe not retail wallets. > > On Friday, April 17th, 2026 at 6:38 PM, Matt Corallo 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+ y= ears and have not only had no success, popular wallets have been actively m= igrating the opposite direction instead. >>> >>> 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= . >>> >>> Wallets are likely to be more responsive here than in the past because = the stakes are much higher. >> >> More, maybe. But I think you=E2=80=99re drastically underestimating to w= hat 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 accou= nts to sell), and have processes in place to ensure everyone cross validate= s 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 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 >> >>>> 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 t= he other P2MR coins. >> >> Yes but we=E2=80=99re still back to square one - there=E2=80=99s still w= allets relying on a disable-EC soft fork before a CRQC. >> >>> 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. >> >> Yes, i mean I think P2MR would be way more exciting if we had an efficie= nt way to enforce addresses as single use directly in consensus. I=E2=80=99= m not, however, aware of one. >> >>> 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. >> >> 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 wro= te: >>> >>>> On 4/16/26 1:34 PM, conduition wrote: >>>>> Hi List, >>>>> >>>>>> Fundamentally, it seems to me the most reasonable goal is that we sh= ould be seeking to increase the number of coins which are reasonably likely= to be secured by the time a CRQC exists. Put another way, we should be see= king to minimize the chance that the Bitcoin community feels the need to fo= rk to burn coins by reducing the number of coins which can be stolen to the= minimum number [1]. >>>>> >>>>> I think that's a reasonable goal which we all share, but is not the o= nly goal. Real-life isn't about min-maxing a single metric of success. >>>>> >>>>> For instance, imagine we deploy P2TRv2, and we get EVERYONE to migrat= e to it before a CRQC appears. We maxed out our stated success metric. But = we might not disable P2TRv2 key-spending in a timely manner. If the future = community fails to deploy at the right time, a CRQC can steal at least as m= uch bitcoin as they could've before the migration, if not more. We maxed ou= t 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 o= f a more general but less easily-quantifiable goal: to design an optimal, f= lexible, 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 suggeste= d alternative here isn't >>>> actually a concreate goal. "optimal, flexible, and long-term-secure" i= sn'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 cor= rect 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, where= as 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 requ= irement for P2MR. We've been >>>> trying to convince wallets to not reuse addresses for 15+ years and ha= ve not only had no success, >>>> popular wallets have been actively migrating the opposite direction in= stead. In the face of address >>>> reuse, P2MR has zero advantages over P2TRv2. >>>> >>>>> There are also differences of faith. Matt puts more faith in the futu= re community to activate follow-up soft forks. I put more faith in wallet d= evelopers following standards and in users proactively migrating to PQ-safe= wallets. >>>>> >>>>> Based on Matt's previous emails, I think we both share the same LACK = of faith that a majority of the UTXO set will migrate in time, and we also = share the goal of mitigating that. >>>>> >>>>> >>>>>> This naturally means focusing on the wallets which are the *least li= kely* to migrate or otherwise get themselves in a safe spot. Focusing on th= ose who are the most likely to migrate does almost nothing to move the need= le 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 qu= antum security posture. Since it seems important to understand the wallets'= stances in this dilemma, I posted a tweet tagging 8 major multi-chain wall= ets [2] including the 3 wallets you cited as examples. I'm curious what the= y'll say. >>>>> >>>>> Having worked with such wallets before, my expectation is that they'l= l follow whatever is standardized, as long as it gives them more market sha= re 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 buil= ding 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 t= o 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 P= Q output type the default for receiving Bitcoin. Big software companies are= typically very concerned about bugs in new code paths, and they weigh this= risk against the benefits of any new feature. When deploying new features = as default, they often do so using A/B testing and incremental rollout tech= niques. So the earlier question shouldn't be binary. It becomes: How quickl= y will major wallets roll out PQ outputs as default? >>>> >>>> Fair, true point. >>>> >>>>> Rollout pace will depend on the personal views of the wallets' corpor= ate executives and technical advisors. They will weigh the risk of introduc= ing new, riskier, less-efficient code paths against the risk of a CRQC appe= aring in the near future. We and other users can try to lobby them, but ult= imately each wallet's decision makers must eventually convince themselves t= he CRQC risk is greater. Some will move too slowly, and many will likely re= gret 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 the= y 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 meaning= fully faster than P2MR would, and that this trumps arguments about post-qua= ntum 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 o= f the ecosystem changes their >>>> processes substantially. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Gro= ups "Bitcoin Development Mailing List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send= an email to [bitcoindev+unsubscribe@googlegroups.com](mailto:bitcoindev%2B= unsubscribe@googlegroups.com). >>>> To view this discussion visit https://groups.google.com/d/msgid/bitcoi= ndev/600f95eb-04e8-470d-b6df-cf725e48d1b5%40mattcorallo.com. > > -- > You received this message because you are subscribed to the Google Groups= "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/sMhLbmV30g91LFREGHE2JfcnoPYAOeUXZpOdeP7rY7aqBDpx0BP4avqHHKIu2JXU5ba5N2CgP= Dvxe_2lzDqHJsz9bsSInuaqZ5SSstrFJsE%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/= kkdcg1Bo7GsRcpH5gDpfZ1WZR-ulfI5JRUKFa8cWla7CaWGtbQxgcE-nGZBOQeXKpepfSh8eVhE= -x2-fOXExE9x2b2V21m6kact8e4CSzNQ%3D%40protonmail.com. --b1=_Ti9zD5KMSXrEG4NYPaTeNRjqJCI2g5dVonQvOncPXek Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Conduiti= on,
Jus= t a couple points on address reuse.
=20
=20
=20

On Saturday, April 18th, 2026 at 11:59 AM, 'conduition' via Bitcoin= Development Mailing List <bitcoindev@googlegroups.com> wrote:
I think I maybe under-stated my concern over the no-address-reuse = requirement for P2MR. We've been trying to convince wall= ets 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 o= ver P2TRv2.

I think we agree that mere= ly spec-ing out P2MR as "not safe to reuse" in a BIP will be insufficient t= o prevent all address reuse. We also agree that reused P= 2MR 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 d= isagree in our conclusions. You believe that because of this overlap in sec= urity profiles, that we therefore ought to prefer P2TRv2 - presumably becau= se of its short-term efficiency. I think that's a huge leap of logic. The o= verall 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 tha= t P2TRv2 is preferable, you'd need to assume that the vast majority users w= ho migrate to P2MR will reuse addresses - vast enough of a majority that th= e short-term efficiency savings of P2TRv2 key-spending outweighs the safety= of the (presumed) tiny minority of users who actually use P2MR properly.

There are additional drawbacks to P2MR as specified in the current ver= sion of BIP360. Bitcoin users activated Taproot a little over 5 years ago, = whose stated benefits include indistinguishable outputs between users of Sc= ript paths and non-Script paths, hide whether a Script path was present whe= n 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 th= e window just now, if there are other ways of mitigating CRQC risks.
<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">
We have historical evidence this as= sumption won't hold. Take a look at Pro= ject Eleven's bitcoin risk list metrics dashboard. The volume of bitcoi= n exposed today due to address reuse is only a minority fraction of the ove= rall supply - about 5 million BTC at present. Still significant, but not an= overwhelming majority by any means. We have no reason to expect everyone w= ill suddenly start reusing addresses consistently with P2MR, at least not a= ny more than they already do.

Matt's arguing about maximizing the num= ber of users/utxos safely migrated, not share of supply, so i don't think t= his is a valid counterpoint. The Milton-Shikhelman report from J= uly 2025 estimated over 60%= of existing UTxOs reuse an address.

If anything, address-reuse will reduce, and not just bec= ause 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, robi= nhood, bitfinex, tether, etc, and these make up a significant chunk of thos= e 5 million exposed coins. We can reasonably expect those players to use P2= MR properly out of self-interest - These coins will be the lowest-hanging f= ruit targets if they fail to do so.

So yes, even after taking address reuse into a= ccount, 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 pr= e-quantum efficiency.

P2MR is also asking them to overhaul a UX decision they&nb= sp;made with lots of user feedback on top of that.
<= /div>

That's fair, it would be a difficult challenge to some l= ow-effort wallets not to receive coins to vulnerable addresses. But this ar= gument implies EC spending on P2MR isn't restricted in time - otherwise the= re is nothing to exploit when addresses are reused, and so address reuse wo= uldn't matter. Under this same implication, P2TRv2 fares even worse. Concre= tely:
=
<= ul data-editing-info=3D"{"orderedStyleType":1,"unorderedStyl= eType":2}" style=3D"margin-top: 0px; margin-bottom: 0px;">
  • If EC spending is restricted, then= both P2MR and P2TRv2 have exactly the same security profile and address re= use does not matter. 
    • If EC spending isn't restricted, then both address formats are vul= nerable when reused, and P2TRv2 exposure is worse because even those who don't reuse addresses are vulnerable.
    <= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">
    =
    In other words, P2MR is the Nash = equilibrium of a prisoner's dilemma square [^1]. 

    =
    • P2MR: addresses with hidden EC spend pat= hs are safe
    • P2TRv2: everyone is vuln= erable
    • P2MR with EC restriction: eve= ryone is safe
    • P2TRv2 with EC restric= tion: everyone is safe

    Whet= her EC restriction happens or not, you always get the same or better securi= ty by choosing P2MR. EC restriction is the only step which can secure reuse= d addresses of either P2MR or P2TRv2 [^2].

    <= /span>
    Thus, if you firmly believe that many wallets will reuse a= ddresses and want to mitigate the vulnerability that follows, then the choi= ce 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 P2= TRv2 there is that P2TRv2 needs a future soft fork to restrict EC spendi= ng, while with P2MR this is optional, but still desirable (since some w= allets 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 stri= ctly better choice even if no CRQC appears - with or without EC restriction= - because of its better script-path efficiency.

    [^2]: For those r= are few wallets who are: (1) willing to upgrade, (2) NOT willing to use fre= sh addresses, and (3) NOT willing to depend on future activation of an EC r= estriction, then these wallets can choose to use hybrid address formats whi= ch use ECC and hash-based sigs in the same locking script. This allows them= to reuse addresses at the cost of efficiency. With a stateful signature (e= .g. XMSS/SHRINCS), they'd be adding a few hundred bytes to their witnesses,= and they'd be able to reuse the address thousands to millions of times. I = could picture corporate cold-wallets using this technique, but maybe not re= tail 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 "= 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/b= itcoindev/sMhLbmV30g91LFREGHE2JfcnoPYAOeUXZpOdeP7rY7aqBDpx0BP4avqHHKIu2JXU5= ba5N2CgPDvxe_2lzDqHJsz9bsSInuaqZ5SSstrFJsE%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/bitcoindev/= kkdcg1Bo7GsRcpH5gDpfZ1WZR-ulfI5JRUKFa8cWla7CaWGtbQxgcE-nGZBOQeXKpepfSh8eVhE= -x2-fOXExE9x2b2V21m6kact8e4CSzNQ%3D%40protonmail.com.
    --b1=_Ti9zD5KMSXrEG4NYPaTeNRjqJCI2g5dVonQvOncPXek--