From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Apr 2026 09:30:19 -0700 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wD384-00082m-H9 for bitcoindev@gnusha.org; Wed, 15 Apr 2026 09:30:18 -0700 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-4236c3b8f32sf14081498fac.0 for ; Wed, 15 Apr 2026 09:30:16 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1776270610; cv=pass; d=google.com; s=arc-20240605; b=CvjHroS/CZdzdFWD7IUMbAA6ORw45PL40veZvoj/xHkJGjIiyhCYsvZd5riju5Iwmd sAWGF/cIwnYK8dXS0K4Y7QK3u+gkUhdyo8ucf+rJleOvd1/FTF6V3k3k5IBdTHUHk0z+ Ljvhneh6scFUHPSUdlcyBX+gYVISfNaaP5n8IAJnlHvDBq7Np6CnG6zTeyx365DXLTSq UFoSgNBtpo4ytps6EOflJ166KiJLKhj0mG6S7sBJBwAG7uNTz07QibqrMdRZ2eB7NGOi UcmhvpXwrvkVtS1Uw99EF0s4z5puoXLqxDv+87qZbN4l3kRur9TRuyhWZXg/bACLK+t8 U2HQ== 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=PmBTPE/gPODysbtzcP/9ZS3+WA5B4sNcmHClFOMdu4w=; fh=c+I7W25jMkcD4YHxmgOGxWQYu31QG/ZwI2TKmM0KREU=; b=ljJCib17/HAX+7GVUIQl3VKwSSjuNsmUAd0a+O4HlulZJsxbuR86oYtF0JIJcV/sHx I8++9ZFJtgglk7sCiiEYnVHlre6fMFemtwTDDCc3audfVvtJfSeDJAUGd9kRWNW/GPiA LMx8CLz/1GuPyCSrIWf+ADzpvfC7DM/WQAGpLyCBbShP1jHfrIvr9UlbCQk3QpYKFlIf 6Aopc+WTISOf9m/yEVuHwYUBrDiCXPLnI77QyP5NurRmcHWhh08tnmzhPhlqDYrjOEnZ CeEGN9Q1H0P+tZWyh0PHKjqn6gGJ/D77OedX9Gq++cD+ukN90Ldw9355Zgalyh6qD8U6 33bw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=Tc17G2ho; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::632 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=1776270610; x=1776875410; 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=PmBTPE/gPODysbtzcP/9ZS3+WA5B4sNcmHClFOMdu4w=; b=CVGjv6xHxsRlLIb0mP673guMV3T5MQ/byPHOEbHSFBMvB3LFMtjEsdht2EYCTiLXSS IV2xgD6cWP90Nn9FzfAdXQ+Uo929YLuwa2yfw1AN1qt26psDs32w8TMrzDrVDZXunjss xH6bVe5u0FOBxoZ4ZpTEJE51eM3CQWtnTolJELmQ6zOTPh5Zx+LkM1/UM+6ThbW6JUFr 52kMPGG8R72n2hCqgizLoWPHb8wgrc7PshCAVhpK1dQnfOqbVTgpADBGLcwkClgcIKa7 lv+v/Y3OPeDagVA6aB4RPjpBIf+yJ0y9qSZYWkjfE0QTlVxhOQPEOgIZv6yte/PVh6/V dTjA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776270610; x=1776875410; 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=PmBTPE/gPODysbtzcP/9ZS3+WA5B4sNcmHClFOMdu4w=; b=EEvwzbPUCEvKZPX8Y+MQqYR6G+6QbwZBU3evPTdsg2CIeNSHBMd6+AhSNFhKNNYqTN 7m5w4qRvcyL0Km60E7+uzpRs3dNx/IxZcHs1FJAwKLYu1JIVI8k7FZwtJQpfM9nJ0Hxl LE5Pv/JAROOTNHJJDM0NZIVNkfEtqjiWkHTNHAWRdI6xwULwxvM+oYTD+UHDBQKh8WZP Lo1w/OPIOb0I8/hznuooSKBGvrwGEpua6x8hpsLDOJ9rCOF+FnlAAgv4mQFqew7Wy33X YfXtm/kw4csvMdZXDoOXMiAor0WLKQsj8klTEhBDEqbLpZXI/xSNETljjVL02rIe8GFq /o7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776270610; x=1776875410; 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=PmBTPE/gPODysbtzcP/9ZS3+WA5B4sNcmHClFOMdu4w=; b=LmhBIwRoFsGe6b6JtBzSIF3xZ32PCnqYetBGofzGn9w3AM9L7Sonik362okTtk8I45 q5FgobRICvNTBnzHCgSOjofzB4lzFYdPh51YQA6qM1NCwMw1YLRo4oqGphXbhmE7+J98 4vpuBb2k6D+QeGVlCP8eaiysyxFxcvfOK9vVrqzMm9P/Y1HvgJd2YSgUCkMK4CmdlgQV EreMcH6leswuPzIXrgekadWyHi6ZPJUr9YARU7gVonj5odUxLxFEIxW4GA3eZNyUQm3T rP5KKjSJtGFt31j5yGcEr4J8lJDEW15EiwJQ1nDJ6Gbl/h2AHOz7TQaX9LF836CxzzzD 8EKg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ/bWQyt+KeDilSl1PbJZ67Wok5m2MkmvU5sh7KiwdI0ZjnckcGywwuR/wbRXvvuusmLLgKxYPauhTpH@gnusha.org X-Gm-Message-State: AOJu0Ywza/+hksCjkxm9wuK4dGvy5n6p6u+OzGykhfInFyb1uBxN5SEb Ou/+kx//AJ+QxHrfjKY5+meqoUuQYSwiuu4Jyq6fnNTYny4ePKZ0Xovk X-Received: by 2002:a05:6870:176b:b0:41b:e8a0:8d8a with SMTP id 586e51a60fabf-4280abdf056mr154586fac.4.1776270609846; Wed, 15 Apr 2026 09:30:09 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJPy3lknP3njKzgsIZtdJ98GMVtcNZj5W//js8BPaZGeg==" Received: by 2002:a05:6870:2144:b0:41c:3f51:3b83 with SMTP id 586e51a60fabf-4246e939c76ls230883fac.0.-pod-prod-00-us-canary; Wed, 15 Apr 2026 09:30:04 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ+Mycb+ncMBbEgPbUGd+iVtlS08UatNhBVqEojFQtJLMN9idq0W0sOXhxaHedCOycfmkGqCC41PQxN1@googlegroups.com X-Received: by 2002:a05:6808:3205:b0:46a:17b8:bd7f with SMTP id 5614622812f47-47984fff47cmr117547b6e.19.1776270603959; Wed, 15 Apr 2026 09:30:03 -0700 (PDT) Received: by 2002:a05:6808:30da:b0:46b:22a1:35fc with SMTP id 5614622812f47-47974646e16msb6e; Wed, 15 Apr 2026 09:01:30 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ/vYqk75lOlOfCPpYBO7QGCBT6XSOaAgVvHWC/2VPV0Xtrrw2pcOUQbwBYtPMImiqBA+OmQQ8Npl2xn@googlegroups.com X-Received: by 2002:a05:6a00:6c81:b0:82c:6b16:c894 with SMTP id d2e1a72fcca58-82f764f6321mr77522b3a.20.1776268887945; Wed, 15 Apr 2026 09:01:27 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776268887; cv=pass; d=google.com; s=arc-20240605; b=NYKlwQav94AOQcNcUALgYyX0nEtXF0mEVeps9uzIRgmu+AENVWFzW7iKyDmogW8ZVv WMjoLQ+8prImfG1qLP3/nl5bwfgPLPJMZb6RDgPkeL4VhvnImNb4VIJ1RvdE30/xj6Bw vh7Z//klDyoIbjCzpRYjRm721wuI4J35+1n9J9cymwSbHqi7Qxym3fo4idhsxSLH6g1K IabTYIatkD7EYrp9iWZTibox0APdG0A4fD04P9xMRN9WMzLayl8pBqFrnmniRG7b2+EJ YZyaTl41jaQSVe6G5uHHXDTSGlmhJAWSD+jOhJFq1gWxd5G8OFIhS4+eMIiHC5Pz0yG5 2EVw== 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=Eggs/LpKpMRMtNiVmdfe969+jV0/Mb9k1PCmSf1A3ZA=; fh=/I7Nsg2i1GukIl4fztSKMheM3VBjB1lNLsW4/4EkiEQ=; b=Sx9trqBJ3ZA4pYCJYQ0VwVXvUPypzGrDNW6rXHXFS9v0udVmdoExbvJNGEf6ZAREzn ieoOZ20HZBccp+QsXtC626qe/aQmM7zyqgjyoFn2DuJZIO5acsgwIO1TM4s8LhIEK34m z5xjGP9Ujyp3kFOXOKOkspvmGEbq8+xYsV5T/dKAS82voXKqsnA0qNRbxL5iUHZZ+jOA /2f9Zg3MVNHfdIUEP6yRwzXLkWW8T0IzqYHMe37cCkZ/g1G0+Kr5JJxi1cYieyN86H2E xG0hKboPELACTTYvgJlDU04vH1sGMCdVis/3xOpjjqYqP/OtyUJZrkunNM3zlmP4x/2X AmvQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=Tc17G2ho; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::632 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-pl1-x632.google.com (mail-pl1-x632.google.com. [2607:f8b0:4864:20::632]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-82f6739aa55si81884b3a.8.2026.04.15.09.01.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2026 09:01:27 -0700 (PDT) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::632 as permitted sender) client-ip=2607:f8b0:4864:20::632; Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-2ab46931cf1so43950225ad.0 for ; Wed, 15 Apr 2026 09:01:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776268887; cv=none; d=google.com; s=arc-20240605; b=fnFtUcm3oVucC4VPlQ3UCjpcE0W6fY4BSQ7084RaPa9VR14EWO3mEWgvCrMzVNHX7e lYZFbdQ7dOZUDIqI8hdSZ6/yiqZFEFI56F8fbMQAQWpnFqao/sD4VtgZL+LPW7Hxpb7r vAQhs4WgFfn7h1NCQYKzCxQlPbG/7XVCiPBXg96MIO3tkI1is5x1IGkyN1TqkNYVlov3 sSnQSo4Q8AcG04+MT3NPGBpK1BeWD95bG2VaV++motCEibCnrwY1zL4kj3xhmpoWHZJs cxhZm0J6w+NDKYtyLCLBhmZiY75PP1E55Hq1cmn+abozj6/Mnm03TJY2bhTHmltNvmr3 iK7A== 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=Eggs/LpKpMRMtNiVmdfe969+jV0/Mb9k1PCmSf1A3ZA=; fh=/I7Nsg2i1GukIl4fztSKMheM3VBjB1lNLsW4/4EkiEQ=; b=KMZrQ2h/i0YY5tByP6Ar17gfO2cptKRQuidUpwrgYk5NfefbyfvJosMAA1NeOL0VFX 2UYAqdaTK+wI0X8G1JSUEd0MOuvstua2ovl3Uvzl6ULCFTdXrDHzKShhb5tJOgxq7TVZ 4oB9/sxpN7I+VPhAKo7PWhuN0ScDMPZUcrQsqC+uHF2fwinYbq0R6r+xjsNxLySVMyb8 x94A3X3ZGTBePtoqyVrigIrDEx1y88kAS/xmIWcVIwzPor/b06TiHXbR1yZbah1jvjDT 1DvUGn1tsVbfSckQFBk/1HeDNOSeqXb2yFMPksa8H9J1pHYB31qI83axGv4Tr/4W0AiT 7lQA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AFNElJ8v5QLuzM/Rq6on118WrrMGWCzGSVglxShZ1+jNEiJHRm7fergMi0/eEMQ//juRp3Ybnmigya4pb4RA@googlegroups.com X-Gm-Gg: AeBDietmmqp4+h0720FaHkDRtS9GtHGZhC2BVR1jeNfL2jayCN/tuQF4XowZdeFRYRL r5L2HzcquH8bJ7oNE39prygPxfun6wW635hgtm+jwLe7CJugsIC64Lo9bsPkdDJNlnicDbq7yCO YX7rIkJtgi1lpdPnenJ3C9mI/JxRkfWYSqwnTwMgInT2LFaeFzYLzobYLmMrVFSuPkUyRqpzvCr usaTl3NH691GDFxZreYTMxqZGwuHRZI2ytsKm75cxTjTsaCRy3ZWWIw13UEeZGbvgyoBzBYkLWn xMNPENnoI2mOAvTa6M2CZQ3LWqEf8XMK8oBDBmYpO7VoekSgEMxFXqLZIByebWOycPpzzwZ89gp 67i2SoyJ2aLUCcxFLZxMIHvrrbQaXaSw2nTziCOAT/Ab1Y7wOUo1DqH0HSupxuZsOWSaQEtGe4T 6LrG9Cej4nuMC8xe8uNx2uD2HP199E+cEe2l24J9JZ9W5a1m4KSte4+ec7QUDoITHkUMODCjPVh lLE5TA+P+U3Tj7AFg== X-Received: by 2002:a17:903:292:b0:2b4:6320:8d0a with SMTP id d9443c01a7336-2b5ea916ee1mr1398805ad.0.1776268886961; Wed, 15 Apr 2026 09:01:26 -0700 (PDT) MIME-Version: 1.0 References: <779B3675-93F4-4175-84D2-55B6EA8930B2@mattcorallo.com> In-Reply-To: <779B3675-93F4-4175-84D2-55B6EA8930B2@mattcorallo.com> From: Ethan Heilman Date: Wed, 15 Apr 2026 12:01:16 -0400 X-Gm-Features: AQROBzA8_P_-2FqldMbZsIMz5lacTNgwOBCQl0f2Y1jmUUbSiZ9Ws9dgBCsr8Ns Message-ID: Subject: Re: [bitcoindev] In defense of a PQ output type To: Matt Corallo Cc: conduition , Antoine Poinsot , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000000871f3064f81d483" 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=Tc17G2ho; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::632 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 (/) --0000000000000871f3064f81d483 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe we are talking about exactly the same thing. A P2MR output that can be spent with a EC leaf or a PQ leaf. Is that not what you mean? On Wed, Apr 15, 2026, 11:17 Matt Corallo wrote: > > > On Apr 15, 2026, at 10:36, Ethan Heilman wrote: > > =EF=BB=BF > The proposal is P2MR with PQ sigs and no Schnorr address reuse. Address > reuse in this setting should be treated as security vulnerability. > > > The context was a discussion of using P2MR with a EX fallback =E2=80=9Cun= til it=E2=80=99s > time=E2=80=9D. This avoids the substantial fee and functionality-loss ove= rhead of > hash-based signatures =E2=80=9Cuntil it=E2=80=99s time=E2=80=9D. > > Yes, of course people could opt to not do that, but then we=E2=80=99re ba= ck to > where we started - not solving a useful problem for those who the problem > actually impacts. > > > As such, P2MR with a EC-based key for short-term efficiency reasons has > the same quantum security as P2TR or P2TRv2. > > This is incorrect. > > 1. As long as the Schnorr pubkey has not been leaked by the wallet. The > wallet is PQ safe. > > > Right, the context is a =E2=80=9Cnormal=E2=80=9D wallet which transacts o= ccasionally. A > pure receive-only wallet is fine but that=E2=80=99s such a narrow use-cas= e I=E2=80=99m not > even sure it=E2=80=99s worth discussing? > > 2. Even if the Schnorr pubkey has been leaked by the wallet, if the PQ > leaf hash is not publicly known it is safe against long exposure attacks. > > > Huh? If the address is reused as-is (as is the case the most popular > Bitcoin wallets today) a CRQC can trivially steal the funds with the EC > key. What am I missing? > > P2TR is **always** vulnerable to short and long exposure attacks. There i= s > no better wallet hygiene that can fix this. > > You are comparing: > > P2MR + PQ signatures: A wallet messing up their implementation of PQ saf= e > transactions and introducing a vulnerability and weakening a subset of > outputs. If implemented correctly 100% of the outputs are safe. > > vs. > > P2TR: A design where 100% of outputs are vulnerable even if the > implementation is perfect. > > These aren't the same thing at all, nor do they provide the same security= . > > > No, I=E2=80=99m comparing a realistic deployment of P2MR for the wallets = which are > relevant to the =E2=80=9Cwe should give them maximum time to migrate=E2= =80=9D discussion in > a world where they use P2MR to a world without. Yes, there are wallets th= at > would use P2MR =E2=80=9Cright=E2=80=9D, but those wallets literally do no= t matter for a > discussion around what we need to get in place as soon as possible - larg= e > custodians who won=E2=80=99t make any mistakes with their cold storage ar= e just as > capable of making no mistakes later as they are today. > > For the actual wallets that we want to get migrating as soon as possible > we=E2=80=99re talking about things that aren=E2=80=99t going to pay a 10x= cost increase and > are going to continue using a single static address. > > Matt > > On Wed, Apr 15, 2026, 07:02 Matt Corallo wrote= : > >> Oh, apologies, I was in a bit of a rush yesterday and forgot the most >> important reason why P2MR >> doesn't help at all - address reuse. >> >> In practice the "long tail" of Bitcoin wallets (which, as noted below ar= e >> most of what we care >> about) do strict address reuse. Mostly a consequence of address-based >> blockchain systems its become >> an expected feature that the address displayed in a wallet is static and >> does not change. As such, >> P2MR with a EC-based key for short-term efficiency reasons has the same >> quantum security as P2TR or >> P2TRv2. >> >> Matt >> >> On 4/14/26 4:04 PM, Matt Corallo wrote: >> > I'm gonna top-post because I think we're too far in the weeds and the >> high-level argument is getting >> > lost. No, of course I do not thing that our job is to "convince" any >> quantum skeptics. What is our >> > job is making sure the *bitcoin system* is ready in case a CRQC does >> become a reality. That means >> > looking at the system as a whole, not individuals. Notably, this means >> that if the decisions we make >> > result in a bitcoin where some people who are super worried about a >> CRQC have migrated but everyone >> > else hasn't, and a CRQC becomes an imminent reality, *we've failed*. I= n >> such a world, bitcoin >> > becomes largely value-less and the paranoid folks who migrated long ag= o >> and paid for it have >> > accomplished absolutely nothing. I hope we can at least agree on this >> point. >> > >> > On 4/14/26 2:56 PM, conduition wrote: >> >> Hi Matt, >> >> >> >>> Right but you didn't contend with my point at all, only ignored it. >> Its great that you can move >> >>> your coins into something so that your coins aren't stolen but...who >> cares? If a huge % of >> >>> outstanding bitcoin supply is being stolen that impacts you just as >> much as if your own coins >> >>> were being stolen! >> >> >> >> I don't think I ignored anything, but maybe I just didn't understand >> your point. >> >> >> >> To me, your point seems to be (I'm summarizing here) that "Nobody wil= l >> migrate to P2MR before Q- >> >> day because it is slightly worse than P2TR until Q-day". And your >> conclusion is, in your own words: >> >> >> >>> Thus, ISTM the focus *has* to be on something that has minimal >> drawbacks - not losing the script >> >>> policy privacy of P2TR, low or no fee overhead, etc. >> >> >> >> This seems to imply you're arguing that at least some of those same >> people (who wouldn't use P2MR) >> >> WOULD migrate to P2TRv2, because it is exactly as good as P2TR until >> Q-Day. >> > >> > Yes, exactly. >> > >> >> I respectfully disagree with this argument, and I gave my reasoning a= s >> to why in my last reply. To >> >> review: >> >> >> >> - P2MR is quantum-secure by default. >> >> - P2MR is more efficient long-term. >> > >> > This assumes a CRQC. >> > >> >> - P2MR does not commit us to carrying legacy crypto cruft past its >> shelf-life. >> > >> > Nor does P2TRv2? No one is suggesting P2TRv2 becomes some standard tha= t >> all wallets use forever. No >> > matter what we do we carry the "cruft" of P2TR in Bitcoin forever >> (+/-), P2TRv2 has literally zero >> > additional cruft. >> > >> >> - P2MR and P2TRv2 are both equivalent to quantum-skeptics, who have n= o >> incentive to migrate either >> >> way. >> > >> > See below >> > >> >> - The short-term efficiency difference in P2MR and P2TRv2 is a >> negligible trade-off to anyone who >> >> ISN'T a total quantum-skeptic. >> >> - Fee-sensitive users are online and adaptive, and can use P2TR until >> Q-day; They do not need >> >> P2TRv2 any more than fee-insensitive users. >> > >> > I disagree very strongly with this. This would be true if everyone had >> their own custom-built wallet >> > that they designed to meet their goals exactly. In the real world >> people pick wallets based on many >> > other factors, and developers build wallets for many different users, >> some of which may be fee >> > sensitive and some of which may not be, all of whom will use the same >> default configuration. >> > >> >> - P2MR has utility even if Q-day never comes. >> > >> > I disagree. The overall utility to the Bitcoin system of something lik= e >> P2TR is also the global >> > default that is strongly baked in which results in >> > >> >> - Also, I failed to make this point in my last reply: P2MR and P2TRv2 >> have the same privacy >> >> profile AFAICT, assuming both commit to a hash-based fallback leaf >> script. >> > >> > I don't see how this is true in practice. Maybe in a world where >> everyone uses P2MR with a single >> > left-hand leaf at depth one with a single EC schnorr key which is >> musig2, but....come on. The value >> > of taproot is that its design natively adds this *for free* to every >> contracting protocol, and not >> > only adds it for free but *forces* every contracting protocol to carry >> at least some of the cost if >> > they decline to do this. This results in a massive net privacy win >> across the entire Bitcoin >> > ecosystem, and I don't see how you can argue that these things are >> equivalent in practice, just >> > because they could in theory be used in a way where they are in theory= . >> > >> >> Therefore, P2MR is the better long-term choice. >> >> >> >> If we assume Bitcoin will survive long into the future after CRQCs >> appear, then we should favor >> >> the best long-term design choices over short-term compromises. Thus, >> we should deploy P2MR and NOT >> >> deploy P2TRv2. >> > >> > Not only do I disagree with most of your points here, but I disagree >> that we should be optimizing >> > for a "long-term design" which we intend to be *the* design we use in >> the face of an imminent CRQC. >> > We already know we're not doing that - we're not using lattices or >> isogenies or whatever we'll >> > actually end up using because those things aren't ready. They likely >> will be by the time a CQRC is >> > imminent. If they aren't, we'll almost certainly be back to the drawin= g >> board on witness discounts >> > and whatever else which will mandate a new address format anyway. Ther= e >> is basically zero chance >> > that whatever we do today will be what we end up using "normally" in a >> world with a CRQC. >> > >> >>> But what about someone who sees quantum computers as 90% FUD that >> might happen eventually but >> >>> won't for 50 years but still gets users nagging them about it and >> support for importing some new >> >>> seedphrase format that derives a SHRINCS key in addition to the EC >> ones? That's much less of a >> >>> straw man and way more realistic - and also a place where someone >> might do the work (or, well, >> >>> merge a PR if its done for them) but probably won't if they're >> building a consumer wallet that is >> >>> used by some to transact regularly (but, let's face it, used >> primarily by some people who put >> >>> some money in and then forgot about it for five years). >> >> >> >> Very specific. You're talking about wallet developers here, right? >> Exchanges? Bitcoin businesses >> >> in general etc? And you're saying that the people running these >> businesses and building the >> >> wallets - those who are being "nagged" to implement something that th= e >> rest of the cryptographic >> >> world has already starting rolling out in production [1] - You're >> saying that a subclass of these >> >> people - those who are "mostly" skeptical of quantum hype - WOULD >> implement P2TRv2, but WOULDN'T >> >> implement P2MR? >> >> >> >> It's debatable how big that subclass would be, especially given the >> current landscape. >> > >> > I don't think this is "very specific" at all? In fact I think this is >> the *dominant* case. By coin >> > volume, yes, the biggest wallet is Coinbase's custody product. By >> wallet count, the biggest wallet >> > is probably something like Trust Wallet. Its trash, doesn't care about >> Bitcoin, makes many terrible >> > design decisions which are actively hostile to its users, and yet they >> are the ones who actually >> > decide in what way most bitcoin are stored! I don't know what their >> particular view on quantum is, >> > but my sense of most developers is that the view is generally "well, >> it'll happen at some point, but >> > its not totally urgent". Meanwhile, people are almost without question >> going to nag some wallets for >> > "quantum security" once its a thing. >> > >> > You might reasonably disagree with whether they would implement P2TRv2 >> vs P2MR, I think its >> > definitely a subtle argument, but I don't think you can reasonably >> disagree that these are exactly >> > the most important constituent here. >> > >> > > But even if one confidently sees CRQCs as 50 years away, then I'd >> refer back to my earlier >> > response, and argue that any such skeptical developer has no reason to >> implement either P2MR or >> > P2TRv2 today, apart from compatibility with other software which DOES >> implement them. If "nagging" >> > is the only motivation a dev or business owner has to implement a PQ >> output type, then one need not >> > distinguish between the two. They'd just implement whatever is >> standardized to please their users, >> > and carry on with their day.> >> >> If I'm being a little more realistic, most wallet devs will follow >> whatever is standardized just >> >> to get more market share. I somehow doubt devs will turn up their >> noses and say "it's not >> >> efficient enough, I won't implement that even if a large chunk of my >> customers are clamoring for it." >> >> >> >> I think this reveals the source of our disagreement. In your >> arguments, you are placing a lot of >> >> weight on the importance of pre-quantum fee-efficiency in the new >> output type, so much so that you >> >> seem to think devs would willingly ignore a potential existential >> threat to save users a few sats >> >> per transaction. >> > >> > It is far from only "pre-quantum fee-effeciency", its also the value >> for the entire Bitcoin system >> > of the privacy taproot offers. But I think the more important argument >> specifically here is the >> > question of what they will make the *default*. In a world with P2MR I >> could absolutely see them >> > implementing a P2MR option which you can opt into in the settings. Tha= t >> fails to accomplish our >> > goals entirely. Maybe they also would do the same for P2TR/P2TRv2, but >> I at least think that's >> > somewhat less likely, but in any case better for the bitcoin system >> overall if that's where we land. >> > >> >> But maybe look at it this way: >> >> >> >> - Whether quantum computers are 5, 10, 50 years or more away, anyone >> who truly cares about a few >> >> extra sats per TX can continue to use P2TR when actively transacting >> pre-Q-Day, and use P2MR for >> >> high-security cold storage. The result is mostly the same as if we >> deployed P2TRv2. Yes, there is >> >> some risk of being caught with your pants down on Q-day, but the same >> is true of P2TRv2 because we >> >> might not time the key-spend disabling follow-up fork correctly. >> >> - Mining fees are a part of everyday life for Bitcoiners, and the >> pre-quantum fee difference >> >> between P2TR and P2MR is NOTHING compared to the fee spike we'll all >> have to endure after Q-day, >> >> no matter what fancy cryptography we may end up using by then. There >> are far more important things >> >> we can optimize. >> >> >> >>> Again, you ignore that the impact is global, not local. Yes, >> quantum-skeptics have to be brought >> >>> along over time if you want to have any hope of bitcoin actually >> being relevant. >> >> >> >> Our job is not to proselytize and convince people that the quantum >> threat is real, nor is it even >> >> to encourage migration by design. Our job is to prepare an optimal >> migration path in case the >> >> threat is real. If CRQCs do appear, everyone will want to migrate to >> PQC sooner or later. If they >> >> do not, everyone moves on with their lives and the new output type >> becomes a relic (in P2MR's >> >> case, an occasionally useful one). >> >> >> >> Even if you feel your job IS to convince and migrate as many users as >> possible, I would argue >> >> it'll be hard to convince anyone to migrate to an address format that >> isn't PQ-safe by default. >> >> Bitcoiners trust code, not promises, and P2TRv2 is only PQ-safe if yo= u >> trust its promise of a >> >> future soft fork, while its code would be PQ-vulnerable by default. >> And the only benefit to >> >> accepting this risk seems to be a trivial discount in fees pre-Q-day. >> I don't speak for everyone >> >> of course, but personally I'd rather keep my cold-storage coins on a >> P2WSH address than on P2TRv2, >> >> because at least then I know for sure a CRQC will have a hard time >> stealing my coins regardless of >> >> what upgrades the community does or doesn't deploy in the future. >> > >> > See intro. I don't really see how you can reasonably conclude that our >> goal is only to enable a >> > small subset of people to migrate. That way leas only to a total >> failure of the bitcoin system. >> > >> >>> Sure, but any short term hash-based signature migration path is >> really not intended as the final >> >>> state anyway - if Bitcoin is stuck with only hash based signatures >> and a CRQC exists in 20 years >> >>> that's a pretty terrible outcome. Hopefully by the time a CRQC >> becomes a real threat we have much >> >>> more confidence in lattice-based systems (or whatever PQC is popular >> then) and we can add >> >>> whatever output type makes sense at that point. >> >> >> >> I agree about hash-based sigs not being the endgame. Though, this >> doesn't mean P2MR isn't. We're >> >> talking about output types here, not opcodes. I would argue P2MR >> remains useful regardless of the >> >> cryptography we use: lattice, isogeny, hash-based, multivariate, >> whatever. Merkle trees have been >> >> around for almost 50 years and seem hard to beat. >> >> >> >> For instance, we could reconstruct P2TR using isogenies [2], but woul= d >> we really want to? Using >> >> today's witness discount levels, it would actually be MORE efficient >> overall to spend with SQIsign >> >> inside a P2MR tree, than it would be to use SQIsign to key-spend with >> some hypothetical "Pay-to- >> >> supersingular-curve" output type [^3]. I realize I'm kinda trashing m= y >> own research by saying >> >> this, but it shows how hard it is to beat P2MR, even if you can accep= t >> new cryptographic >> >> assumptions and the accompanying performance penalties. >> > >> > Yes, we probably would. Not because of efficiency but because a goal o= f >> taproot is *privacy* while >> > offering efficiency for the common (all-sign) case. That is generally >> true across contracting >> > protocols and makes things net-cheaper with a taproot-style system >> where you hit the common case >> > often. This is another reason why P2MR is quite a loss - >> > >> >> Even if we do someday find some novel cryptosystem which permits >> rerandomization, and we design a >> >> new output type as efficient and performant as P2TR but in a >> post-quantum context, is the systemic >> >> risk really worth saving a few vbytes - a small fraction of the entir= e >> witness? If so, how many >> >> decades or centuries need to pass for everyone else to share that >> confidence? >> >> >> >> Personally I think we should learn our lesson from this P2TR debacle, >> and encourage users to hide >> >> public keys behind hash functions from now on, and to bolster riskier >> algorithms with hash-based >> >> fallback keys, so that we always have at least one layer of protectio= n >> between keys and any novel >> >> cryptanalytic breakthroughs. Posting our plain pubkeys on-chain does >> sometimes have fun benefits, >> >> but the drawbacks are deadly serious. >> >> >> >> Until SHA256 collision resistance is broken, I'd expect P2MR is >> probably the pinnacle of secure PQ >> >> address formats, and even then we'd probably end up reimplementing >> P2MR with some newer hash >> >> function. Hopefully someday someone proves me wrong, but we can only >> engineer with what we know >> >> today, and today P2MR seems the most optimal conservative option for >> long-term security and >> >> cryptographic agility. >> > >> > As mentioned above if we end up in this situation we're almost >> certainly going to be discussing a >> > P2MRv2 with an additional witness discount, so... >> > >> >>> And with them they will take bitcoin's value... >> >> >> >> If you're really worried about a supply glut caused by CRQCs stealing >> and dumping them, then >> >> debating about P2TRv2 and P2MR is a distraction. IMO, most coins will >> probably not migrate before >> >> Q-Day regardless of what output types we deploy, because many coins >> are held by dead hands, or by >> >> living hands who just don't read the news. >> >> >> >> If this concerns you (and it concerns me too), then saving a few >> vbytes per spend pre-Q-day is >> >> trivial by comparison, and optimizing it will make little impact on >> the integrity of the UTXO set >> >> after Q-day. I would instead suggest you pursue the retroactive area >> of research (rescue >> >> protocols, quantum canaries, hourglass, exposure statistics, etc). >> This is a domain where real >> >> impact can be made to mitigate the risk of a supply glut when/if CRQC= s >> appear. Opportunities >> >> abound. We would be glad of the help :) >> > >> > This is fair, and we should do this too, but I don't see how it implie= s >> we should not also be >> > concerned with ensuring maximum possible migration. >> > >> > >> >> Anyways, I appreciate the good-spirited debate, but to save myself >> time I don't think I'll >> >> continue replying. I've laid out my argument for P2MR pretty clearly >> and I feel it is as >> >> convincing as I can make it. I'd be happy to acknowledge any >> misunderstanding I may have had about >> >> your earlier points in favor of P2TRv2. >> > >> > Fair enough. I continue to think we're talking past each other somewha= t >> but ultimately I think my >> > concern is for ensuring bitcoin survives, while you're more concerned >> with giving those who are >> > concerned an option to feel warm and fuzzy :). >> > >> >> As to the original subject of the email thread, and Antoine's origina= l >> points, seems like we are >> >> all in agreement. >> > Indeed. >> > >> >> --=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/= CAEM%3Dy%2BXLb6cRGqtY9dao-N9-a03Ya4PyCm0BM9ciqhNuyUpUAQ%40mail.gmail.com. --0000000000000871f3064f81d483 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe we are talking about exactly the same thin= g. A P2MR output that can be spent with a EC leaf or a PQ leaf. Is that not= what you mean?

