From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Apr 2026 09:51:49 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wD3St-0008Dg-Kw for bitcoindev@gnusha.org; Wed, 15 Apr 2026 09:51:49 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-4236c3b8f32sf14185518fac.0 for ; Wed, 15 Apr 2026 09:51:47 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776271902; cv=pass; d=google.com; s=arc-20240605; b=AoCOfWYKo1HWAnXmKwZU9AEBNFFzVMelSd/wudI5SJ9d8n+Y4LfaZlnZPGzluoQyH4 fNIUuOtqdYAjVjcWnC8xPcQU7MzJAnQAZhKwiv3ZQOipsYFVjVI0Qnn6Pfn1A/yhUONe I0l7Hoes6NDczTIXGFveMiHGezyAColmhCz9QsmeZAaXulhyTD3dGNbztZSPGuUU67H5 nigzDSaYRgUCBDiLyQoXpx4Rtk5lijd7uoPakXjWw83NTxO2oM+B7/3uGZuyNDPtag/B HZkWmEi4DucvFpyGDc5KBOCB1RvCzViWUA9Mcpzj/KoITtcZ6d685TaibcZh9Pd7ngxg 5t8g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:to:in-reply-to:cc:references :message-id:date:subject:mime-version:from:content-transfer-encoding :sender:dkim-signature; bh=eoCZjDgTU3OEV1mzY7UWTVc2C0sF6KGeaNgRuaO7Hk8=; fh=1fO1l/T1G4748bhBDq5avopB64f3caUhdtmCJ91x68g=; b=Pr3o27xzo5BDyeATWD477OUIf0mOeyHWAXrFWhzZa6cPXvgXAsTI+4TEJUkUvAovSN SsFHiqXs1hVkRkOLuUKfnl8NGdjDzBseo5RirnfDGLTSP8PCJwYltMSozjRIjzNg+Hh3 cDtJdHXlDDUsKaH3HNMVgQ+995RPYwlSksJuRhvRSBEs2KiDDi0HqxC3+qwDYmbCGD57 NWoDla6wrjck45++MSLJdHdIvJkLN9mR7nte0lhlP7zdkZnbx8+1ljFuaLKhp9Azflox W53jNLhOKtDOSxxQourwu9a3WC9u3HmUYrHt3APvGDvZx+ShYv4pudhaYn+9mwqaTHkD fa+A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776268862 header.b=B7iCuPdW; dkim=pass header.i=@clients.mail.as397444.net header.s=1776268865 header.b=q8MD0bak; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776271902; x=1776876702; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:in-reply-to:cc:references:message-id:date :subject:mime-version:from:content-transfer-encoding:sender:from:to :cc:subject:date:message-id:reply-to; bh=eoCZjDgTU3OEV1mzY7UWTVc2C0sF6KGeaNgRuaO7Hk8=; b=XszwO5fju0cyY1XAB477kz54SAN36Id6ZG9Kt5jkl9ie5reXTso2Z06PqmWIff62ni NxvtldCBeg++K9/GiK40SfzDMTYthNscjHmmzzodN4ScwafjYZpSD5K4mBtQcyVEeZhR za6+y9UpfPBbV65uNaE0uwVfi8IJgzAitT1bqNbTKRjUDgpgIGWp/0pbBERaFqFo5vo6 rKqQ06TJIy8EzNfTpJxLWmmlQqcAzFQ0FgBhDywfU8KhdMRxymEK/mDK/N3F5Ck3oLVG jK1vdjKBIz9K2LEvlMu7maeFEgi9rd7UTz6vSaySPd0AEz3OuezPkoOgsslIclasqE3B LcDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776271902; x=1776876702; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:in-reply-to:cc:references:message-id:date :subject:mime-version:from:content-transfer-encoding:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=eoCZjDgTU3OEV1mzY7UWTVc2C0sF6KGeaNgRuaO7Hk8=; b=s2P9bV6ISBxYL0GDZ5AhnUT6ePH1IgZR44flW9p8nkYwvkXOmN1iuGEu+mmCtTiz3d Me1M6Q59F0p2mc42Q0DwTE4xLk0vAgH+QtQDFoP1I4ZVyApsEdPe1e2tOwZoCq7Zx0P6 5viXxgv7Q7mUD0wBtuV1Y+Pze1na2cXd/tr30L1A5yvTpbh90JnJEIo56GV5ZX+wKnYv CnevzLdjiqAdLgk/fmYbiFaU6jbnzPAYEasSGj5RsqNDNWoEEd/VLEhsyylgxxGrVEnf ySzbqdy503ujsAJkK0xvNCpaEWm6mcA2N0W7oy90KQb9j1fMTaPvmUrecUsZfgapuhE2 AOlA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ+ZfGiU02n+HXr0IZLu57VllEqWHGQT2wN+kRPCR3WXsQxIycI1QbqtdMEPoo2vDzoCCAaXuroKIv+7@gnusha.org X-Gm-Message-State: AOJu0YxnJNE3Sz2BR+aQHwTPFVc/R9Oj9cFHYoK6L8gJMv6WKELtICzv +hJz8+IrD96OMUSDWrWhIt/pxOd0glPw99sF8LWIzL2QMTzSwpHCFHok X-Received: by 2002:a05:6871:6c0a:b0:41c:686c:322b with SMTP id 586e51a60fabf-4280ac4f928mr175343fac.9.1776271901415; Wed, 15 Apr 2026 09:51:41 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiIRJ02YpNkBlm8E4wwha6H9uRzlcq4Ckh7zvOil5Tpf9w==" Received: by 2002:a05:6870:8dcf:b0:41c:6a62:2ef1 with SMTP id 586e51a60fabf-4246f10f9e2ls330119fac.2.-pod-prod-00-us-canary; Wed, 15 Apr 2026 09:51:36 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ9PNNIsXHZ3I+b2ToU7lx59OXP+Cl1aIcFlDoZ1s9gDRScBz4kjqmeFUF8Sh2eOELw0T7daf9UwWp/x@googlegroups.com X-Received: by 2002:a05:6808:159b:b0:467:e1a8:2b92 with SMTP id 5614622812f47-47984f28331mr143409b6e.10.1776271896504; Wed, 15 Apr 2026 09:51:36 -0700 (PDT) Received: by 2002:a05:6808:c3a7:b0:479:777b:d692 with SMTP id 5614622812f47-479777bdccbmsb6e; Wed, 15 Apr 2026 09:36:22 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ80F1TbvV1il/EhG5AytvHuQHmoUZfXoJ1QAh6qK+xA1RRu1hGQKAh6sgZ1rJT5Ya4jIZMasAWBfC9O@googlegroups.com X-Received: by 2002:a17:90b:3d92:b0:35f:b1ae:d0ee with SMTP id 98e67ed59e1d1-3612f295c21mr191674a91.5.1776270981546; Wed, 15 Apr 2026 09:36:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776270981; cv=none; d=google.com; s=arc-20240605; b=Ehsx0ayJjeEHNO0DkMMEYJfsLwhEsT9yMQe9ZpEsobWEhzOUzLmGCP54bfVSHC8OAy 6kITX3ldP8Xf6xQtS25K6SIr1YlbCVNZjB8SE7Egka2PJ5M1nBqrLrnrwY7jTSOwrbcN XPRUkIL32AxVjs62LOGel425eqJvxpbCBxm/hHa3WhktpHjK9QqRYsQ20FkltkbK75XF Jms/rmdU0LYSSRl0/slU771RsOSPvvPx3cBFWx+df3sDWA5tS0YQJESBpQ7vcI23PUxh jXyGehCfFcG9mYi6QnJFZqHFDwXyPmM09jdBxK7dUUjaFw1YWvRQfM0Tz1gCaNm39oHO wtew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:dkim-signature:dkim-signature; bh=+OhCqlqAKLDXj+h3t8I/f/U2E3foo7NfsduNx5xS1n8=; fh=wTvfnnPutYPyC8mS8xtoqTr7VF78o7m+Hg6vypSJAU4=; b=GvXwgjKDo/hzpFUgEQQ8gtuX11Qc+z00MYjibNuNxd7TBefiPVALGxL8IJlD1itoVp dkba8NMMiz3c8K4dB5MN6gW7UvqyxCnMhiY4lfnm6IUx4NZzcs3fxOGrFKNVr83tcb3h XEAfnrbWpT05suqC9ORv0jEgSFzUGFvFjup1nm/XsiXmedswtabdZ0WsqFFk46TOuaIc iNFguXpeviRy7Jwfyod7vqLm/UdjDtBWbJ59uMX/Mu4/EWMzJzDebaMEBVuyZE5S+zx8 PhSpA1A7+OUnb+2dZPXNT7lo5/Pw8Vr4Waev34FSOJacbQg2cQXTJ3DpMAFkOcawdJZF GtQw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776268862 header.b=B7iCuPdW; dkim=pass header.i=@clients.mail.as397444.net header.s=1776268865 header.b=q8MD0bak; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Received: from mail.as397444.net (mail.as397444.net. [2620:6e:a000:1::99]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-c7957f1b22fsi76723a12.2.2026.04.15.09.36.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2026 09:36:21 -0700 (PDT) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) client-ip=2620:6e:a000:1::99; X-DKIM-Note: Keys used to sign are likely public at X-DKIM-Note: https://as397444.net/dkim/mattcorallo.com and X-DKIM-Note: https://as397444.net/dkim/clients.mail.as397444.net X-DKIM-Note: For more info, see https://as397444.net/dkim/ Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim) (envelope-from ) id 1wD3Du-00000005ytE-3Nkv; Wed, 15 Apr 2026 16:36:19 +0000 Content-Type: multipart/alternative; boundary=Apple-Mail-97FC7308-0020-4792-AAAA-A099A670A969 Content-Transfer-Encoding: 7bit From: Matt Corallo Mime-Version: 1.0 (1.0) Subject: Re: [bitcoindev] In defense of a PQ output type Date: Wed, 15 Apr 2026 12:36:06 -0400 Message-Id: <32A116B5-22B8-43E9-BD54-EB330C2A1523@mattcorallo.com> References: Cc: conduition , Antoine Poinsot , bitcoindev@googlegroups.com In-Reply-To: To: Ethan Heilman X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776268862 header.b=B7iCuPdW; dkim=pass header.i=@clients.mail.as397444.net header.s=1776268865 header.b=q8MD0bak; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 2620:6e:a000:1::99 as permitted sender) smtp.mailfrom=lf-lists@mattcorallo.com; dmarc=pass (p=NONE sp=REJECT dis=NONE) header.from=mattcorallo.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 1.6 (+) --Apple-Mail-97FC7308-0020-4792-AAAA-A099A670A969 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right, so I=E2=80=99m not= proposing address reuse is a good thing, maybe that=E2=80=99s the misunder= standing. Of course not. Personally I=E2=80=99d rather we=E2=80=99d have ba= nned address reuse in consensus in 2010, but that ship has sailed. Rather, = that address reuse, at this point, is a fact of life for the =E2=80=9Cmargi= nal=E2=80=9D wallets we care about - the middle of the balance distribution= wallets that are not going to be guaranteed first-movers on the PQ front, = and the ones I, thus, think were forced to optimize for.

