From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 17 Apr 2026 14:02:28 -0700 Received: from mail-oo1-f59.google.com ([209.85.161.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wDqKZ-00030z-KX for bitcoindev@gnusha.org; Fri, 17 Apr 2026 14:02:28 -0700 Received: by mail-oo1-f59.google.com with SMTP id 006d021491bc7-68b313c42e7sf1399023eaf.2 for ; Fri, 17 Apr 2026 14:02:27 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776459740; cv=pass; d=google.com; s=arc-20240605; b=ZKzto52GvGSZ2OenWFsYd5jFflOn1dEz4TtuLd8v3PdjTo+l4Hehgwa7Jeu7Li+Vvy HTfnPzNpDXhQIWjdOphL4h1VpIRdiGfopB8NTeaoaXfespr6jND1C+D5rEXvmiAvK1mt /u75JlCEGc0ZJvST4u/Cceh+J2TjFXRKAl0NRJUbGyyKfOp3yl/Iq/KT8YOFfF6UWKJ0 znzlc6AkNGJOT/7zMZN4OBZb+jkPZYHLoCMQdmn3ttn+J9xFhy/mTkA/3+DAN4Scp4fb wfR602BQ9dYQ030o3e7u3gUcQOCadLIeahIIk7yGPgBx5/Gil0KVaRIjXlOEZqYPq90c AYnw== 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:content-transfer-encoding :in-reply-to:from:content-language:references:cc:to:subject :mime-version:date:message-id:sender:dkim-signature; bh=l/6Tty4ZqdA8SThhIQz1SP4J1PvrBGJWddi6Ev47uU0=; fh=P0u2T7LAGy3uzrACrauuHCrH9Fi8qUDlGy7XzmcrxI4=; b=NQFDrIRdQtJBCckxVNDgxq1xUiuayGe0cOsXjtPOvv+BZ52TuE5Q2ZA3f+sOqGPjCy JJLgAALZnI++8wW5Hr5Sgz7EfZGNJWJbim4qlw3oRDoN6E3vXGPaQuBsY0DZKhLcZSQo DROJ6WMoOcFTep/4bJDB3BZvzELe5m5oMGTUSyq42NksIB2NEPJdOQHuikS/vOsJTlVu 1II4Obsz7Mtl92Nr2xuan/NoScREtDddlkVEgE8Q7Np84D4+hbWgHWU6t37Lo+r9AS2t CvLcL3MReIJRQ2U8dFwYvg1EuZt6/ASNBmvKWxa1s30ZVu+W8z3FfL9xcQxJH3Lrs+nx qfAQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776457262 header.b="MGKALiL/"; dkim=pass header.i=@clients.mail.as397444.net header.s=1776457265 header.b=kEc15ABY; 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=1776459740; x=1777064540; 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:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=l/6Tty4ZqdA8SThhIQz1SP4J1PvrBGJWddi6Ev47uU0=; b=iSBuW43WaPPaKThgkorsd+SBNwqRpjE5ato3Dck4kJAC6vyBRZbcHOh6TC037VOZrW dAe9y0N2SZenQg5IkEGEPNzgLHJkzwdCmF89JBCLerHZFJxdaMAIGfUJK3w35bqcBIKI iy61ErynF6QEJ44NBo+WZOh/D7/vWWbnfkQ4K3olKlc6zYvTAzXZpJi6e5A8VUi3UtVv fOeciKq0rsw4Cnmc6wvdkmhdpMx4lm8FNUqPc6JWwEf2LDYMdDIJ2r6npeZQjm9o0hCc 0IfxWALm5egyEL3uSPhRahCe7CZKXdGGLQE/4gxVNAcpoo4pTp0Du6q6UaepaPjj5om+ PfWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776459740; x=1777064540; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:mime-version:date :message-id:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=l/6Tty4ZqdA8SThhIQz1SP4J1PvrBGJWddi6Ev47uU0=; b=CZ32qnKDNRSv20an4dvlC/wcVHaS6RyjoIy1q00zThOCKcwvnK8ZYPMZM2pI/tew23 03mzgdJrlwdzk08FpeoZxLlvURekIjIV48qk5gZzKTYrK5vuWHjqOjrnA/S8iSXwq7Gg PLiCW6UHU8X4y5Eab9EA4e0q6uSXe4T/u95+KFXXsXpiJxuaTkb2VdUfForWsX6esrpP 9Ohuu1V7kwQ1uV26CyWb9cPoqsKF2PftS9AHClIhAhOhAQVxL0ixxS8pg161V/Twc+Xl uNers8v8DzMsvi7uqW0CphdXjSKUdxe/KMbd0HFBVfOtJOwqT+fnOIOJSTov5RNeDMGT hwDw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ/xDLLnmR6K5jegFCKwief/eGYCfay/la2EiIWFzsD2yBGJtE6Et7ZaTmn0KcPd8ARtoKMqcLp44B/p@gnusha.org X-Gm-Message-State: AOJu0YzqhxgNpDIMyFhaUvqFp6Y7SDqspZvocFKBZmP9Lo+rKl/o+6eq +mlnYuxOQIDzrTTxV8CLIx6x/kQhTuHxoHwtNYfpqKVW6iaNJJX5HRSH X-Received: by 2002:a05:6820:620d:b0:67a:2ff:91b0 with SMTP id 006d021491bc7-69462e21450mr1857567eaf.3.1776459739846; Fri, 17 Apr 2026 14:02:19 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJ8qQARykaW0HIjTNQdBTirhwW/TFXOnJfsBs0E8RNaIw==" Received: by 2002:a05:6820:1c8d:b0:67b:f5b9:99d8 with SMTP id 006d021491bc7-694375efb95ls933185eaf.0.-pod-prod-02-us; Fri, 17 Apr 2026 14:02:14 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+HgAOltSSexrSfZCImga8Nn/tzSdvWjHsk/S7U93RucQwLtySh7IN6Rw3z3Uo1YRihbn9cHLHi+SyT@googlegroups.com X-Received: by 2002:a05:6808:4fe9:b0:467:3f4:907b with SMTP id 5614622812f47-4799c878c3emr2369598b6e.7.1776459734802; Fri, 17 Apr 2026 14:02:14 -0700 (PDT) Received: by 2002:a05:6808:286:b0:467:e362:ec8e with SMTP id 5614622812f47-4799cd50cf1msb6e; Fri, 17 Apr 2026 13:44:27 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ9CDpzRfUaFL6ZF90JldD5eRKz+0CACCQvzFf9gQ3rjSkclYlzi0F2RllHA9wyi2yxajYIaPRZgP0Z/@googlegroups.com X-Received: by 2002:a05:6a20:3d1f:b0:39c:c07:144a with SMTP id adf61e73a8af0-3a08d887209mr4292213637.36.1776458666678; Fri, 17 Apr 2026 13:44:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776458666; cv=none; d=google.com; s=arc-20240605; b=TijLV0zz/0sKyeNAHWymSsvz0uVsFosnZ2Qyc8Tsx045j8Q/MzteSkmtP+JTOoQYWU oNcINbfvQvjovz4We3t/toYemsLwvcRPDNPvATD2stk8tugXBDyiHfSeCAeS91nTA+Hm kRwlJkiSsQhfOGeYfcsqTaHyWmLWYVtlLQVy4ZlmZQNhGjhuTtuw51jT/A/ZtAtCpZWI V/mDewPyl/aTWoR9HnoiTDfhkO1apGkSOe8mE2Gl7dTd6K1EdTx+nJDkOH0vCirn6NwQ 19ZjH5d6b1DU5l9zKLlOhv6ojFCw5O+MPsG1WumG5lnHtj1sfXag4uZWWjuHr3GnBKUC mssA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:mime-version:date:message-id :dkim-signature:dkim-signature; bh=UgNSjgj2tQJcpM9JjrQynsDYN1AoJ68rBD2yOuoY4Es=; fh=uEWj4pBeVKS+CbH1pcujNUSi3LsuC+l1wdM6I1Oz8Qk=; b=igoHk2Xn1P2PMuKvP4gOGp7ryIOQCNI+GwO3U1T2JPJCOFNqzp+s6pJWPcCs24QkmX z8cb7vBd9qCRgDn+7fL89/9Ck9nrfUbVoyMFvbB1s/LJQGitGYva1jDVJdtaOILO1Oz9 qxPzRNsOSmTAJD33jp5smUL/dzxKKxi7ud8NZyOSX3SbNzca6AxdqUrBZB1sFW5SLV7Q ONH+W6igLkhYVmr1zog1QO+T+WFrmGHJHBCxsz1RN5zaj+O/cMrryD6mR5G8coBCyqwr +GA5eZiXXemV/0aLinMVoP/Wr5VyiXctseMkcirYdpRQGocrrUbcaiPEzCpQ2DP+Po62 mRIQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776457262 header.b="MGKALiL/"; dkim=pass header.i=@clients.mail.as397444.net header.s=1776457265 header.b=kEc15ABY; 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 41be03b00d2f7-c7976f0f9d7si102421a12.0.2026.04.17.13.44.26 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Apr 2026 13:44:26 -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 1wDq34-00000006NwV-3nkI; Fri, 17 Apr 2026 20:44:23 +0000 Message-ID: <600f95eb-04e8-470d-b6df-cf725e48d1b5@mattcorallo.com> Date: Fri, 17 Apr 2026 16:44:21 -0400 MIME-Version: 1.0 Subject: Re: [bitcoindev] PQC - What is our Goal, Even? To: conduition Cc: Erik Aronesty , Bitcoin Development Mailing List References: <05E6D06B-1F72-48F6-B4F3-0225675BCC1F@mattcorallo.com> Content-Language: en-US From: Matt Corallo In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776457262 header.b="MGKALiL/"; dkim=pass header.i=@clients.mail.as397444.net header.s=1776457265 header.b=kEc15ABY; 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: -0.8 (/) On 4/16/26 1:34 PM, conduition wrote: > Hi List, >=20 >> 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 should be seeking= to minimize the chance that the Bitcoin community feels the need to fork t= o burn coins by reducing the number of coins which can be stolen to the min= imum number [1]. >=20 > 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. >=20 > 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 m= ight not disable P2TRv2 key-spending in a timely manner. If the future comm= unity fails to deploy at the right time, a CRQC can steal at least as much = bitcoin as they could've before the migration, if not more. We maxed out ou= r success metric but still failed, so that metric must not be our only goal= . >=20 > 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, flexi= ble, and long-term-secure PQ migration path. If we standardize this and mak= e 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=20 actually a concreate goal. "optimal, flexible, and long-term-secure" isn't = something we can optimize=20 for :) > If we can agree on that, then any further disagreement will be due to a d= ifference of opinion as to what is "optimal" or "flexible", and the correct= trade-offs to make on security. We all weigh different properties with dif= ferent values. >=20 > For instance, I put more weight on conclusive security of P2MR, whereas M= att 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=20 trying to convince wallets to not reuse addresses for 15+ years and have no= t only had no success,=20 popular wallets have been actively migrating the opposite direction instead= . In the face of address=20 reuse, P2MR has zero advantages over P2TRv2. > There are also differences of faith. Matt puts more faith in the future c= ommunity to activate follow-up soft forks. I put more faith in wallet devel= opers following standards and in users proactively migrating to PQ-safe wal= lets. >=20 > Based on Matt's previous emails, I think we both share the same LACK of f= aith that a majority of the UTXO set will migrate in time, and we also shar= e the goal of mitigating that. >=20 >=20 >> 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 o= n the total number of coins protected, nor, thus, on the probability of a f= uture Bitcoin community feeling the need to burn coins. >=20 > Also agreed. >=20 >=20 > I didn't find any public statements from your cited examples about quantu= m security posture. Since it seems important to understand the wallets' sta= nces 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. >=20 > Having worked with such wallets before, my expectation is that they'll fo= llow whatever is standardized, as long as it gives them more market share a= nd as long as they can "npm install whatever" to implement it. I'm not triv= ializing 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 re= quires a rewrite of a=20 bunch of key derivation and backup schemes. P2MR is also asking them to ove= rhaul a UX decision they=20 made with lots of user feedback on top of that. > The harder question to answer is whether the major wallets make the PQ ou= tput type the default for receiving Bitcoin. Big software companies are typ= ically very concerned about bugs in new code paths, and they weigh this ris= k against the benefits of any new feature. When deploying new features as d= efault, they often do so using A/B testing and incremental rollout techniqu= es. So the earlier question shouldn't be binary. It becomes: How quickly wi= ll 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 appearin= g in the near future. We and other users can try to lobby them, but ultimat= ely each wallet's decision makers must eventually convince themselves the C= RQC risk is greater. Some will move too slowly, and many will likely regret= their choices one way or another. >=20 > I believe we cannot effectively optimize away a problem like this by temp= ting decision-makers with slightly lower fees, since that's not all they ar= e worried about. I believe we especially should not try to do so at the exp= ense of conclusive PQ security and long-term optimization. >=20 > I think the crux of the P2TRv2 vs P2MR disagreement here is that Matt bel= ieves P2TRv2 will induce wallets to roll out default PQ outputs meaningfull= y faster than P2MR would, and that this trumps arguments about post-quantum= security or efficiency. No, its far from just about fees. Its also about maintaining the goals that= we had going into=20 taproot. And a bit that P2MR doesn't accomplish anything unless much of the= ecosystem changes their=20 processes substantially. --=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/= 600f95eb-04e8-470d-b6df-cf725e48d1b5%40mattcorallo.com.