On Wed,= Apr 15, 2026, 11:17 Matt Corallo <lf-lists@mattcorallo.com> wrote:
<= div dir=3D"ltr">

On= Apr 15, 2026, at 10:36, Ethan Heilman <eth3rs@gmail.com> wrote:
=EF=BB= =BF
The proposal is P2MR with PQ sigs and no Schnorr = address reuse. Address reuse in this setting should be treated as security = vulnerability.

The contex= t was a discussion of using P2MR with a EX fallback =E2=80=9Cuntil it=E2=80= =99s time=E2=80=9D. This avoids the substantial fee and functionality-loss = overhead of hash-based signatures =E2=80=9Cuntil it=E2=80=99s time=E2=80=9D= .

Yes, of course people could opt to not do that, = but then we=E2=80=99re back to where we started - not solving a useful prob= lem for those who the problem actually impacts.

> As such= , P2MR with a EC-based key for short-term efficiency reasons has the same q= uantum security as P2TR or P2TRv2.

This is incorrect.=C2=A0

1. As long as the Schnorr pubkey has not been leaked by the wal= let. The wallet is PQ safe.

Right, the context is a =E2=80=9Cnormal=E2=80=9D wallet which transacts = occasionally. A pure receive-only wallet is fine but that=E2=80=99s such a = narrow use-case I=E2=80=99m not even sure it=E2=80=99s worth discussing?
2. Even if the Schnorr pubkey has been leaked by the wallet, if = the PQ leaf hash is not publicly known it is safe against long exposure att= acks.=C2=A0