Matt

On Apr 15, 2026, at 12:30, Ethan Heilman <eth3rs@gmail.com&= gt; wrote:

=EF=BB=BF
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 a= ddress 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 re= use. 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 requir= es rushing to activate a softfork just before an event, where no one can ag= ree on when the event will happen and it may happen in secret. I suspect ma= ny large custodians and small holders will not want to trust that the softf= ork gets 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:
>
>
>
>>     On Apr 15, 2026, at 10:36, Ethan Heilman <eth3= rs@gmail.com <mailto:eth3rs@gmail.com>> wrote:
>>
>>     =EF=BB=BF
>>     The proposal is P2MR with PQ sigs and no Schnor= r address reuse. Address reuse in this setting
>>     should be treated as security vulnerability. >
>     The 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
>     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 shor= t-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 l= eaked by the wallet. The wallet is PQ safe.
>
>     Right, the context is a =E2=80=9Cnormal=E2=80=9D wa= llet 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 b= y 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 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 sub= set of outputs. If implemented correctly 100%
>>     of the outputs are safe.
>>
>>     vs.
>>
>>     P2TR: A design where 100% of outputs are vulner= able 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 d= iscussion in a world 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 storage are just as capable of making no
>     mistakes later as they are today.
>
>     For the actual wallets that we want to get migratin= g 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 <lf-lists@mattcorallo.com <mailto:lf-
>>     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 reu= se.
>>
>>         In practice the "long tail" of Bi= tcoin wallets (which, as noted below are most of what we
>>         care
>>         about) do strict address reuse. M= ostly a consequence of address-based blockchain systems
>>         its become
>>         an expected feature that the addr= ess displayed in a wallet is static and does not change.
>>         As such,
>>         P2MR with a EC-based key for shor= t-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 *bitc= oin system* is ready in case a CRQC does become a reality.
>>         That means
>>         > looking at the system as a w= hole, not individuals. Notably, this means that if the
>>         decisions we make
>>         > result in a bitcoin where so= me people who are super worried about a CRQC have migrated
>>         but everyone
>>         > else hasn't, and a CRQC beco= mes an imminent reality, *we've failed*. In such a world,
>>         bitcoin
>>         > becomes largely value-less a= nd the paranoid folks who migrated long ago and paid for it
>>         have
>>         > accomplished absolutely noth= ing. I hope we can at least agree on this point.
>>         >
>>         > On 4/14/26 2:56 PM, conduiti= on 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 some= thing 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 will migrate to P2MR
>>         before Q-
>>         >> day because it is slight= ly 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 P2= TR, 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 u= s to carrying legacy crypto cruft past its shelf-life.
>>         >
>>         > Nor does P2TRv2? No one is s= uggesting P2TRv2 becomes some standard that all wallets use
>>         forever. No
>>         > matter what we do we carry t= he "cruft" of P2TR in Bitcoin forever (+/-), P2TRv2 has
>>         literally zero
>>         > additional cruft.
>>         >
>>         >> - P2MR and P2TRv2 are bo= th equivalent to quantum-skeptics, who have no incentive to
>>         migrate either
>>         >> way.
>>         >
>>         > See below
>>         >
>>         >> - The short-term efficie= ncy difference in P2MR and P2TRv2 is a negligible trade-off to
>>         anyone who
>>         >> ISN'T a total quantum-sk= eptic.
>>         >> - Fee-sensitive users ar= e 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 wit= h this. This would be true if everyone had their own custom-
>>         built wallet
>>         > that they designed to meet t= heir goals exactly. In the real world people pick wallets
>>         based on many
>>         > other factors, and developer= s 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 util= ity to the Bitcoin system of something like P2TR is also the
>>         global
>>         > default that is strongly bak= ed 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 desig= n natively adds this *for free* to every contracting
>>         protocol, and not
>>         > only adds it for free but *f= orces* every contracting protocol to carry at least some of
>>         the cost if
>>         > they decline to do this. Thi= s results in a massive net privacy win across the entire
>>         Bitcoin
>>         > ecosystem, and I don't see h= ow 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 b= etter long-term choice.
>>         >>
>>         >> If we assume Bitcoin wil= l survive long into the future after CRQCs appear, then we
>>         should favor
>>         >> the best long-term desig= n 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" whi= ch we intend to be *the* design we use in the face of an
>>         imminent CRQC.
>>         > We already know we're not do= ing that - we're not using lattices or isogenies or whatever
>>         we'll
>>         > actually end up using becaus= e 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 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 wi= ll be what we end up using "normally" in a world with a CRQC.
>>         >
>>         >>> But what about someo= ne who sees quantum computers as 90% FUD that might happen
>>         eventually but
>>         >>> won't for 50 years b= ut still gets users nagging them about it and support for
>>         importing some new
>>         >>> seedphrase format th= at derives a SHRINCS key in addition to the EC ones? That's much
>>         less of a
>>         >>> straw man and way mo= re realistic - and also a place where someone might do the work
>>         (or, well,
>>         >>> merge a PR if its do= ne for them) but probably won't if they're building a consumer
>>         wallet that is
>>         >>> used by some to tran= sact regularly (but, let's face it, used primarily by some people
>>         who put
>>         >>> some money in and th= en forgot about it for five years).
>>         >>
>>         >> Very specific. You're ta= lking 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 starti= ng 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 t= hat 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 wal= let is Coinbase's custody product. By wallet count, the
>>         biggest wallet
>>         > is probably something like T= rust Wallet. Its trash, doesn't care about Bitcoin, makes
>>         many terrible
>>         > design decisions which are a= ctively hostile to its users, and yet they are the ones who
>>         actually
>>         > decide in what way most bitc= oin are stored! I don't know what their particular view on
>>         quantum is,
>>         > but my sense of most develop= ers is that the view is generally "well, it'll happen at
>>         some point, but
>>         > its not totally urgent". Mea= nwhile, people are almost without question going to nag some
>>         wallets for
>>         > "quantum security" once its = a thing.
>>         >
>>         > You might reasonably disagre= e 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 constitue= nt here.
>>         >
>>         >  > But even if one c= onfidently 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 com= patibility 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 mo= re 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-qua= ntum fee-effeciency", its also the value for the entire
>>         Bitcoin system
>>         > of the privacy taproot offer= s. But I think the more important argument specifically here
>>         is the
>>         > question of what they will m= ake the *default*. In a world with P2MR I could absolutely
>>         see them
>>         > implementing a P2MR option w= hich you can opt into in the settings. That fails to
>>         accomplish our
>>         > goals entirely. Maybe they a= lso 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 thi= s way:
>>         >>
>>         >> - Whether quantum comput= ers are 5, 10, 50 years or more away, anyone who truly cares
>>         about a few
>>         >> extra sats per TX can co= ntinue to use P2TR when actively transacting pre-Q-Day, and use
>>         P2MR for
>>         >> high-security cold stora= ge. The result is mostly the same as if we deployed P2TRv2.
>>         Yes, there is
>>         >> some risk of being caugh= t with your pants down on Q-day, but the same is true of P2TRv2
>>         because we
>>         >> might not time the key-s= pend 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 cry= ptography we may end up using by then. There are far more
>>         important things
>>         >> we can optimize.
>>         >>
>>         >>> Again, you ignore th= at the impact is global, not local. Yes, quantum-skeptics have to
>>         be brought
>>         >>> along over time if y= ou want to have any hope of bitcoin actually being relevant.
>>         >>
>>         >> Our job is not to prosel= ytize and convince people that the quantum threat is real, nor
>>         is it even
>>         >> to encourage migration b= y 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 o= n with their lives and the new output type becomes a relic (in
>>         P2MR's
>>         >> case, an occasionally us= eful one).
>>         >>
>>         >> Even if you feel your jo= b IS to convince and migrate as many users as possible, I would
>>         argue
>>         >> it'll be hard to convinc= e anyone to migrate to an address format that isn't PQ-safe by
>>         default.
>>         >> Bitcoiners trust code, n= ot 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 seem= s to be a trivial discount in fees pre-Q-day. I don't speak for
>>         everyone
>>         >> of course, but personall= y 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 commun= ity does or doesn't deploy in the future.
>>         >
>>         > See intro. I don't really se= e how you can reasonably conclude that our goal is only to
>>         enable a
>>         > small subset of people to mi= grate. 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 Bi= tcoin is stuck with only hash based signatures and a CRQC exists
>>         in 20 years
>>         >>> that's a pretty terr= ible outcome. Hopefully by the time a CRQC becomes a real threat
>>         we have much
>>         >>> more confidence in l= attice-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 typ= es here, not opcodes. I would argue P2MR remains useful
>>         regardless of the
>>         >> cryptography we use: lat= tice, isogeny, hash-based, multivariate, whatever. Merkle trees
>>         have been
>>         >> around for almost 50 yea= rs and seem hard to beat.
>>         >>
>>         >> For instance, we could r= econstruct 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" out= put type [^3]. I realize I'm kinda trashing my own research by
>>         saying
>>         >> this, but it shows how h= ard it is to beat P2MR, even if you can accept new cryptographic
>>         >> assumptions and the acco= mpanying performance penalties.
>>         >
>>         > Yes, we probably would. Not = because of efficiency but because 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 n= et-cheaper with a taproot-style system where you hit the
>>         common case
>>         > often. This is another reaso= n why P2MR is quite a loss -
>>         >
>>         >> Even if we do someday fi= nd some novel cryptosystem which permits rerandomization, and
>>         we design a
>>         >> new output type as effic= ient 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 nee= d to pass for everyone else to share that confidence?
>>         >>
>>         >> Personally I think we sh= ould 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 w= e always have at least one layer of protection between keys and
>>         any novel
>>         >> cryptanalytic breakthrou= ghs. Posting our plain pubkeys on-chain does sometimes have fun
>>         benefits,
>>         >> but the drawbacks are de= adly serious.
>>         >>
>>         >> Until SHA256 collision r= esistance is broken, I'd expect P2MR is probably the pinnacle
>>         of secure PQ
>>         >> address formats, and eve= n then we'd probably end up reimplementing P2MR with some newer
>>         hash
>>         >> function. Hopefully some= day someone proves me wrong, but we can only engineer with what
>>         we know
>>         >> today, and today P2MR se= ems 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 wi= tness discount, so...
>>         >
>>         >>> And with them they w= ill take bitcoin's value...
>>         >>
>>         >> If you're really worried= about a supply glut caused by CRQCs stealing and dumping them,
>>         then
>>         >> debating about P2TRv2 an= d 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 do= n't read the news.
>>         >>
>>         >> If this concerns you (an= d it concerns me too), then saving a few vbytes per spend pre-
>>         Q-day is
>>         >> trivial by comparison, a= nd optimizing it will make little impact on the integrity of
>>         the UTXO set
>>         >> after Q-day. I would ins= tead suggest you pursue the retroactive area of research (rescue
>>         >> protocols, quantum canar= ies, hourglass, exposure statistics, etc). This is a domain
>>         where real
>>         >> impact can be made to mi= tigate 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 maxi= mum possible migration.
>>         >
>>         >
>>         >> Anyways, I appreciate th= e 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 f= avor of P2TRv2.
>>         >
>>         > Fair enough. I continue to t= hink we're talking past each other somewhat but ultimately I
>>         think my
>>         > concern is for ensuring bitc= oin survives, while you're more concerned with giving those
>>         who are
>>         > concerned an option to feel = warm and fuzzy :).
>>         >
>>         >> As to the original subje= ct 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= /32A116B5-22B8-43E9-BD54-EB330C2A1523%40mattcorallo.com.
--Apple-Mail-97FC7308-0020-4792-AAAA-A099A670A969--