From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 17 Apr 2026 15:05:00 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.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 1wDrJ5-0004Pf-8Y for bitcoindev@gnusha.org; Fri, 17 Apr 2026 15:05:00 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-415e1e9aa5dsf1968286fac.0 for ; Fri, 17 Apr 2026 15:04:58 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1776463493; cv=pass; d=google.com; s=arc-20240605; b=PYA36I1kOFChuaY2mQr5IO1M8sQZoV98fFXv6x/SNP/b8Pdwps7AM/VgnYzLCM793c E4moVQdwKnYpdI/4d6qeACj9wpXQ1ZbGugpXDc/WC/Y+7kJrNYsnlrNcf+PRYetNDB6I pBfAjfyV4mo3JlbmPz9riQYTjtyjrlaLOff1LJ+QtoxKv2XwLe4XDC9W4GjC86Ba53sP QExXFTGJfsQ5a/cnU0GUlr3FjPZ+ejNKIBeHgKNIsfpN+odMeGWBwnsCvFgSdv/TF9FN cTXe5NJXQ/6ouF0BdXNV1F1GMTDrSN7h7UUz9ihDBRYFVAmqVXjCwzHT8+OXbVYBmj6b T57g== 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 :dkim-signature; bh=IqF/LxkEERncK8b639yUJ6buL1QEQUCFJlny2lHSHtE=; fh=UaHETLFiswaObFngzYK9t/dl3RKIC4CUq8VwP2oigso=; b=gGOXtu6u9mywClDWDFwLZ0M5x7RRz9I+je5SwBm0NbzcunWzIAVfziV6OIoi2ioQTe JIo+7As+yByDDlUr4kFy0i49dDwocJv62pP0Vc5PIoIEvzNB/mtRE6Ndi/OvXlS1vxhp M/xfCv+p6HHZJcgRGILKm2klERgyZbFZi9wx5vfYsC1wAuKwLaN5qcq28wiUe9WkBNRF c7Ado365wepZQsdE1+VFGjvScFdeFQ84oyY2S+7dhKjFrNiqI+5MEXlY2x29BhcYW5en v8m1Gl6LlW2H51fXDZ2ucFhRzQ95hezYMpQbkiZXLdTddRbSEM+m9ND2KiEB6iI1WviD i1WQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=QJC+3DPl; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::433 as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776463493; x=1777068293; 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=IqF/LxkEERncK8b639yUJ6buL1QEQUCFJlny2lHSHtE=; b=A5VmVXCIc9iacN2qhpdSWZ5lPDibKBkyKA0j/4DWTD4+aYSrsr3J35lOVeH5wCFa5P w+mrrdxIC8Ds/IX0aJYmWw/txJ8U5Rpy8xQCNBHFwGLmjh8LaigiQwtSqNrank7Jhew3 tgx0LNnPDJnKnICLzA8/6edc6HnchY3+Jdq4xKxYz0ATV/LtrIeg5sIKv/h27cGvHIER /acAVoV/eexNd3SbledMFWZOlDU8LSxvUuuo6aGuGYepEBk1eEBhBYKvLQfVmi4Ymo8d IG9yWR7XVDbK6H0WnQWKV41CdeJnijHG6udB+wTGZLSItXPO0oxS1buAenAXHr7lPBzu 4Xag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776463493; x=1777068293; 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:from:to:cc:subject:date:message-id:reply-to; bh=IqF/LxkEERncK8b639yUJ6buL1QEQUCFJlny2lHSHtE=; b=DNSMmqRnEUzoTh4jspTR3AxGiVTqujCRwkQiq3Nkc4FfnxNof7jfwth/j5NFIWqxM5 w/myZOPWfsSamw2ZQpkJpNySyVt4uB4lfISYS4wj798ePKvexH+SQrsbjNVDEazxkXL/ CInSqeEs9/AYDHsfO9ZkUsYftmsuc0ynOE5Ppt0d4wGDXLmAuNB5OS6W4xp7HYXlv5Pb tJopw/s0CjDCTcZrNYhO5pGoM54aLvdUmHugZ3D/cblKIXnzaw9VqGtqZRicpUO7Xdsi iimpJPWWSGkqloRszhUo8wa03+UNyXUhlySLCDV2ioG5q7lBpNrLKX1jYUfEA5NTcAuU YxUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776463493; x=1777068293; 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=IqF/LxkEERncK8b639yUJ6buL1QEQUCFJlny2lHSHtE=; b=cZsl1sy9JSCXjpT9LdX/nUQz1vtExkKH3hMS8/NpB+HKm2N0iW2+SEj3SFCl8p1jSO TtLP0kX444qzTRGFwWtMzEy9GbpPNToQTKnTi/P3lDYyFlsK+Ho+fvcKNa0ByMDKDp1+ k5SbPS1pkFTzi7jZv2hvWjA+e7iejrXRNpAZqiEg2l3ZXvihqXiPAFrTws2lUPgq89ur egPNmd5ySZnKcYQ/XkoAA9nk/2I/5ufMoPxVMNinzBtBFx315HpwNCE5/laXODmP/Wia TekbSpA7gE1g6Ew0MIuXGTnlZZxH5veaJ00jTxbvdvll1wXkLdzSz1exCCaokwqvAWJk +Ncw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ/a0s/zzxTNvhJci9FmNTdrwdaZcvGRJJBPFgMbmwVn441rQdMxvCNPcAvJA2xoV7ehD6lFxJfBDkV7@gnusha.org X-Gm-Message-State: AOJu0YxLxXzqSXFlC5lbaZq0ygueZY0OKJc/55mMrpNoP4LKE3IvLc5y 7Agph5kwOt+Zlla8d6cxoT7uoTyCZZjTvfqAluwkhQo+zvizvTnj0lET X-Received: by 2002:a05:6870:9619:b0:417:5b7a:704b with SMTP id 586e51a60fabf-42aded3dd8dmr2909863fac.31.1776463492853; Fri, 17 Apr 2026 15:04:52 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiIH7ZN6q/o5SUwEa8T95BUTBzgSAa1YYyyNruHkiD+SQg==" Received: by 2002:a05:6870:e8d:b0:41c:5212:2c74 with SMTP id 586e51a60fabf-4280c4bb6e8ls1405706fac.1.-pod-prod-05-us; Fri, 17 Apr 2026 15:04:48 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ+Do4P84ccKmn0ok/AHrx9lc4+R86SZZMMdGwDtuZJsendKQI4+ALgAECdxxacH/Bld3jWCogo3yPla@googlegroups.com X-Received: by 2002:a05:6808:6902:b0:467:1504:eb13 with SMTP id 5614622812f47-4799cac4c08mr2772451b6e.36.1776463488229; Fri, 17 Apr 2026 15:04:48 -0700 (PDT) Received: by 2002:a05:6808:286:b0:467:e362:ec8e with SMTP id 5614622812f47-4799cd50cf1msb6e; Fri, 17 Apr 2026 14:28:33 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ9AZAwVL+tfUtdyuTxMBkZQ+ceGmi5rKXtYU5myFAVMaRiQ7pXl8mA0q0co/Ud4w9+qIM1qyd+koXml@googlegroups.com X-Received: by 2002:a05:6830:6603:b0:7d7:d198:3586 with SMTP id 46e09a7af769-7dc9518cbf1mr3176296a34.13.1776461312515; Fri, 17 Apr 2026 14:28:32 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776461312; cv=pass; d=google.com; s=arc-20240605; b=SIT7OvGGvb5Ot2k7fk9TD1urB4rLo6Q1a9k0WMI60e8uygdvz3vciUhH4z9dS/kIcT IsD2EBarvbHcPd3ScQnLRD5PgvbcsnzVk4gK+ly6vrZgKnwbohCb8qQ3iHI3nWfT/U3f CPoWWfrhjBqDJ6j2a/zf3r01PIM14dm7pjHzuK8XTHRPPtZp0AqCSLtSraen3D1ZZnBF uR24etEu2iz1KDZiqpUUe3eYwoU5R/Wm3uNQbq8bYt+UKSFNz2hfEnZX1RMW/SyrWxZd 1CS92B1LKWTcz5z4Z9saE5i7r4hNw/jdTpzt19UdafpF90++slCAktA3Lk5cWI/taLnn OPvw== 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=gjnW9YMNQKFjzQlNboxa2or2TqU1JqnnTd9NKw1BozA=; fh=pnAdC1LmYnq7W7HwFxbaCzbBrlw5s2D7arfvezFda70=; b=b/eU0mIWYmaSv2q5o90P6WXMPo4A78jvSDJElY8pW86O5DyTgutT/0Khqv8gOpk3lG Ly6BnjgixNB/63v3oMiFoaFM1efwnT5embYYemYpidx+XjYvHO00qFAzcET8B1XlYxzu gJ7/oyO7uHQFd9399WvBa6PpsANPOFr8+bFvfIlQHDLEhhYDb4NNN3aYobhc56tfgbsM kf2VDn0Tfpy8M9TiBkWRwsloSmtXV6xQIwqdSl5LoB3MxJec8yFoO7twnXwS64qSXBSy wpq9rKjNShPDVOVpJXXL4a4z6FCjJPT6RLPhrDy4vHTGUJlt2e7wR+3dIusHi+SYsNT0 YEww==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=QJC+3DPl; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::433 as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com. [2607:f8b0:4864:20::433]) by gmr-mx.google.com with ESMTPS id 46e09a7af769-7dc97432ebesi107240a34.0.2026.04.17.14.28.32 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Apr 2026 14:28:32 -0700 (PDT) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::433 as permitted sender) client-ip=2607:f8b0:4864:20::433; Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-82f138a6d5aso552379b3a.0 for ; Fri, 17 Apr 2026 14:28:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776461312; cv=none; d=google.com; s=arc-20240605; b=UMnY3p0+w4d4jJ/aab8/jUIMcvFdXVgzgdInGztNd/9Omh7Ob5RMVTGCIiuc1YHoVs 6rcjxr5JTdXZuOqmMRIhA214jTrOMP5HclPaaNZE4+n/S2tXVEG0UlKAYsAJtkXBH75j 8D9KgRzt06iJ8pUjeN0sYsG1hWdoS7zkaXMZLbBuMwOqcbIn0mtFUGTNanCqnjEVBi1V IoAg+7gkhVoZm90icXUCId7nBzx29TFN2v6gOEjSAolmt5rmdMAgkRLa61nDIvtoX1ta PcevH/6EIrrm3NHxJ/SfgWbVv26OEjRxsIAKoBSCXVy986LjdKSgUeVLo4lDxZQmPyON l9/Q== 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=gjnW9YMNQKFjzQlNboxa2or2TqU1JqnnTd9NKw1BozA=; fh=pnAdC1LmYnq7W7HwFxbaCzbBrlw5s2D7arfvezFda70=; b=esbROlnCnPUEAEKp0xW4tJmSIq7QALKAnfgpbCPWN8NLcz42ltk25VbWwICbgLy5Dc lxzHfxM65ujUmAHitRJdQ+jvfT34LPOw184hLMPUsmyGEIYS76oQ4qm2e3MK028yeDNa vAlvUB+Bxc8L27YtvBngvEx7AwcF1/cOF3ALFzwkcXWkX2btgwriReVDJllikD0JDRxh mV5QNtgteSQoLrqLPAUMGE6N1G3GgIPL5n4xv2HOAnAqykb9q4VcZO+42bPo+1rDfYJg nMTjgULitfcSogCWuTzosttpmE60Xx4pg4N6ouWmjalwSoVyNxpZ5WvYvUghkpxTlITz HkRw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AFNElJ9rpSTxlhoKrYhvHe1xcxbXzI7g+rrggEp5RXARRXLq9GdJB2/iI2NDdpfNTPujOOXUEVAfyZ0cMnKF@googlegroups.com X-Gm-Gg: AeBDies+bqqoTuTmYxsMmDUuIgUHMKvsaFVfDLmvcfXnUXcHneJxoazVXGuzO7qWlbk 4gTRQ2jPNMoFnxvt09N4qX3Avdu7ZxYun4lqmxZMTamE3Xys/8kbnxYXRlRiivNHxqWfxSnrF84 sRKf/Pz9vhTwLUs+J30JeBWTOBLzGSXL2SXM5kd2Ljn28X9DWmjLa7w9nR45a9dBwTlIWLiJ/ku aImcfqOjE544SBxHAfkQYjAvPhJQAMDr888/LRHO5I9EjZ/Y3A7gm0i1va94ouw31WUpvrdOisL zEzNQuD9E3uthFB4pg1jaX4iEUAYtI6L4rAutV5B8XCu0aOhnxR2Desj6uCW5a3u8jAdSWEfAeX c8NG1hTBmqWbaL8Ro8HsnHG1ba00RBUHB73AJW+2H6Lpc/2e8WFB6ivO6vpXLzbUHWILGbB8ehX tOpXXplP9nY0uJgphQh3K6fyzW8R8lyi6QZbTW8bpyLLKjLyNNv/eKmwAo91law36REczHa7d2Y Zwdp9OcMSn1jCgnHGTw X-Received: by 2002:a05:6a00:299a:b0:82c:7876:a027 with SMTP id d2e1a72fcca58-82f8c86b4c1mr4939987b3a.18.1776461311604; Fri, 17 Apr 2026 14:28:31 -0700 (PDT) MIME-Version: 1.0 References: <05E6D06B-1F72-48F6-B4F3-0225675BCC1F@mattcorallo.com> <600f95eb-04e8-470d-b6df-cf725e48d1b5@mattcorallo.com> In-Reply-To: <600f95eb-04e8-470d-b6df-cf725e48d1b5@mattcorallo.com> From: Ethan Heilman Date: Fri, 17 Apr 2026 17:28:20 -0400 X-Gm-Features: AQROBzDqhH-GMuEZObMAxZ4tnO_1wkrlGd2M4p4yl6idevWoh9eDAwEu77IpdCg Message-ID: Subject: Re: [bitcoindev] PQC - What is our Goal, Even? To: Matt Corallo Cc: conduition , Erik Aronesty , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000006f79b0064faea17b" X-Original-Sender: eth3rs@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=QJC+3DPl; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::433 as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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.5 (/) --0000000000006f79b0064faea17b Content-Type: text/plain; charset="UTF-8" > 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. There is a huge difference between, 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 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. > 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. 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 this 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. All told, it seems better to communicate to wallets 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 engineering effort to support P2MR and PQ sigs. 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 should > be seeking 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 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 as > much bitcoin as they could've before the migration, if not more. We maxed > out our success metric but still failed, so that metric must not be our > 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 screw > 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 properties > with different values. > > > > For instance, I put more weight on conclusive security of P2MR, whereas > 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 future > 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 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 > 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 share > 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 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 > 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 convince > themselves the CRQC risk is greater. Some will move too slowly, and many > will likely regret their choices one way or another. > > > > I believe we cannot effectively optimize away a problem like this 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 about > 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 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/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 email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAEM%3Dy%2BWi1ERpSCEFadYS4esGSPauM%2BvoNkSSjZzqeUijWESyFg%40mail.gmail.com. --0000000000006f79b0064faea17b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> We'= ;ve been trying to convince wallets to not reuse addresses for 15+ years an= d have not only had no success, popular wallets have been actively migratin= g 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 = anyways and if you reuse addresses in this context a CRQC may steal your us= er's funds.

Wallets = are likely to be more responsive here than in the past because the stakes a= re much higher.

> 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 insec= ure wallets, you still protected 99% of the other P2MR coins.

I am NOT suggesting or proposing this= , but one could require that any P2MR output whose EC pubkey has been leake= d 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 this allow address reuse then one coul= d solve the address reuse problem in this manner.
All told, it seems better to communicate to walle= ts 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= engineering effort to support P2MR and PQ sigs.=C2=A0

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 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@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.co= m/d/msgid/bitcoindev/CAEM%3Dy%2BWi1ERpSCEFadYS4esGSPauM%2BvoNkSSjZzqeUijWES= yFg%40mail.gmail.com.
--0000000000006f79b0064faea17b--