Huh? If the a= ddress is reused as-is (as is the case the most popular Bitcoin wallets tod= ay) a CRQC can trivially steal the funds with the EC key. What am I missing= ?

P2TR is **always** vulnerable to short and long exposure att= acks. There is no better wallet hygiene that can fix this.

You are comparing:=C2=A0

P2MR + PQ signatures:=C2=A0 A wallet = messing up their implementation of PQ safe transactions and introducing a v= ulnerability and weakening a subset of outputs. If implemented correctly 10= 0% of the outputs are safe.

vs.=C2=A0

P2TR: A de= sign where 100% of outputs are vulnerable even if the implementation is per= fect.

These aren't t= he same thing at all, nor do they provide the same security.=C2=A0

No, I=E2=80=99m comparing a reali= stic deployment of P2MR for the wallets which are relevant to the =E2=80=9C= we should give them maximum time to migrate=E2=80=9D discussion in a world = where they use P2MR to a world without. Yes, there are wallets that would u= se P2MR =E2=80=9Cright=E2=80=9D, but those wallets literally do not matter = for a discussion around what we need to get in place as soon as possible - = large custodians who won=E2=80=99t make any mistakes with their cold storag= e are just as capable of making no mistakes later as they are today.
<= div>
For the actual wallets that we want to get migrating as = soon as possible we=E2=80=99re talking about things that aren=E2=80=99t goi= ng to pay a 10x cost increase and are going to continue using a single stat= ic address.

