From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 17 Apr 2026 18:06:17 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wDu8W-0006d8-Bi for bitcoindev@gnusha.org; Fri, 17 Apr 2026 18:06:17 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-41c02dec5c1sf2403140fac.2 for ; Fri, 17 Apr 2026 18:06:16 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776474370; cv=pass; d=google.com; s=arc-20240605; b=VpLJPEOWPnxnk5clOI7CTG/8yfKNzhKKNwmnwblJ6p7c7MGX8ylTKkqFg13zUQAxR0 nAUZPfqoS0ctwNi7V3nNayS5Bnd3h6lCnB5vdqHZflCpOKfFBSDNo9YxYQdrXlBsnBg/ rE19hsyF23Lzq2KaDn4/zMg+IfQAWpwRwM8k9Ig3WE46DWEcL51WNtkuMsb6qJdcqfah rpod4Abbbh4yGJYHzJuMT5w4DUcaSsJwJEUc+mnT50ha3ImqrYJ/gRVP4B6gmsSO01Qy THItlgTmJuEqc60uueWD++Cuo3GxM45gVuY67gNEa2QVq1P/lOu9bV0c3qMhdEYTVqbY vHvw== 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:to:in-reply-to:cc:references :message-id:date:subject:mime-version:from:content-transfer-encoding :sender:dkim-signature; bh=RDRcL0Xyx96POz+X6mQLsxl+jhn6GC45SHDlpY+ZqgU=; fh=q7sshPZ4iEmN/GoIvb+t2U0c3WfsNAjEaascACU5V5E=; b=c9nGYzcKA777kBhOjWuCw3cEgaFbEGg//XQALvJWSfRjpiucUN6oeu20HJH5ESjtjp 1aYiX3JpQxiapQe8ekXQVEZJjnFMJWkRByn6PIpHLMGdDNHucBAKLnjB0M+HAkF03M5H FxTOIb5KYkq1fJ1FBl2FDMoxgsikEc60oZTgCteUWMBFyYOzG27xKRwAeL4HZuljYZBR kgneypOXenJHJ1hCweCG/HbBn3g2BFqLFGgmVZSOoNru6hZZp2iY1GzxJ/wfxzysrsIz xuhszwHqr8dbhnS5zX1FLoZvLKc0fToUDDe5pDy41lIkpqpePkAjXCWJFoZZFeFQuFq7 1YWA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776470462 header.b=OMa+EjDV; dkim=pass header.i=@clients.mail.as397444.net header.s=1776470464 header.b=HIcQ1FeG; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776474370; x=1777079170; 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:to:in-reply-to:cc:references:message-id:date :subject:mime-version:from:content-transfer-encoding:sender:from:to :cc:subject:date:message-id:reply-to; bh=RDRcL0Xyx96POz+X6mQLsxl+jhn6GC45SHDlpY+ZqgU=; b=JWK0npN1+zci6Fsylwmfe663kUA3Id3WOUVL13Ur7CJUei3Np0xZ+bYlp3Alp6oPh0 XU3hAjnq4Lh2rnBvqmsKN5egOUNpg6n6tKXNJoJIpNIfs5sp6kUCLLUQ/ucynzsguRpm 62P5LF8vuUPPegYXg4uiaUlSHDDQDveoX+RAvfi2/A7jDSVkrFEba0mohUlid5voDT1e gjRDFIVmMkKr4Py1aXgce+fy+T31Ud07yG4xzzLhk22SoEwXKHzn9R08fT8uIi30gUVi ftYO5pi5OBcXSuh7V5SP9YeiWX8QINERKzqknaFK9t2lAw6ErEQwLfqFNC9dVVWP6Ws1 QR6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776474370; x=1777079170; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:in-reply-to:cc:references:message-id:date :subject:mime-version:from:content-transfer-encoding:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=RDRcL0Xyx96POz+X6mQLsxl+jhn6GC45SHDlpY+ZqgU=; b=JO/fYCETcH53EBCWLJM9bFEE5sUA2Z1Oaj7DzkwJgKrL2zKcieSRamSAVpGO8/oxQa iU89wDPPlMByMgzXQwvIFxE8Zi19KUy7AU0N1lTKeTMQxBq8PVVTOpr1I34vkDWjVsNM p8u7V9UmKWCTs7dSVCoR8aiZXnbSnPY4lrNkwhutrTveCMSiJDIW3lQGYyfBDjWbFfwJ 4Cxz1rKIe5m6ElHoh4A19rwhrEhyJwK+SYJlmJfcb8Rg14dCIJJraxVCtY1eTqodVUpt z/zJRh5Iq9cYt1lTDSgTl6l1knD4TwyTcMQBQ0McKvL5OOuORS91onpuM6elnyDCQWa2 eREw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ/k3f+QolPG/SLohqY3Nxr0VHg80GMROTGZm2edaqzvci+P3DwV6EKo4ohh801bOzagG87rOVe44dxU@gnusha.org X-Gm-Message-State: AOJu0Yz784CRRu5WsNDdTI+2omHJrYDt+u5QYpizj3l6K6JxpSN/f0Hi Y2M312hQHlOa9V3GqlNVh5yGl+S5I5ak+0z8fSXSn/gcTsIvGh/AKZBm X-Received: by 2002:a05:6870:6c0b:b0:417:7b1d:19c with SMTP id 586e51a60fabf-42adee1daa1mr3182659fac.37.1776474370139; Fri, 17 Apr 2026 18:06:10 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiK7fpxk3p1aBShMbtYHYGGQ3IXYFa08KXkYJhK0ylCbgQ==" Received: by 2002:a05:6870:23a9:b0:417:821f:fca0 with SMTP id 586e51a60fabf-4280bdaaff4ls1298571fac.0.-pod-prod-09-us; Fri, 17 Apr 2026 18:06:05 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+6H5/kuPURgvP5ymnWWGpHmsLORh05LmV/DMKwzk8fJ4i8KlrV6eFZ5MsK5T2zJ4fuzA7XXG8a4+6m@googlegroups.com X-Received: by 2002:a05:6808:1301:b0:467:2375:58c9 with SMTP id 5614622812f47-4799ca307d1mr3355571b6e.45.1776474364947; Fri, 17 Apr 2026 18:06:04 -0700 (PDT) Received: by 2002:a05:620a:12c5:b0:8d6:1bc4:a7bc with SMTP id af79cd13be357-8e7920843bems85a; Fri, 17 Apr 2026 17:38:02 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ9dhO0vO0k+RtotwlyS61TcAWTcB+BldICEpz29QaDJSX275OAOH8TkuWclO0ef5uGY3ki0EiPOIorv@googlegroups.com X-Received: by 2002:a05:620a:4720:b0:8cd:b38d:be7a with SMTP id af79cd13be357-8e78f541702mr766196685a.4.1776472681878; Fri, 17 Apr 2026 17:38:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776472681; cv=none; d=google.com; s=arc-20240605; b=kB13CxxnZML0CIIDL2vJTeVtzZwGJJJkhFvOxIHj6cyWs7vm8NqslODFZW5Mr4mH91 ipH2e2Xn5QmhWqEoOpuA2K3kcWLxRm2EOmELLawG+IxvA1KDnX1TAA+9N44FJTKCiBtN ACYnG4YizpplSF8Cr4lrvOJZN/tR7U7FzsRwzq7lKq+VXaoTzNVOXpvM9reofktjfQvG Xi0zRdWyH+5DAAe4pzZmtuRZ3JJ5EDXTSsrL6sO1laEQ0WfWYrH5mvZBeaWiMEhdc6xA N883K+8xD7JbeRcUqUSEDqlzRFLMsWKylrtGMRzmse6UKXe8Dn6G4fMoTebQKVLsQZIG Vy9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:dkim-signature:dkim-signature; bh=+GULtkHNLxn6sI6sZNNn+ZuGH6guZ7VWprKLvkPubzw=; fh=/ybBAbc8okWLnlcC4HRIRkkaOp99XxArcG3H/TjD1YA=; b=ghE4HTQZFcmPk/zu9KgnSm2x3RkXJYAGYB78YI92Wx6rLK9cYq3xSag+yLggoBI7Sw kbfwDbNCtj3uQgm+SUaCQ8JaKjKJkmCSg8yGR5Wsfl1SGzpw9X5GZvqGiYuD7GiVJSIZ MEcjp4AXl7WYNcICRnRdLFnoVWPSFj8Ra7UWBPjTejzy0LNP3cEzVUOVskzMlP6OemwN 0NwkEufBkQ/k2Hb5E4P5BYKj77k9hAWzeRbFQkHRlxQ7ivRhvAvYEQXwngOKOC6jX6wI s/8SjaNm4a0e62d7+z4jqh04C1nxsqtdKenU6iXX9ddhLRdYKza5sY5Kdo8EhnqCOHqw rSKg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776470462 header.b=OMa+EjDV; dkim=pass header.i=@clients.mail.as397444.net header.s=1776470464 header.b=HIcQ1FeG; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Received: from mail.as397444.net (mail.as397444.net. [2620:6e:a000:1::99]) by gmr-mx.google.com with ESMTPS id af79cd13be357-8e7d8ce77d7si10039585a.5.2026.04.17.17.38.01 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Apr 2026 17:38:01 -0700 (PDT) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) client-ip=2620:6e:a000:1::99; X-DKIM-Note: Keys used to sign are likely public at X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net X-DKIM-Note: For more info, see https://as397444.net/dkim/ Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1wDth9-00000006PkF-0UVL; Sat, 18 Apr 2026 00:37:59 +0000 Content-Type: multipart/alternative; boundary=Apple-Mail-A2D0333C-EA7F-461A-9160-1BD674F278AF Content-Transfer-Encoding: 7bit From: Matt Corallo Mime-Version: 1.0 (1.0) Subject: Re: [bitcoindev] PQC - What is our Goal, Even? Date: Fri, 17 Apr 2026 20:37:47 -0400 Message-Id: References: Cc: conduition , Erik Aronesty , bitcoindev@googlegroups.com In-Reply-To: To: Ethan Heilman X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776470462 header.b=OMa+EjDV; dkim=pass header.i=@clients.mail.as397444.net header.s=1776470464 header.b=HIcQ1FeG; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.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: 1.6 (+) --Apple-Mail-A2D0333C-EA7F-461A-9160-1BD674F278AF Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Apr 17, 2026, at 18:04, Ethan Heilman &l= t;eth3rs@gmail.com> wrote:

=EF=BB=BF

> We've been trying to convince wallets to not reu= se addresses for 15+ years and have not only had no success, popular wallet= s have been actively migrating the opposite direction instead.

There is a huge difference between, = we would prefer you don't reuse addresses because privacy loss although pri= vacy is hard to maintain anyways and if you reuse addresses in this context= a CRQC may steal your user's funds.

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

<= /div>
For example most funds or very large holders have a pre-defined l= ist of addresses that they=E2=80=99re allowed to send to (basically exchang= e accounts to sell), and have processes in place to ensure everyone cross v= alidates 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=99l= l just presume that they can move the funds again before a CRQC. And many o= f 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 nor= malized pretty quickly=E2=80=A6

> In the face of address re= use, 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 pro= tected 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 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 this = is wallets advertising PQ functionality aren't actually PQ safe because thi= s allow address reuse then one could solve the address reuse problem in thi= s manner.

Yes, i mean I t= hink P2MR would be way more exciting if we had an efficient way to enforce = addresses as single use directly in consensus. I=E2=80=99m not, however, aw= are of one.

All told, it seems better to communicate to wallet= s and users that wallets which allow EC address reuse aren't PQ safe. If a = wallet doesn't want to provide PQ safety why would they put in the engineer= ing 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 b= ugs :).

Matt

On Fri, Apr 17, 2026, 17:02 Matt Corallo <lf-lists@mattcorallo.com> w= rote:


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@googlegroups.com.=
To view this discussion visit https://groups.google.com/d/msgid/b= itcoindev/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= /D13BDAB9-111D-4F85-942E-58F56AEBA946%40mattcorallo.com.
--Apple-Mail-A2D0333C-EA7F-461A-9160-1BD674F278AF--