From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Apr 2026 08:23:31 -0700 Received: from mail-oa1-f55.google.com ([209.85.160.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 1wD25R-0007VM-OU for bitcoindev@gnusha.org; Wed, 15 Apr 2026 08:23:31 -0700 Received: by mail-oa1-f55.google.com with SMTP id 586e51a60fabf-41c07bdd2a9sf4557786fac.3 for ; Wed, 15 Apr 2026 08:23:29 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776266604; cv=pass; d=google.com; s=arc-20240605; b=CuGOaV2Ncq4uR6o6aVgGl5YUfmqbYTTWKQFPZj5fqzSQZm7IgT2TCKCVr3AeP8uTjA pPpshvgykKvjy3Sz+48CoLEDxq7NGaF5OvVQDSnXqJU/EZDbOGxn6XVClBtoVk3/jOWO 4M4Xv0OZwe1va9YnUEsR3jU3HPHYbBsxvYIEOEf1Ms7yUHAbmFp4V8tybrnaAh+oBZNl yewvzoUCnm9sXoN96oIfseE233MJW3oCi4PoD4rTWcRynLW3V3EQrUhW5i/ZbqoDsD4Y MQhSbM+fLJp2wWJbhBstv+H5vMcESW5tnD+E/cFxkDP4CakTcIUlcfJJ7uPuLm6AdXll SIXA== 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=B861+/HrPYEJmDNzXS5SWz03ILUCHKoRQ7b809pY/Ek=; fh=kTA7scaXnm+9UoWzCaX5QPHz11W7ikyNgRpoRQ0KEqk=; b=lNMkGZCx1q3x4StInFNEyFRPG5cJ4YCz6mkyYiESkc6kA9tyYYPjj7HGyA8jAxYO1K 6UEnLEO6OBCHwPVPaaTFqgGeFUKfMrMbQXYMMq1IJLgxX8j4kPHxzjLF7p4V/gurWLLz rpFmI68sJXR6Tqy4ygIijEssSy0ZEL5IKQ2HVN8yF8YKauLjRjxepymDM+4BXY35NEyB ZpLD3B/3X5kS3sSsvWfIVFYWVlke7n2g04Zcv0G42ThLYg+iIXGSgqNOgncwBVDl7ERE 86TTqHFP45R4KduJ8Fn7sWZlCzN6rhooTKkkvvo4BAEG+4dOSHm4G3tEYBqQPmQT4npQ pKZw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776264063 header.b="kRl/i+kH"; dkim=pass header.i=@clients.mail.as397444.net header.s=1776264065 header.b=cM5Uuhkc; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.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=1776266604; x=1776871404; 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=B861+/HrPYEJmDNzXS5SWz03ILUCHKoRQ7b809pY/Ek=; b=vx/RLCRnHwV6RpwLlGRbduAPGRqI1yV6S7WaXgCAVjr5EEUeztXdVMthIkCkr86Hwu yFYIxeNOGYs0Yw9GSEhcQQQzhB44RoGA1yV43TUFrRwvCgJ+kryTBV+xVrgZf5yBbmOm otXc/HKF2URAAIFtWHd19Fo9PZXj6CIXwCuU4ItPzSPMx6quBAenxUtlurfvXYBD7haJ 0yuy7D3vocFnZv5oFkNm2hyDeNJVMO59CO1ZCXXAmgin2tecgpN4zq/BOL47wkyIaBSk +CJQo2Ru8xd5mWTlGaG4xTSrkHkGN+RIamNBLpf8Nxnxr6XVVg7Dzs6hOanxpb+fJ+X4 fyUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776266604; x=1776871404; 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=B861+/HrPYEJmDNzXS5SWz03ILUCHKoRQ7b809pY/Ek=; b=A5JQhZMe3Jaruy7oBmZtNiMIQ5t+DAUV88TGWVgt8/yjT46BZzBVGf+43vMMstkj9p KonwdVTtwADeaIaRmA7jOjOlOjv4NHFAK7XmECe7SLQGtgqnztvhyufvMNuvN5RbZOxM 4mjmmtTaNYptP4zKCf4Pzt77RV/DJsxOOA8YIDgORDNumLTvIVsd8DShmHANGod2tx0q pR3R1OFU5ISmv6qop4CEzRlRv3+FWTKJyFqoBAvH+vqtcc060MgPgnlOCC8oB3SaZczf 1yHw2gyqeyHEvDoOpLiIpViLmyeTEZdj59wXcvKNNNHvoIuDw6WgyIaYARovSC578Dek xiEQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ8QoLcyXTwn22rAyei0O/s+CUlN0KlSNLZYG3ATMwpC22BM+y9tUUC8J73nVxm8fWKK8DsoM8kkvkDa@gnusha.org X-Gm-Message-State: AOJu0YzuY+dZMlSFzX+Fa3UsBwy9Vmo/8YEKXnPr7e6aJma9mNLX20ma wMxdVtSdkRA0+kr1ZUg/UNY1i5H9sbmVpfrFmqgSIKRuGazgMghV6ZJh X-Received: by 2002:a05:6870:9a89:b0:423:6559:ae5d with SMTP id 586e51a60fabf-423e10f0803mr13394146fac.20.1776266603350; Wed, 15 Apr 2026 08:23:23 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJbts1vUv5WxwEQjO4bmSsKyFfiJ5HdrZpeeOSk/NLYqw==" Received: by 2002:a05:6870:831e:b0:41c:64c3:46be with SMTP id 586e51a60fabf-423dd955f34ls3481940fac.1.-pod-prod-07-us; Wed, 15 Apr 2026 08:23:18 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+YjUpMkpGfAHNMpchacV5ojMEkZsRoeV1CakthItCKjEk3KciiEDqoxEx4x55skbW2ZhBIHAvlirWM@googlegroups.com X-Received: by 2002:a05:6808:1a16:b0:468:8534:e93 with SMTP id 5614622812f47-478a0f1f7cemr11245726b6e.37.1776266598718; Wed, 15 Apr 2026 08:23:18 -0700 (PDT) Received: by 2002:a05:690c:628a:b0:7b3:443:26a9 with SMTP id 00721157ae682-7b7135fd0d9ms7b3; Wed, 15 Apr 2026 08:17:44 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+FQQi/oZD+zj0jdIIoldfAu5oOzz747Ape6L0JfWkNA5Sy5V+FZYD3fWM2400OWEdXegRCEaLk+QL1@googlegroups.com X-Received: by 2002:a05:690e:4853:b0:650:314f:1108 with SMTP id 956f58d0204a3-65198beeacfmr15436620d50.59.1776266264029; Wed, 15 Apr 2026 08:17:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776266264; cv=none; d=google.com; s=arc-20240605; b=PNhlCiWuDt+0wjWC4tIfWBUYBwYjZebCwHcql9EuDdX/0ZhHzlhnY+Hc+Rd+Hz8394 H7aJ8r/kx6spfzTaHng0CbczJJExQa+atkf66gzamrO5iHRmkSBW4i26qvI61hqmi8Su 924c8KrC5fuLxxsQEs5g2v6xvqhwyO4tJFGT1kct95D3/WrUdY564cwen2QhryrB1RiI BK43E7dKCFBOY/to0ssFHN+ELWYRDlZvrEm0B6sL2cA6GC1MG3eMWZuxD5hOSfE8lJiy uCIOfCx4yx02l4srqoC/3M3AoXv4j8JC65NhqDqKwhqdgZ17Ezqdzo4rCsn2ebGvQWaE a+0Q== 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=fXVg0Ohl21yJJnERYyRQu5W2gfrYD5fB+FoN2oLwN/U=; fh=wTvfnnPutYPyC8mS8xtoqTr7VF78o7m+Hg6vypSJAU4=; b=irCOzNWFrZFc/2UqT8gLhwVzq1BTI7APRdzTOw+85w48U9jAMzPmOxZsrx2EdhobWr r53sy7V+0FGzwy01PBlmh4J1U7pi9lGwLZzITDrcxAk7nk90NPOvST4guDaTSXpAANSI ovMPCvmcFwE23Utv6IKF9o323g4vKHritpLLY5SHNqo305/JVhOc+6ITff16Kw72R6+a cF5r5SUu9e/lU6KnnDvUKf23yEd+kk1O5XpP0wEgH6D9ua8xRVbe8mnJfr4IUT4hCFWW hDmZfO+BUSExMklz56jbhba0iikmaLluuv3fnq6o/LpBE79wDaGXF2l58fmjejO4M3rq l+zA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776264063 header.b="kRl/i+kH"; dkim=pass header.i=@clients.mail.as397444.net header.s=1776264065 header.b=cM5Uuhkc; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.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. [69.59.18.99]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-8ae6cb77391si721656d6.4.2026.04.15.08.17.43 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2026 08:17:43 -0700 (PDT) Received-SPF: pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.99 as permitted sender) client-ip=69.59.18.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 1wD1zp-00000005yEu-02xo; Wed, 15 Apr 2026 15:17:41 +0000 Content-Type: multipart/alternative; boundary=Apple-Mail-ED81775B-94AE-497F-8963-0FFC79095C06 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 11:17:29 -0400 Message-Id: <779B3675-93F4-4175-84D2-55B6EA8930B2@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=1776264063 header.b="kRl/i+kH"; dkim=pass header.i=@clients.mail.as397444.net header.s=1776264065 header.b=cM5Uuhkc; spf=pass (google.com: domain of lf-lists@mattcorallo.com designates 69.59.18.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-ED81775B-94AE-497F-8963-0FFC79095C06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Apr 15, 2026, at 10:36, Ethan Heilman &l= t;eth3rs@gmail.com> wrote:

=EF=BB=BF
The proposal is P2M= R 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 fa= llback =E2=80=9Cuntil it=E2=80=99s time=E2=80=9D. This avoids the substanti= al fee and functionality-loss overhead of hash-based signatures =E2=80=9Cun= til it=E2=80=99s time=E2=80=9D.

Yes, of course peo= ple could opt to not do that, but then we=E2=80=99re back to where we start= ed - not solving a useful problem for those who the problem actually impact= s.

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

This is incorrect. 

1. As long as the Schnorr pubkey ha= s not been leaked by the wallet. The wallet is PQ safe.

Right, the context is a =E2=80=9Cnormal=E2= =80=9D wallet which transacts occasionally. A pure receive-only wallet is f= ine but that=E2=80=99s such a narrow use-case I=E2=80=99m not even sure it= =E2=80=99s worth discussing?

2. Even if the Schnorr pubkey has= been leaked by the wallet, if the PQ leaf hash is not publicly known it is= safe against long exposure attacks. 

Huh? If the address is reused as-is (as is the case the m= ost popular Bitcoin wallets today) a CRQC can trivially steal the funds wit= h 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 c= omparing: 

P2MR + P= Q signatures:  A wallet messing up their implementation of PQ safe tra= nsactions and introducing a vulnerability and weakening a subset of outputs= . If implemented correctly 100% of the outputs are safe.

vs. 

P2TR: A design where 100% of outputs are vulnerable even= if the implementation is perfect.

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

No, I=E2= =80=99m comparing a realistic deployment of P2MR for the wallets which are = relevant to the =E2=80=9Cwe should give them maximum time to migrate=E2=80= =9D discussion in a world where they use P2MR to a world without. Yes, ther= e are wallets that would use P2MR =E2=80=9Cright=E2=80=9D, but those wallet= s literally do not matter for a discussion around what we need to get in pl= ace as soon as possible - large custodians who won=E2=80=99t make any mista= kes 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 migrating as soon as possible we=E2=80=99re talking about thin= gs that aren=E2=80=99t going to pay a 10x cost increase and are going to co= ntinue using a single static address.

Matt
On Wed, Apr 15, 2026, 07:02 Matt Corallo <= ;lf-lists@mattcorallo.com&g= t; wrote:
Oh, ap= ologies, I was in a bit of a rush yesterday and forgot the most important r= eason why P2MR
doesn't help at all - address reuse.

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

Matt

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