Matt

On Wed, Apr 15, 2= 026, 07:02 Matt Corallo <lf-lists@mattcorallo.com> wrote:
Oh, apologies, I = was in a bit of a rush yesterday and forgot the most important reason why P= 2MR
doesn't help at all - address reuse.

In practice the "long tail" of Bitcoin wallets (which, as noted b= elow are most of what we care
about) do strict address reuse. Mostly a consequence of address-based block= chain systems its become
an expected feature that the address displayed in a wallet is static and do= es not change. As such,
P2MR with a EC-based key for short-term efficiency reasons has the same qua= ntum security as P2TR or
P2TRv2.

Matt

On 4/14/26 4:04 PM, Matt Corallo wrote:
> I'm gonna top-post because I think we're too far in the weeds = and the high-level argument is getting
> lost. No, of course I do not thing that our job is to "convince&q= uot; any quantum skeptics. What is our
> job is making sure the *bitcoin system* is ready in case a CRQC does b= ecome a reality. That means
> looking at the system as a whole, not individuals. Notably, this means= that if the decisions we make
> result in a bitcoin where some people who are super worried about a CR= QC have migrated but everyone
> else hasn't, and a CRQC becomes an imminent reality, *we've fa= iled*. In such a world, bitcoin
> becomes largely value-less and the paranoid folks who migrated long ag= o and paid for it have
> accomplished absolutely nothing. I hope we can at least agree on this = point.
>
> On 4/14/26 2:56 PM, conduition wrote:
>> Hi Matt,
>>
>>> Right but you didn't contend with my point at all, only ig= nored it. Its great that you can move
>>> your coins into something so that your coins aren't stolen= but...who cares? If a huge % of
>>> outstanding bitcoin supply is being stolen that impacts you ju= st as much as if your own coins
>>> were being stolen!
>>
>> I don't think I ignored anything, but maybe I just didn't = understand your point.
>>
>> To me, your point seems to be (I'm summarizing here) that &quo= t;Nobody will migrate to P2MR before Q-
>> day because it is slightly worse than P2TR until Q-day". And = your conclusion is, in your own words:
>>
>>> Thus, ISTM the focus *has* to be on something that has minimal= drawbacks - not losing the script
>>> policy privacy of P2TR, low or no fee overhead, etc.
>>
>> This seems to imply you're arguing that at least some of those= same people (who wouldn't use P2MR)
>> WOULD migrate to P2TRv2, because it is exactly as good as P2TR unt= il Q-Day.
>
> Yes, exactly.
>
>> I respectfully disagree with this argument, and I gave my reasonin= g as to why in my last reply. To
>> review:
>>
>> - P2MR is quantum-secure by default.
>> - P2MR is more efficient long-term.
>
> This assumes a CRQC.
>
>> - P2MR does not commit us to carrying legacy crypto cruft past its= shelf-life.
>
> Nor does P2TRv2? No one is suggesting P2TRv2 becomes some standard tha= t all wallets use forever. No
> matter what we do we carry the "cruft" of P2TR in Bitcoin fo= rever (+/-), P2TRv2 has literally zero
> additional cruft.
>
>> - P2MR and P2TRv2 are both equivalent to quantum-skeptics, who hav= e no incentive to migrate either
>> way.
>
> See below
>
>> - The short-term efficiency difference in P2MR and P2TRv2 is a neg= ligible trade-off to anyone who
>> ISN'T a total quantum-skeptic.
>> - Fee-sensitive users are online and adaptive, and can use P2TR un= til Q-day; They do not need
>> P2TRv2 any more than fee-insensitive users.
>
> I disagree very strongly with this. This would be true if everyone had= their own custom-built wallet
> that they designed to meet their goals exactly. In the real world peop= le pick wallets based on many
> other factors, and developers build wallets for many different users, = some of which may be fee
> sensitive and some of which may not be, all of whom will use the same = default configuration.
>
>> - P2MR has utility even if Q-day never comes.
>
> I disagree. The overall utility to the Bitcoin system of something lik= e P2TR is also the global
> default that is strongly baked in which results in
>
>> - Also, I failed to make this point in my last reply: P2MR and P2T= Rv2 have the same privacy
>> profile AFAICT, assuming both commit to a hash-based fallback leaf= script.
>
> I don't see how this is true in practice. Maybe in a world where e= veryone uses P2MR with a single
> left-hand leaf at depth one with a single EC schnorr key which is musi= g2, but....come on. The value
> of taproot is that its design natively adds this *for free* to every c= ontracting protocol, and not
> only adds it for free but *forces* every contracting protocol to carry= at least some of the cost if
> they decline to do this. This results in a massive net privacy win acr= oss the entire Bitcoin
> ecosystem, and I don't see how you can argue that these things are= equivalent in practice, just
> because they could in theory be used in a way where they are in theory= .
>
>> Therefore, P2MR is the better long-term choice.
>>
>> If we assume Bitcoin will survive long into the future after CRQCs= appear, then we should favor
>> the best long-term design choices over short-term compromises. Thu= s, we should deploy P2MR and NOT
>> deploy P2TRv2.
>
> Not only do I disagree with most of your points here, but I disagree t= hat we should be optimizing
> for a "long-term design" which we intend to be *the* design = we use in the face of an imminent CRQC.
> We already know we're not doing that - we're not using lattice= s or isogenies or whatever we'll
> actually end up using because those things aren't ready. They like= ly will be by the time a CQRC is
> imminent. If they aren't, we'll almost certainly be back to th= e drawing board on witness discounts
> and whatever else which will mandate a new address format anyway. Ther= e is basically zero chance
> that whatever we do today will be what we end up using "normally&= quot; in a world with a CRQC.
>
>>> But what about someone who sees quantum computers as 90% FUD t= hat might happen eventually but
>>> won't for 50 years but still gets users nagging them about= it and support for importing some new
>>> seedphrase format that derives a SHRINCS key in addition to th= e EC ones? That's much less of a
>>> straw man and way more realistic - and also a place where some= one might do the work (or, well,
>>> merge a PR if its done for them) but probably won't if the= y're building a consumer wallet that is
>>> used by some to transact regularly (but, let's face it, us= ed primarily by some people who put
>>> some money in and then forgot about it for five years).
>>
>> Very specific. You're talking about wallet developers here, ri= ght? Exchanges? Bitcoin businesses
>> in general etc? And you're saying that the people running thes= e businesses and building the
>> wallets - those who are being "nagged" to implement some= thing that the rest of the cryptographic
>> world has already starting rolling out in production [1] - You'= ;re saying that a subclass of these
>> people - those who are "mostly" skeptical of quantum hyp= e - WOULD implement P2TRv2, but WOULDN'T
>> implement P2MR?
>>
>> It's debatable how big that subclass would be, especially give= n the current landscape.
>
> I don't think this is "very specific" at all? In fact I = think this is the *dominant* case. By coin
> volume, yes, the biggest wallet is Coinbase's custody product. By = wallet count, the biggest wallet
> is probably something like Trust Wallet. Its trash, doesn't care a= bout Bitcoin, makes many terrible
> design decisions which are actively hostile to its users, and yet they= are the ones who actually
> decide in what way most bitcoin are stored! I don't know what thei= r particular view on quantum is,
> but my sense of most developers is that the view is generally "we= ll, it'll happen at some point, but
> its not totally urgent". Meanwhile, people are almost without que= stion going to nag some wallets for
> "quantum security" once its a thing.
>
> You might reasonably disagree with whether they would implement P2TRv2= vs P2MR, I think its
> definitely a subtle argument, but I don't think you can reasonably= disagree that these are exactly
> the most important constituent here.
>
>=C2=A0 > But even if one confidently sees CRQCs as 50 years away, th= en I'd refer back to my earlier
> response, and argue that any such skeptical developer has no reason to= implement either P2MR or
> P2TRv2 today, apart from compatibility with other software which DOES = implement them. If "nagging"
> is the only motivation a dev or business owner has to implement a PQ o= utput type, then one need not
> distinguish between the two. They'd just implement whatever is sta= ndardized to please their users,
> and carry on with their day.>
>> If I'm being a little more realistic, most wallet devs will fo= llow whatever is standardized just
>> to get more market share. I somehow doubt devs will turn up their = noses and say "it's not
>> efficient enough, I won't implement that even if a large chunk= of my customers are clamoring for it."
>>
>> I think this reveals the source of our disagreement. In your argum= ents, you are placing a lot of
>> weight on the importance of pre-quantum fee-efficiency in the new = output type, so much so that you
>> seem to think devs would willingly ignore a potential existential = threat to save users a few sats
>> per transaction.
>
> It is far from only "pre-quantum fee-effeciency", its also t= he value for the entire Bitcoin system
> of the privacy taproot offers. But I think the more important argument= specifically here is the
> question of what they will make the *default*. In a world with P2MR I = could absolutely see them
> implementing a P2MR option which you can opt into in the settings. Tha= t fails to accomplish our
> goals entirely. Maybe they also would do the same for P2TR/P2TRv2, but= I at least think that's
> somewhat less likely, but in any case better for the bitcoin system ov= erall if that's where we land.
>
>> But maybe look at it this way:
>>
>> - Whether quantum computers are 5, 10, 50 years or more away, anyo= ne who truly cares about a few
>> extra sats per TX can continue to use P2TR when actively transacti= ng pre-Q-Day, and use P2MR for
>> high-security cold storage. The result is mostly the same as if we= deployed P2TRv2. Yes, there is
>> some risk of being caught with your pants down on Q-day, but the s= ame is true of P2TRv2 because we
>> might not time the key-spend disabling follow-up fork correctly. >> - Mining fees are a part of everyday life for Bitcoiners, and the = pre-quantum fee difference
>> between P2TR and P2MR is NOTHING compared to the fee spike we'= ll all have to endure after Q-day,
>> no matter what fancy cryptography we may end up using by then. The= re are far more important things
>> we can optimize.
>>
>>> Again, you ignore that the impact is global, not local. Yes, q= uantum-skeptics have to be brought
>>> along over time if you want to have any hope of bitcoin actual= ly being relevant.
>>
>> Our job is not to proselytize and convince people that the quantum= threat is real, nor is it even
>> to encourage migration by design. Our job is to prepare an optimal= migration path in case the
>> threat is real. If CRQCs do appear, everyone will want to migrate = to PQC sooner or later. If they
>> do not, everyone moves on with their lives and the new output type= becomes a relic (in P2MR's
>> case, an occasionally useful one).
>>
>> Even if you feel your job IS to convince and migrate as many users= as possible, I would argue
>> it'll be hard to convince anyone to migrate to an address form= at that isn't PQ-safe by default.
>> Bitcoiners trust code, not promises, and P2TRv2 is only PQ-safe if= you trust its promise of a
>> future soft fork, while its code would be PQ-vulnerable by default= . And the only benefit to
>> accepting this risk seems to be a trivial discount in fees pre-Q-d= ay. I don't speak for everyone
>> of course, but personally I'd rather keep my cold-storage coin= s on a P2WSH address than on P2TRv2,
>> because at least then I know for sure a CRQC will have a hard time= stealing my coins regardless of
>> what upgrades the community does or doesn't deploy in the futu= re.
>
> See intro. I don't really see how you can reasonably conclude that= our goal is only to enable a
> small subset of people to migrate. That way leas only to a total failu= re of the bitcoin system.
>
>>> Sure, but any short term hash-based signature migration path i= s really not intended as the final
>>> state anyway - if Bitcoin is stuck with only hash based signat= ures and a CRQC exists in 20 years
>>> that's a pretty terrible outcome. Hopefully by the time a = CRQC becomes a real threat we have much
>>> more confidence in lattice-based systems (or whatever PQC is p= opular then) and we can add
>>> whatever output type makes sense at that point.
>>
>> I agree about hash-based sigs not being the endgame. Though, this = doesn't mean P2MR isn't. We're
>> talking about output types here, not opcodes. I would argue P2MR r= emains useful regardless of the
>> cryptography we use: lattice, isogeny, hash-based, multivariate, w= hatever. Merkle trees have been
>> around for almost 50 years and seem hard to beat.
>>
>> For instance, we could reconstruct P2TR using isogenies [2], but w= ould we really want to? Using
>> today's witness discount levels, it would actually be MORE eff= icient overall to spend with SQIsign
>> inside a P2MR tree, than it would be to use SQIsign to key-spend w= ith some hypothetical "Pay-to-
>> supersingular-curve" output type [^3]. I realize I'm kind= a trashing my own research by saying
>> this, but it shows how hard it is to beat P2MR, even if you can ac= cept new cryptographic
>> assumptions and the accompanying performance penalties.
>
> Yes, we probably would. Not because of efficiency but because a goal o= f taproot is *privacy* while
> offering efficiency for the common (all-sign) case. That is generally = true across contracting
> protocols and makes things net-cheaper with a taproot-style system whe= re you hit the common case
> often. This is another reason why P2MR is quite a loss -
>
>> Even if we do someday find some novel cryptosystem which permits r= erandomization, and we design a
>> new output type as efficient and performant as P2TR but in a post-= quantum context, is the systemic
>> risk really worth saving a few vbytes - a small fraction of the en= tire witness? If so, how many
>> decades or centuries need to pass for everyone else to share that = confidence?
>>
>> Personally I think we should learn our lesson from this P2TR debac= le, and encourage users to hide
>> public keys behind hash functions from now on, and to bolster risk= ier algorithms with hash-based
>> fallback keys, so that we always have at least one layer of protec= tion between keys and any novel
>> cryptanalytic breakthroughs. Posting our plain pubkeys on-chain do= es sometimes have fun benefits,
>> but the drawbacks are deadly serious.
>>
>> Until SHA256 collision resistance is broken, I'd expect P2MR i= s probably the pinnacle of secure PQ
>> address formats, and even then we'd probably end up reimplemen= ting P2MR with some newer hash
>> function. Hopefully someday someone proves me wrong, but we can on= ly engineer with what we know
>> today, and today P2MR seems the most optimal conservative option f= or long-term security and
>> cryptographic agility.
>
> As mentioned above if we end up in this situation we're almost cer= tainly going to be discussing a
> P2MRv2 with an additional witness discount, so...
>
>>> And with them they will take bitcoin's value...
>>
>> If you're really worried about a supply glut caused by CRQCs s= tealing and dumping them, then
>> debating about P2TRv2 and P2MR is a distraction. IMO, most coins w= ill probably not migrate before
>> Q-Day regardless of what output types we deploy, because many coin= s are held by dead hands, or by
>> living hands who just don't read the news.
>>
>> If this concerns you (and it concerns me too), then saving a few v= bytes per spend pre-Q-day is
>> trivial by comparison, and optimizing it will make little impact o= n the integrity of the UTXO set
>> after Q-day. I would instead suggest you pursue the retroactive ar= ea of research (rescue
>> protocols, quantum canaries, hourglass, exposure statistics, etc).= This is a domain where real
>> impact can be made to mitigate the risk of a supply glut when/if C= RQCs appear. Opportunities
>> abound. We would be glad of the help :)
>
> This is fair, and we should do this too, but I don't see how it im= plies we should not also be
> concerned with ensuring maximum possible migration.
>
>
>> Anyways, I appreciate the good-spirited debate, but to save myself= time I don't think I'll
>> continue replying. I've laid out my argument for P2MR pretty c= learly and I feel it is as
>> convincing as I can make it. I'd be happy to acknowledge any m= isunderstanding I may have had about
>> your earlier points in favor of P2TRv2.
>
> Fair enough. I continue to think we're talking past each other som= ewhat but ultimately I think my
> concern is for ensuring bitcoin survives, while you're more concer= ned with giving those who are
> concerned an option to feel warm and fuzzy :).
>
>> As to the original subject of the email thread, and Antoine's = original points, seems like we are
>> all in agreement.
> Indeed.
>

--
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/CAEM%3Dy%2BXLb6cRGqtY9dao-N9-a03Ya4PyCm0BM9ciqhNuyUpUAQ%= 40mail.gmail.com.
--0000000000000871f3064f81d483--