From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Apr 2026 09:30:31 -0700 Received: from mail-oo1-f55.google.com ([209.85.161.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wD38G-00083J-AU for bitcoindev@gnusha.org; Wed, 15 Apr 2026 09:30:31 -0700 Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-68a678f44adsf14136998eaf.0 for ; Wed, 15 Apr 2026 09:30:27 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1776270621; cv=pass; d=google.com; s=arc-20240605; b=YRYK36rPRzTfljKRpZuoljwe10XWbwxr5fv+QIDXYWjJSBVD6VJdMiRzHLRPq6ROXH iRPTnBIxfwbvy972H1MwaSFxABkbQQmtJ3aI67kE3oo8mvpWmF3yw22tvbSIaT9/ugCD nqRnh9qB7y6Wo+t0G5FDSBpdCDx7WjGiGkX/OzZpsb0QEOfXYHagmJrJC/8pl8Q1oHl3 ftjaHI8tGd5ZsP5SL3ZDg4Ovbmk/XHZSEPxICNFNlFdDkOVlnCD2/z7jyr10Alvu/DXS KntDQnncezpGHzIN+demQMvhCSVSMB49H2KLNHL27HowDqWAsFZSVzqt0ioU8RQNkv+O 4Jew== 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=lLWjsN4Lsuz9frPbKe1U0gSda1niV6g8T/x9xALTR3w=; fh=ZYtH2CtAPzN0eXjaDzpgkYAtKClT3sT3M7DzsDPBCPo=; b=ATb9A55Z0YKbcE0x6c4Vnnrv1Kw3UP6QQSHrzRxVKfFV7PhB37YLlIN9Msdk3o2QPD sb8jQP2dxMcYIiHEobpgf4TLTMV+YTtDPbLjIivd9X+N2qmp1oU/eAe/4odSFTegibtC FeSZVP/EEj4GnB5sDKNvvMDedHl2kVDhnBo/0RKvbAwpuB4QL+Oh4iTGWXeVY005J+9c 6ASVHte10JB/Epql/tKUh3wb4WXMGRdVJNyd/jbDAjIFvvW2odgM/DTiK7kvDkpYwrjn caioc5tQZ1sFp6q6b46goYJ+avpn0FlKS7FEnxENO0mCPWTv8zSRsrrBxX69TsHF2+rw nZDQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b="ky/KQ+LT"; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::529 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=1776270621; x=1776875421; 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=lLWjsN4Lsuz9frPbKe1U0gSda1niV6g8T/x9xALTR3w=; b=CVAcqkCdt8mQDF2DDx5zTV09vSVBdlC8zVRhKtKKBX3hfQYXQaZDj0+wkKn/rwV12A akpi5aWwehiRBuT+aAGmK4gJuWI7Jv9v7JZegJcNzsQq9W/itdsAKGSj7BWd4eqpVuIH DbsFPuA3nRgtCLftJ6BvpsjkTOZrvPNm7nS7FlE/nyqvNc5c3DY6FA+5f9GfNmRAwcF2 vNM8AJayWYABthVy845DOyC5A6xsh5yzzD3DBqKXlMk8SDsL2XbUFh0lhWukNvBLYcPt +F4uGDRmZ3iT3E4O6e5oWf3m/jB8r1R+0rNnW1gSXpA2RBtxFrNESekOfszk2RJPjV4g M98A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776270621; x=1776875421; 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=lLWjsN4Lsuz9frPbKe1U0gSda1niV6g8T/x9xALTR3w=; b=fRfT9v+68vIt2XXcz4DLDBjuLo5K9p7Qma+lgnfnyz9KEWn+SU/NmIDZ0ut3+tFmRQ ak+RmfnrsVGTdWkZLbdkRoJJ7u0+uOzM5MdCRMKiUvg8eI/cMl4sUJKttWaWBAWKVlao 8mo4GxqhZoDkg32rITHwT7QVHaeF0gpUco3j8SDZ50TeuPakcwvmo2+w82u5msHZy+w/ Z3FfE+jJxKGEowE613gt4p1lqGUCBxr42DEts4buk2pVGdul9YCRY+ljojjuNqsrdnDP orszl8JA016k7pxTpvTB8NiLPDR5/4TpyJvX549ZRMvOVrMSCmo+M3gl9GVUuXpDUBkN G3zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776270621; x=1776875421; 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=lLWjsN4Lsuz9frPbKe1U0gSda1niV6g8T/x9xALTR3w=; b=PCQsMFzPgEmTX0t5gfZGQMmw2djSjrj8zjbL1hzSDuZ4RLwBe3FEXzbayYXAIjQDUD a7iuXY83cyiRFVQoser1nB35tYEemkRJ5XBZa3O/HjQc1y/uIt9w9+GdA2WeMPqP6VKZ 8XqrZ4ejwpHcyfw/4MS/ERyj2WFstHAjvy51WX88bce2UgDOzfceW0T7DQzH1tQp/x3L Vo2VsJBZ8zYGDkUMtEZWwA9JNqrGLwJezM1utNGDLo2EK7mDqeRIEEhUd8ZDCZdyPe8D 1zv/2OE3dJfouJRRfk61kAuBxAkSqg9CBvTJ9ElbE3ZQ5wC1keESZ6bh04gb+tJmLhKv G9ow== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ8Yome2hLeaN9mnW63ThPDOds+f7+xXhg5r2HMVLswIFa1hisAr1ra2QUpXs7m0qsP8J0rRmJ67MElz@gnusha.org X-Gm-Message-State: AOJu0YzjWVWTEWg/Dh58yakqyJLTk9xDiraz5wh+S77iu0sN3JYUhYgL Mqo4bLDY24ySLi34GOTU2aHm8wPsmydsrAbd107DFqLeuhaofynliQvw X-Received: by 2002:a05:6820:a284:10b0:67f:caa7:944c with SMTP id 006d021491bc7-68be90cd058mr8003886eaf.62.1776270621268; Wed, 15 Apr 2026 09:30:21 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiLkYYU419/FT3ZotVwxsBqTjWYduiC6oZdLYwpN8mVu3g==" Received: by 2002:a05:6871:1ce:b0:423:26a0:eb23 with SMTP id 586e51a60fabf-4280bdab016ls8413fac.0.-pod-prod-05-us; Wed, 15 Apr 2026 09:30:15 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ8qB4Fbs3HdQqMWP8CiWdxvXbxtcGGRD9TiQZN2ALuMUaB64O0L+Vqiq4A4gqXgQIxI2iMq5vYkaUmJ@googlegroups.com X-Received: by 2002:a05:6808:1382:b0:466:fb74:1ec9 with SMTP id 5614622812f47-4789ca39736mr12467734b6e.4.1776270615816; Wed, 15 Apr 2026 09:30:15 -0700 (PDT) Received: by 2002:ae9:f80e:0:b0:8d6:1bc4:a7bc with SMTP id af79cd13be357-8e4e75bc967ms85a; Wed, 15 Apr 2026 09:26:22 -0700 (PDT) X-Forwarded-Encrypted: i=3; AFNElJ822QpppXBPH8b8eGuiuA6MqOXiUBrZt6yIPojJaM21fPSy7DqWJELThrlWrxJYiB3edl6u5ARyROXm@googlegroups.com X-Received: by 2002:a05:6102:f8d:b0:609:4182:f135 with SMTP id ada2fe7eead31-609ff2d5780mr10240944137.11.1776270379324; Wed, 15 Apr 2026 09:26:19 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776270379; cv=pass; d=google.com; s=arc-20240605; b=MX1+kqsR0sZqlbHmrTmR47KeOd2UcVGoiWRWo4nAH6ijTNh/TXojTfvt2NPImk1dRn Iy+yRN80sSSi+qZ7CcajdmhREXQESl5+zLhtVStvFg4JAbV712AzAMK39GXFfs0KnItz Q10gf6Zvl7eHmiJRRxKkHYZC5tbZsOY2j/sWPpYUIPhXjUyQ0hNTy9kl8gsEqt5xnupE E0h2i9akH7v6Xqpst8i8f2ml8h294/9f1htB60CBDPfsXHbJKZgvZ3+JymNrtyMuQ9uH kdPgeroX7T6nYBqJmu88VEp9EvO0ozTZae0C7qRUGeWFmByJfNR3PYoE0U5xBKOsWhl9 rrgA== 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=IHB6WiVq2WdOmMgxLb6otpWZlVRZ6FCx0YazQVyOxE4=; fh=eMKn2xZ8okKaPd9rhcV9lV/BFuYkd2Pgumm+dgdq5Bo=; b=ccyRD7/hLXeAkwlpJPm+sygnS3C+2r7ta2e66mu/AybOVjvXK6VAZmFSWbMcpCjZlu aF8NPmKGXTveabu8YDEvViwD1pEInMw815MN1xLhE+YGs8yS3h5hwTHVucvfSDomRXlb Hz7ESzI4l/csmY2PXtkMZfg947g431ylMl1rK6zsdVRuJtxF1V7FHqZqCAlY/00rUXNb PrKNhEhaWCZQQ/aASAEpXAHeChuIqlOFVQDUs9a8icMhViFD1JdhHVqhBgKsuE9XGj7c uJPzfVAPidV9HBApXI7QdRfQGiyZcndTb3R0kVjuuHCPOkAVZ3BNwG4pFgSGtq0IQ165 amkQ==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b="ky/KQ+LT"; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::529 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-pg1-x529.google.com (mail-pg1-x529.google.com. [2607:f8b0:4864:20::529]) by gmr-mx.google.com with ESMTPS id ada2fe7eead31-612cce3cf25si82932137.1.2026.04.15.09.26.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2026 09:26:19 -0700 (PDT) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::529 as permitted sender) client-ip=2607:f8b0:4864:20::529; Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-c76b9efc299so2690873a12.0 for ; Wed, 15 Apr 2026 09:26:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776270378; cv=none; d=google.com; s=arc-20240605; b=IOJZkm6Q3CRV24JcdP+yNzPU0ISqR/41vnB3fCDywSZpZsNuMC7rw4Xz/0z0S7ixUF SWnAbkyGJqRrfVCsRgrCuzGphFqb7n0TYwzAlJLnO0m6Pe11JiH2rwgynEy3Gkg+CPWT aiW+zYHeR6fgKDgid4BF17xd1/r8t5Yxe29QQczdAySxIndvdAS+ilBepMvCPXzYl/cc 2VefMyuaf13SAOqLp5H4SZNfkqjEPY7B/G7NDU3vCPIo6FnSOiRLNQ2m1nZDqJdoBHVH Wb9OlZ4zecdj1j/sRbYPo101GLODaflsMxFGm+eQ6qQIMkmPfKyeRAGOJQ7iEj2m7U4w ojqg== 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=IHB6WiVq2WdOmMgxLb6otpWZlVRZ6FCx0YazQVyOxE4=; fh=eMKn2xZ8okKaPd9rhcV9lV/BFuYkd2Pgumm+dgdq5Bo=; b=R5n8sNSp4/jmpuMYw1W0U3JSNLuC3cwXTww/6+/BbNhRMVdv8cFaDXj8GTm2CA4zJS +sTck78FGNUqRJXqwN3d7jD2Vk6bO1dBBKuPg2mAL/X22EcVYY/92XOsYvLLq3Qg939/ PkUbFmSNT5I5gF7HU37k0x3kUw6IKk7HQlk2x/q102qT9hZ8roSNjld057Yk5Er12Raf lveoelu9gJotx0zyw5sIyJpvBkSvs9gMXBWpes0k39+mK1xReYNAwsrXxNMjvqwBGAb4 KwsGfF3lpKSMb9rtGl5CU1u9B7C0tGwq8E4/6K6wdNRbIIQXUEEWuX657ebNdeyWEalL +MXA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AFNElJ828LfMGIXi6TUNroaYqfJLQei4GellmFFgAV/AwPl63QnJ8JTH82khbnEpe7m7wOZvP+qZ6iKn/Ts/@googlegroups.com X-Gm-Gg: AeBDies5tI1z70HSuZH3t2cAEuqWz0+Qal1vIjOHbPxulEFeLyCERzcWSifLPkqfD4k lN0uh0iXBwxrL+OGMjS3vOnACfviBMpj9fr0kl0r7a+3IpwEb3cdwf2fzx3yyPH78sCrwkXz2lI cCRjlMNDe9Bv3H2uSTHaPU4RElrowEdeSSCbd8d/kAH028BFy/DcwDeLgUVnNOcH/8XuvhgR4RX lBCl45qnHbasJG8O9EtYudbR1SZeZ/IF6rFh1varrWRReQzvI+v/tB5aUAXWDvLumdNewrgzFtm H4bMzw41mLnnTshKpkGsPhLft/3BKYW17IWJYPSEvGogD9yLMFIuKWC5cPBw5Yb43kXw5Ma1obx koj4u6HoznY9nQxCXP4U/3YjuGO3fLssXYh+st0iF37uwCzEPa/i0d3zaCCVIOvndXqZDodUDdS +DhQPxFvna5A9dS9Zb9n11LCIESdqQbstkO0dqRd9Yo/UG/Bb+lFrSgi2RCMhP1RZ3iPzilS0kA uFycULwcvc1xdr3JQ== X-Received: by 2002:a05:6a20:244d:b0:3a0:d88:6d6b with SMTP id adf61e73a8af0-3a00d88792emr18431130637.49.1776270378037; Wed, 15 Apr 2026 09:26:18 -0700 (PDT) MIME-Version: 1.0 References: <779B3675-93F4-4175-84D2-55B6EA8930B2@mattcorallo.com> <51cd9663-4ff8-4534-8622-ede77e190021@mattcorallo.com> In-Reply-To: <51cd9663-4ff8-4534-8622-ede77e190021@mattcorallo.com> From: Ethan Heilman Date: Wed, 15 Apr 2026 12:26:08 -0400 X-Gm-Features: AQROBzD4SVyBDkdtWGAZAZrqj1t_WSUVeWJISJoIZdLwDgD8J1TdewgygExF4v8 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="000000000000e8755e064f822cae" 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="ky/KQ+LT"; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::529 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 (/) --000000000000e8755e064f822cae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The response below is not me being rude, but an attempt to be as clear as possible since either you are misunderstanding me or I am misunderstanding you. As far as I can tell, no one is proposing P2MR + PQ with address reuse other than you. I agree that your proposal to use P2MR in this way has the problems you point out. This is why, I am **not** proposing to use P2MR+PQ with address reuse, but instead P2MR+PQ without address reuse. The design choices are: P2MR without address reuse. There will be work here to ensure wallets don't mess this up. P2TRv2 that allows address reuse because the EC spend path could be disallowed in a future softfork. There will be work here to ensure wallets don't mess this up. P2TRv2 seems risker to me because it requires rushing to activate a softfork just before an event, where no one can agree on when the event will happen and it may happen in secret. I suspect many large custodians and small holders will not want to trust that the softfork gets the timeline right. On Wed, Apr 15, 2026, 12:03 Matt Corallo wrote: > Yes, that is what I'm thinking of. Specifically as deployed by a wallet > that reuses a single address > for ~all transactions, as those are the "marginal" wallets which we want > to encourage to move (see > my goals post which I just sent). > > Matt > > On 4/15/26 12:01 PM, Ethan Heilman wrote: > > 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 > lists@mattcorallo.com>> wrote: > > > > > > > >> 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 context 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 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 trans= acts > occasionally. A pure receive-only wallet > > is fine but that=E2=80=99s such a narrow use-case I=E2=80=99m not e= ven sure it=E2=80=99s > worth discussing? > > > >> 2. Even if the Schnorr pubkey has been leaked by the wallet, if th= e > 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 popula= r > 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 is no better wallet > >> hygiene that can fix this. > >> > >> You are comparing: > >> > >> P2MR + PQ signatures: A wallet messing up their implementation of > PQ safe 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 wa= llets > which are relevant to the =E2=80=9Cwe > > should give them maximum time to migrate=E2=80=9D discussion in a w= orld > where they use P2MR to a world > > without. Yes, there are wallets that would use 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 stor= age are > 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 >> lists@mattcorallo.com>> 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 note= d > below are 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 weed= s > 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*. In such a world, > >> bitcoin > >> > becomes largely value-less and the paranoid folks who > migrated long ago and paid for it > >> have > >> > accomplished absolutely nothing. I hope we can at least agre= e > 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 yo= u > 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 will migrate to P2MR > >> before Q- > >> >> day because it is slightly worse than P2TR until Q-day". An= d > 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 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 that 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 no incentive to > >> migrate either > >> >> way. > >> > > >> > See below > >> > > >> >> - The short-term efficiency difference in P2MR and P2TRv2 i= s > 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 like 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 protoco= l > 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 afte= r > 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. The= y > likely will be by the time > >> a CQRC is > >> > imminent. If they aren't, we'll almost certainly be back to > the drawing board on witness > >> discounts > >> > and whatever else which will mandate a new address format > anyway. There 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 t= o > 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 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 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 thin= k > 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, an= d > yet they are the ones who > >> actually > >> > decide in what way most bitcoin are stored! I don't know wha= t > their particular view on > >> quantum is, > >> > but my sense of most developers is that the view is generall= y > "well, it'll happen at > >> some point, but > >> > its not totally urgent". Meanwhile, people are almost withou= t > 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 you= r > 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 importan= t > 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. That 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 a= s > if we deployed P2TRv2. > >> Yes, there is > >> >> some risk of being caught with your pants down on Q-day, bu= t > 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 man= y > 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 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-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 conclud= e > 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 would 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 my own research by > >> saying > >> >> this, but it shows how hard it is to beat P2MR, even if you > can accept new cryptographic > >> >> assumptions and the accompanying performance penalties. > >> > > >> > Yes, we probably would. Not because of efficiency but becaus= e > a goal of 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 entire witness? If so, > >> how many > >> >> decades or centuries need to pass for everyone else to shar= e > that confidence? > >> >> > >> >> Personally I think we should learn our lesson from this P2T= R > 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 > protection 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 P2M= R > 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 CRQC= s > 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 CRQCs 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 implies 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 prett= y > clearly and I feel it is as > >> >> convincing as I can make it. I'd be happy to acknowledge an= y > 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 somewhat 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 original 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%2BUeV-dO2TT2Sg4rXqVuTauObJwF3K%2B2LmxTWFWE8ePcNg%40mail.gmail.com. --000000000000e8755e064f822cae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The response below is not me being rude= , but an attempt to be as clear as possible since either you are misunderst= anding me or I am misunderstanding you.

As far as I can tell, no one is proposing P2MR + PQ with address reuse o= ther than you. I agree that your proposal to use P2MR in this way has the p= roblems you point out. This is why, I am **not** proposing to use P2MR+PQ w= ith address reuse, but instead P2MR+PQ without address reuse.

The design choices are:

P2MR without address reuse. There wil= l be work here to ensure wallets don't mess this up.

P2TRv2 that allows address reuse because t= he EC spend path could be disallowed in a future softfork. There will be wo= rk here to ensure wallets don't mess this up.
P2TRv2 seems risker to me because it requires rus= hing to activate a softfork just before an event, where no one can agree on= when the event will happen and it may happen in secret. I suspect many lar= ge custodians and small holders will not want to trust that the softfork ge= ts the timeline right.

= On Wed, Apr 15, 2026, 12:03 Matt Corallo <lf-lists@mattcorallo.com> wrote:
Yes, that is what I'm thinking of= . Specifically as deployed by a wallet that reuses a single address
for ~all transactions, as those are the "marginal" wallets which = we want to encourage to move (see
my goals post which I just sent).

Matt

On 4/15/26 12:01 PM, Ethan Heilman wrote:
> I believe we are talking about exactly the same thing. A P2MR output t= hat 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@mattcorall= o.com <mailto:lf-
> lists@mattcorallo.com>> wrote:
>
>
>
>>=C2=A0 =C2=A0 =C2=A0On Apr 15, 2026, at 10:36, Ethan Heilman <eth3= rs@gmail.com <mailto:eth3rs@gmail.com>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0=EF=BB=BF
>>=C2=A0 =C2=A0 =C2=A0The proposal is P2MR with PQ sigs and no Schnor= r address reuse. Address reuse in this setting
>>=C2=A0 =C2=A0 =C2=A0should be treated as security vulnerability. >
>=C2=A0 =C2=A0 =C2=A0The context was a discussion of using P2MR with a E= X fallback =E2=80=9Cuntil it=E2=80=99s time=E2=80=9D. This avoids the
>=C2=A0 =C2=A0 =C2=A0substantial fee and functionality-loss overhead of = hash-based signatures =E2=80=9Cuntil it=E2=80=99s time=E2=80=9D.
>
>=C2=A0 =C2=A0 =C2=A0Yes, of course people could opt to not do that, but= then we=E2=80=99re back to where we started - not
>=C2=A0 =C2=A0 =C2=A0solving a useful problem for those who the problem = actually impacts.
>
>>=C2=A0 =C2=A0 =C2=A0> As such, P2MR with a EC-based key for shor= t-term efficiency reasons has the same quantum
>>=C2=A0 =C2=A0 =C2=A0security as P2TR or P2TRv2.
>>
>>=C2=A0 =C2=A0 =C2=A0This is incorrect.
>>
>>=C2=A0 =C2=A0 =C2=A01. As long as the Schnorr pubkey has not been l= eaked by the wallet. The wallet is PQ safe.
>
>=C2=A0 =C2=A0 =C2=A0Right, the context is a =E2=80=9Cnormal=E2=80=9D wa= llet which transacts occasionally. A pure receive-only wallet
>=C2=A0 =C2=A0 =C2=A0is fine but that=E2=80=99s such a narrow use-case I= =E2=80=99m not even sure it=E2=80=99s worth discussing?
>
>>=C2=A0 =C2=A0 =C2=A02. Even if the Schnorr pubkey has been leaked b= y the wallet, if the PQ leaf hash is not
>>=C2=A0 =C2=A0 =C2=A0publicly known it is safe against long exposure= attacks.
>
>=C2=A0 =C2=A0 =C2=A0Huh? If the address is reused as-is (as is the case= the most popular Bitcoin wallets today) a
>=C2=A0 =C2=A0 =C2=A0CRQC can trivially steal the funds with the EC key.= What am I missing?
>
>>=C2=A0 =C2=A0 =C2=A0P2TR is **always** vulnerable to short and long= exposure attacks. There is no better wallet
>>=C2=A0 =C2=A0 =C2=A0hygiene that can fix this.
>>
>>=C2=A0 =C2=A0 =C2=A0You are comparing:
>>
>>=C2=A0 =C2=A0 =C2=A0P2MR + PQ signatures:=C2=A0 A wallet messing up= their implementation of PQ safe transactions and
>>=C2=A0 =C2=A0 =C2=A0introducing a vulnerability and weakening a sub= set of outputs. If implemented correctly 100%
>>=C2=A0 =C2=A0 =C2=A0of the outputs are safe.
>>
>>=C2=A0 =C2=A0 =C2=A0vs.
>>
>>=C2=A0 =C2=A0 =C2=A0P2TR: A design where 100% of outputs are vulner= able even if the implementation is perfect.
>>
>>=C2=A0 =C2=A0 =C2=A0These aren't the same thing at all, nor do = they provide the same security.
>
>=C2=A0 =C2=A0 =C2=A0No, I=E2=80=99m comparing a realistic deployment of= P2MR for the wallets which are relevant to the =E2=80=9Cwe
>=C2=A0 =C2=A0 =C2=A0should give them maximum time to migrate=E2=80=9D d= iscussion in a world where they use P2MR to a world
>=C2=A0 =C2=A0 =C2=A0without. Yes, there are wallets that would use P2MR= =E2=80=9Cright=E2=80=9D, but those wallets literally do not
>=C2=A0 =C2=A0 =C2=A0matter for a discussion around what we need to get = in place as soon as possible - large
>=C2=A0 =C2=A0 =C2=A0custodians who won=E2=80=99t make any mistakes with= their cold storage are just as capable of making no
>=C2=A0 =C2=A0 =C2=A0mistakes later as they are today.
>
>=C2=A0 =C2=A0 =C2=A0For the actual wallets that we want to get migratin= g as soon as possible we=E2=80=99re talking about
>=C2=A0 =C2=A0 =C2=A0things that aren=E2=80=99t going to pay a 10x cost = increase and are going to continue using a single
>=C2=A0 =C2=A0 =C2=A0static address.
>
>=C2=A0 =C2=A0 =C2=A0Matt
>
>>=C2=A0 =C2=A0 =C2=A0On Wed, Apr 15, 2026, 07:02 Matt Corallo <lf-lists@mattcorallo.com <mailto:lf-
>>=C2=A0 =C2=A0 =C2=A0lists@mattcorallo.com>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Oh, apologies, I was in a bit of = a rush yesterday and forgot the most important reason why
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0P2MR
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0doesn't help at all - address= reuse.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In practice the "long tail&q= uot; of Bitcoin wallets (which, as noted below are most of what we
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0care
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0about) do strict address reuse. M= ostly a consequence of address-based blockchain systems
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0its become
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an expected feature that the addr= ess displayed in a wallet is static and does not change.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As such,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0P2MR with a EC-based key for shor= t-term efficiency reasons has the same quantum security
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as P2TR or
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0P2TRv2.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Matt
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 4/14/26 4:04 PM, Matt Corallo = wrote:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I'm gonna top-post becau= se I think we're too far in the weeds and the high-level
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0argument is getting
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> lost. No, of course I do not= thing that our job is to "convince" any quantum skeptics.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0What is our
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> job is making sure the *bitc= oin system* is ready in case a CRQC does become a reality.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0That means
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> looking at the system as a w= hole, not individuals. Notably, this means that if the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0decisions we make
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> result in a bitcoin where so= me people who are super worried about a CRQC have migrated
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0but everyone
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> else hasn't, and a CRQC = becomes an imminent reality, *we've failed*. In such a world,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bitcoin
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> becomes largely value-less a= nd the paranoid folks who migrated long ago and paid for it
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0have
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> accomplished absolutely noth= ing. I hope we can at least agree on this point.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> On 4/14/26 2:56 PM, conduiti= on wrote:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Hi Matt,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> Right but you didn&#= 39;t contend with my point at all, only ignored it. Its great that you
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0can move
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> your coins into some= thing so that your coins aren't stolen but...who cares? If a huge
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0% of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> outstanding bitcoin = supply is being stolen that impacts you just as much as if your
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0own coins
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> were being stolen! >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> I don't think I igno= red anything, but maybe I just didn't understand your point.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> To me, your point seems = to be (I'm summarizing here) that "Nobody will migrate to P2MR
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0before Q-
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> day because it is slight= ly worse than P2TR until Q-day". And your conclusion is, in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0your own words:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> Thus, ISTM the focus= *has* to be on something that has minimal drawbacks - not losing
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the script
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> policy privacy of P2= TR, low or no fee overhead, etc.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> This seems to imply you&= #39;re arguing that at least some of those same people (who
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wouldn't use P2MR)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> WOULD migrate to P2TRv2,= because it is exactly as good as P2TR until Q-Day.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Yes, exactly.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> I respectfully disagree = with this argument, and I gave my reasoning as to why in my
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0last reply. To
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> review:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> - P2MR is quantum-secure= by default.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> - P2MR is more efficient= long-term.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> This assumes a CRQC.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> - P2MR does not commit u= s to carrying legacy crypto cruft past its shelf-life.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Nor does P2TRv2? No one is s= uggesting P2TRv2 becomes some standard that all wallets use
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0forever. No
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> matter what we do we carry t= he "cruft" of P2TR in Bitcoin forever (+/-), P2TRv2 has
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0literally zero
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> additional cruft.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> - P2MR and P2TRv2 are bo= th equivalent to quantum-skeptics, who have no incentive to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0migrate either
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> way.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> See below
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> - The short-term efficie= ncy difference in P2MR and P2TRv2 is a negligible trade-off to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anyone who
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> ISN'T a total quantu= m-skeptic.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> - Fee-sensitive users ar= e online and adaptive, and can use P2TR until Q-day; They do
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not need
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> P2TRv2 any more than fee= -insensitive users.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I disagree very strongly wit= h this. This would be true if everyone had their own custom-
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0built wallet
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> that they designed to meet t= heir goals exactly. In the real world people pick wallets
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0based on many
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> other factors, and developer= s build wallets for many different users, some of which may
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be fee
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> sensitive and some of which = may not be, all of whom will use the same default configuration.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> - P2MR has utility even = if Q-day never comes.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I disagree. The overall util= ity to the Bitcoin system of something like P2TR is also the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0global
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> default that is strongly bak= ed in which results in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> - Also, I failed to make= this point in my last reply: P2MR and P2TRv2 have the same
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0privacy
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> profile AFAICT, assuming= both commit to a hash-based fallback leaf script.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I don't see how this is = true in practice. Maybe in a world where everyone uses P2MR with
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a single
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> left-hand leaf at depth one = with a single EC schnorr key which is musig2, but....come
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on. The value
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> of taproot is that its desig= n natively adds this *for free* to every contracting
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0protocol, and not
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> only adds it for free but *f= orces* every contracting protocol to carry at least some of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the cost if
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> they decline to do this. Thi= s results in a massive net privacy win across the entire
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bitcoin
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> ecosystem, and I don't s= ee how you can argue that these things are equivalent in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0practice, just
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> because they could in theory= be used in a way where they are in theory.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Therefore, P2MR is the b= etter long-term choice.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> If we assume Bitcoin wil= l survive long into the future after CRQCs appear, then we
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0should favor
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> the best long-term desig= n choices over short-term compromises. Thus, we should deploy
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0P2MR and NOT
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> deploy P2TRv2.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Not only do I disagree with = most of your points here, but I disagree that we should be
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0optimizing
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> for a "long-term design= " which we intend to be *the* design we use in the face of an
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0imminent CRQC.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> We already know we're no= t doing that - we're not using lattices or isogenies or whatever
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we'll
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> actually end up using becaus= e those things aren't ready. They likely will be by the time
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a CQRC is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> imminent. If they aren't= , we'll almost certainly be back to the drawing board on witness
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discounts
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> and whatever else which will= mandate a new address format anyway. There is basically
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0zero chance
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> that whatever we do today wi= ll be what we end up using "normally" in a world with a CRQC.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> But what about someo= ne who sees quantum computers as 90% FUD that might happen
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0eventually but
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> won't for 50 yea= rs but still gets users nagging them about it and support for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0importing some new
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> seedphrase format th= at derives a SHRINCS key in addition to the EC ones? That's much
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0less of a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> straw man and way mo= re realistic - and also a place where someone might do the work
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(or, well,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> merge a PR if its do= ne for them) but probably won't if they're building a consumer
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wallet that is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> used by some to tran= sact regularly (but, let's face it, used primarily by some people
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0who put
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> some money in and th= en forgot about it for five years).
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Very specific. You'r= e talking about wallet developers here, right? Exchanges? Bitcoin
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0businesses
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> in general etc? And you&= #39;re saying that the people running these businesses and building
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> wallets - those who are = being "nagged" to implement something that the rest of the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cryptographic
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> world has already starti= ng rolling out in production [1] - You're saying that a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0subclass of these
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> people - those who are &= quot;mostly" skeptical of quantum hype - WOULD implement P2TRv2, but >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0WOULDN'T
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> implement P2MR?
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> It's debatable how b= ig that subclass would be, especially given the current landscape.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I don't think this is &q= uot;very specific" at all? In fact I think this is the *dominant*
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case. By coin
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> volume, yes, the biggest wal= let is Coinbase's custody product. By wallet count, the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0biggest wallet
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> is probably something like T= rust Wallet. Its trash, doesn't care about Bitcoin, makes
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0many terrible
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> design decisions which are a= ctively hostile to its users, and yet they are the ones who
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0actually
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> decide in what way most bitc= oin are stored! I don't know what their particular view on
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0quantum is,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> but my sense of most develop= ers is that the view is generally "well, it'll happen at
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0some point, but
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> its not totally urgent"= . Meanwhile, people are almost without question going to nag some
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wallets for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> "quantum security"= once its a thing.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> You might reasonably disagre= e with whether they would implement P2TRv2 vs P2MR, I think its
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> definitely a subtle argument= , but I don't think you can reasonably disagree that these
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0are exactly
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> the most important constitue= nt here.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 > But even if one c= onfidently sees CRQCs as 50 years away, then I'd refer back to my
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0earlier
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> response, and argue that any= such skeptical developer has no reason to implement either
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0P2MR or
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> P2TRv2 today, apart from com= patibility with other software which DOES implement them. If
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"nagging"
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> is the only motivation a dev= or business owner has to implement a PQ output type, then
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0one need not
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> distinguish between the two.= They'd just implement whatever is standardized to please
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0their users,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> and carry on with their day.= >
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> If I'm being a littl= e more realistic, most wallet devs will follow whatever is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0standardized just
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> to get more market share= . I somehow doubt devs will turn up their noses and say "it's not<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> efficient enough, I won&= #39;t implement that even if a large chunk of my customers are
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clamoring for it."
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> I think this reveals the= source of our disagreement. In your arguments, you are placing
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a lot of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> weight on the importance= of pre-quantum fee-efficiency in the new output type, so much
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0so that you
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> seem to think devs would= willingly ignore a potential existential threat to save users
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a few sats
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> per transaction.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> It is far from only "pr= e-quantum fee-effeciency", its also the value for the entire
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Bitcoin system
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> of the privacy taproot offer= s. But I think the more important argument specifically here
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> question of what they will m= ake the *default*. In a world with P2MR I could absolutely
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0see them
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> implementing a P2MR option w= hich you can opt into in the settings. That fails to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0accomplish our
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> goals entirely. Maybe they a= lso would do the same for P2TR/P2TRv2, but I at least think
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that's
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> somewhat less likely, but in= any case better for the bitcoin system overall if that's
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0where we land.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> But maybe look at it thi= s way:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> - Whether quantum comput= ers are 5, 10, 50 years or more away, anyone who truly cares
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0about a few
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> extra sats per TX can co= ntinue to use P2TR when actively transacting pre-Q-Day, and use
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0P2MR for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> high-security cold stora= ge. The result is mostly the same as if we deployed P2TRv2.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, there is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> some risk of being caugh= t with your pants down on Q-day, but the same is true of P2TRv2
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0because we
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> might not time the key-s= pend disabling follow-up fork correctly.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> - Mining fees are a part= of everyday life for Bitcoiners, and the pre-quantum fee
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0difference
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> between P2TR and P2MR is= NOTHING compared to the fee spike we'll all have to endure
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0after Q-day,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> no matter what fancy cry= ptography we may end up using by then. There are far more
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0important things
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> we can optimize.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> Again, you ignore th= at the impact is global, not local. Yes, quantum-skeptics have to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be brought
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> along over time if y= ou want to have any hope of bitcoin actually being relevant.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Our job is not to prosel= ytize and convince people that the quantum threat is real, nor
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is it even
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> to encourage migration b= y design. Our job is to prepare an optimal migration path in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> threat is real. If CRQCs= do appear, everyone will want to migrate to PQC sooner or
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0later. If they
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> do not, everyone moves o= n with their lives and the new output type becomes a relic (in
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0P2MR's
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> case, an occasionally us= eful one).
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Even if you feel your jo= b IS to convince and migrate as many users as possible, I would
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0argue
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> it'll be hard to con= vince anyone to migrate to an address format that isn't PQ-safe by
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0default.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Bitcoiners trust code, n= ot promises, and P2TRv2 is only PQ-safe if you trust its
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0promise of a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> future soft fork, while = its code would be PQ-vulnerable by default. And the only
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0benefit to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> accepting this risk seem= s to be a trivial discount in fees pre-Q-day. I don't speak for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0everyone
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> of course, but personall= y I'd rather keep my cold-storage coins on a P2WSH address than
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on P2TRv2,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> because at least then I = know for sure a CRQC will have a hard time stealing my coins
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regardless of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> what upgrades the commun= ity does or doesn't deploy in the future.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> See intro. I don't reall= y see how you can reasonably conclude that our goal is only to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enable a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> small subset of people to mi= grate. That way leas only to a total failure of the bitcoin
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0system.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> Sure, but any short = term hash-based signature migration path is really not intended as
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the final
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> state anyway - if Bi= tcoin is stuck with only hash based signatures and a CRQC exists
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in 20 years
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> that's a pretty = terrible outcome. Hopefully by the time a CRQC becomes a real threat
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we have much
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> more confidence in l= attice-based systems (or whatever PQC is popular then) and we can add
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> whatever output type= makes sense at that point.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> I agree about hash-based= sigs not being the endgame. Though, this doesn't mean P2MR
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0isn't. We're
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> talking about output typ= es here, not opcodes. I would argue P2MR remains useful
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0regardless of the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> cryptography we use: lat= tice, isogeny, hash-based, multivariate, whatever. Merkle trees
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0have been
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> around for almost 50 yea= rs and seem hard to beat.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> For instance, we could r= econstruct P2TR using isogenies [2], but would we really want
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to? Using
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> today's witness disc= ount levels, it would actually be MORE efficient overall to spend
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with SQIsign
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> inside a P2MR tree, than= it would be to use SQIsign to key-spend with some hypothetical
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Pay-to-
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> supersingular-curve"= ; output type [^3]. I realize I'm kinda trashing my own research by
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0saying
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> this, but it shows how h= ard it is to beat P2MR, even if you can accept new cryptographic
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> assumptions and the acco= mpanying performance penalties.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Yes, we probably would. Not = because of efficiency but because a goal of taproot is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*privacy* while
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> offering efficiency for the = common (all-sign) case. That is generally true across
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0contracting
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> protocols and makes things n= et-cheaper with a taproot-style system where you hit the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0common case
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> often. This is another reaso= n why P2MR is quite a loss -
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Even if we do someday fi= nd some novel cryptosystem which permits rerandomization, and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we design a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> new output type as effic= ient and performant as P2TR but in a post-quantum context, is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the systemic
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> risk really worth saving= a few vbytes - a small fraction of the entire witness? If so,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0how many
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> decades or centuries nee= d to pass for everyone else to share that confidence?
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Personally I think we sh= ould learn our lesson from this P2TR debacle, and encourage
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0users to hide
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> public keys behind hash = functions from now on, and to bolster riskier algorithms with
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hash-based
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> fallback keys, so that w= e always have at least one layer of protection between keys and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0any novel
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> cryptanalytic breakthrou= ghs. Posting our plain pubkeys on-chain does sometimes have fun
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0benefits,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> but the drawbacks are de= adly serious.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Until SHA256 collision r= esistance is broken, I'd expect P2MR is probably the pinnacle
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of secure PQ
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> address formats, and eve= n then we'd probably end up reimplementing P2MR with some newer
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hash
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> function. Hopefully some= day someone proves me wrong, but we can only engineer with what
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0we know
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> today, and today P2MR se= ems the most optimal conservative option for long-term security
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> cryptographic agility. >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> As mentioned above if we end= up in this situation we're almost certainly going to be
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discussing a
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> P2MRv2 with an additional wi= tness discount, so...
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>> And with them they w= ill take bitcoin's value...
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> If you're really wor= ried about a supply glut caused by CRQCs stealing and dumping them,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> debating about P2TRv2 an= d P2MR is a distraction. IMO, most coins will probably not
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0migrate before
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Q-Day regardless of what= output types we deploy, because many coins are held by dead
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hands, or by
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> living hands who just do= n't read the news.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> If this concerns you (an= d it concerns me too), then saving a few vbytes per spend pre-
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Q-day is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> trivial by comparison, a= nd optimizing it will make little impact on the integrity of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the UTXO set
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> after Q-day. I would ins= tead suggest you pursue the retroactive area of research (rescue
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> protocols, quantum canar= ies, hourglass, exposure statistics, etc). This is a domain
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0where real
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> impact can be made to mi= tigate the risk of a supply glut when/if CRQCs appear.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Opportunities
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> abound. We would be glad= of the help :)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> This is fair, and we should = do this too, but I don't see how it implies we should not
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0also be
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> concerned with ensuring maxi= mum possible migration.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Anyways, I appreciate th= e good-spirited debate, but to save myself time I don't think I'll<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> continue replying. I'= ;ve laid out my argument for P2MR pretty clearly and I feel it is as
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> convincing as I can make= it. I'd be happy to acknowledge any misunderstanding I may
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0have had about
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> your earlier points in f= avor of P2TRv2.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Fair enough. I continue to t= hink we're talking past each other somewhat but ultimately I
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0think my
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> concern is for ensuring bitc= oin survives, while you're more concerned with giving those
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0who are
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> concerned an option to feel = warm and fuzzy :).
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> As to the original subje= ct of the email thread, and Antoine's original points, seems
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0like we are
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> all in agreement.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Indeed.
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>

--
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%2BUeV-dO2TT2Sg4rXqVuTauObJwF3K%2B2LmxTWFWE8eP= cNg%40mail.gmail.com.
--000000000000e8755e064f822cae--