From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Apr 2026 09:30:22 -0700 Received: from mail-oo1-f64.google.com ([209.85.161.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 1wD388-000831-Vu for bitcoindev@gnusha.org; Wed, 15 Apr 2026 09:30:22 -0700 Received: by mail-oo1-f64.google.com with SMTP id 006d021491bc7-686e8d94970sf14116341eaf.1 for ; Wed, 15 Apr 2026 09:30:20 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776270615; cv=pass; d=google.com; s=arc-20240605; b=IWTGC6uffwiT15mjLIfSX9cxcMqQX2l3ZU9yFKM4LwUsEbvCp9zu31siTzAAN/LENN IUEQ4/AzO/N935zHGP/YX8dO/nyn5J7LFouboa0m+S0qnbSWHIHx7au5A8IbP3PAS8ds nMJkjpo/SZu9nAPROF3b3rGriaA7noqroksRijIYs6PBMm174QvVQIHAvxAsa19hJJM8 M8nxTe8mpNZpTHj0NSDoSGGqSmRMwUApi14yz/ObYqXXjvECPwyaTzErZoLghCmkYlOw WZa1EOlfU0qOZQX6P9RqTtvdtShSSN/X+3sK54JAmShjHftHgFmHBK0biCbxElLpS0+I zXLQ== 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:content-transfer-encoding :in-reply-to:from:content-language:references:cc:to:subject :mime-version:date:message-id:sender:dkim-signature; bh=oa/0TxCIBzlpUlweM98uYXHyNo63xsWE2TOOEZLj7NQ=; fh=Bur91VCQ+EmxDuwaTrf2AUp4nm8kc4HsVvt7Lb1afhM=; b=Ef+vZ60G/oVlBXDH7OqkhUo33cfbh1ryZNTZW2/HruH5G/sciCMjbn0GR7unQwomA4 DUkfl4MIClhOpc51uxuR7ovRK57fqLdCo0J6sgsqDz8ucpf/1MtTLu3mfK26q6cKayE3 xsr7oGmZs5gwBWS4xP9e5Y/E1R5Req9tEaN9XA8AIs5i8pCQ6NUZBiqJdP/eKwkhJFJO mXHZJWcH0eZCMg/wqF4chZtAG0JpA3bWzGZsNo057C8VACj4hpjn4yu8doUk7RA0c2U8 dmX8uzA+sYZq+7cfCw/HRDTUSdBgiTWEPvPVvrKQvhLgrcgsQfobXCTGU3mAxBp+Gupj Y8mQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776267662 header.b=TnD19jSe; dkim=pass header.i=@clients.mail.as397444.net header.s=1776267664 header.b=pa6va50v; 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=1776270615; x=1776875415; 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:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=oa/0TxCIBzlpUlweM98uYXHyNo63xsWE2TOOEZLj7NQ=; b=LlALCMBiwJZHmMh2mOSCtrM4ZvFH5bzOO4WazP/Su9jGHzKxxhZRaed7Ua7fU5oMWc thkvSieyOSzyR/D83xbrbRXMv4763A1abQJigT4txu0YL8dNj1EsynxlBi+nBS5SpL+k 6KrSt3+96bp1h1gqedCVS3XHIsd2JT/D42fQnu7nGR1we512TM2/XW1M494Q0xO8+9Wn 6LeViJZhVO07y35OfLaq7qrwZhYyuRaQYFfuNPX7dw+Fv05dr+JD6iL9awJU+cwjuATi pOvr0R2pOR5kEDuWW3ze4bLi38GjU86n4s09RFPcpZZokzFKrEFPQm17+4APsjD7Z2Pt 762Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776270615; x=1776875415; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:mime-version:date :message-id:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=oa/0TxCIBzlpUlweM98uYXHyNo63xsWE2TOOEZLj7NQ=; b=qCiHIj2CfpsarmVv/pPQ70r25jjE70E6bW9FE1kOUdzFD/T5Kpoi8ZzvkdmL5BcLvJ JFlsWXV2m/Wk/9Aw6hE/mimWmkASLexcOhifJ7mA8wzRnaKFmbtC6BbRTHxAWFfhke29 6sk8PhM9ghFgHV2ZGJWjEuJZVBst3uuXLwCm5sQBlDVSZ7zzsI6/zszNXmKFwmYeyPmd 2UBuyYbI3E2V+dZ/g8+zLuyw57G19ESha+Pg84ijYEpIaWEZPdNxSRixefFgZPIPkHHA bum/6S6b72zYNHlS+YdAY6zCGAXmn22htTdZ/R0n3Kgz5IoeDVl/J3fgCpwX0aebjH+I E1jQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ/HClswjI3K9+xMLNDuQ5a2ZLaWiJJt16RjfA8xN/Wdq93dVpaivzlEmNDdyRbXE5PzumMQLLziP5Ul@gnusha.org X-Gm-Message-State: AOJu0Yz3JBuL9Oy67bRDp3lcXwqy325B3qjEOhFnIeYLVcRARmyDYFbW CGIOeF2uJJmR/lNCuM90yt4KuLn3CETJFO1VZ+ORGEMelVB6QVUYnBW0 X-Received: by 2002:a05:6820:3007:b0:67e:3028:8bc with SMTP id 006d021491bc7-68be8cd85demr8462976eaf.57.1776270614710; Wed, 15 Apr 2026 09:30:14 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiJ21L2jU5MJWme8Kqt0WrVs9CyrTJz53uNZ4+7uF06CUw==" Received: by 2002:a05:6870:e38c:b0:422:c0f1:a9fa with SMTP id 586e51a60fabf-4280bdac137ls19058fac.0.-pod-prod-07-us; Wed, 15 Apr 2026 09:30:10 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ9gnafPcLO7jOiFJLyUuCPfV9BbNDw0qVc8tH50Z+H6p3PRxM3B6r1qOjvdPXa1MK7d4LIu6W9z/piN@googlegroups.com X-Received: by 2002:a05:6808:17a2:b0:466:f60b:19d5 with SMTP id 5614622812f47-4789e71dd50mr12309021b6e.8.1776270610526; Wed, 15 Apr 2026 09:30:10 -0700 (PDT) Received: by 2002:a05:6808:858e:b0:467:52e4:df4a with SMTP id 5614622812f47-47974425891msb6e; Wed, 15 Apr 2026 09:03:29 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ80DE5NNmjkxMU8u/N80oCwUg92bBfHs3LYef8awUkvAtfT/4TuV4BiDeqXvu3bFbghsv28A8FMq2XH@googlegroups.com X-Received: by 2002:a17:903:288:b0:2ae:46b9:c653 with SMTP id d9443c01a7336-2b2d5a43e92mr229349425ad.33.1776269007442; Wed, 15 Apr 2026 09:03:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776269007; cv=none; d=google.com; s=arc-20240605; b=J9neinW3VvYW0P+UQ7GsUssmYuC4ZhIXJ9+iOLIDFxNE0Cwc5L2ma+LmHYCXV5DczW /tbVNv6KJd823Tvxv1nCDdmxEEYxcKrTrOYRsX/eXF7ygWmTKOUzOxzLvEuII+wZtT7B JfKPdRx+w6VEYQ2T5iwFfCjG1qkojHKLSYsyOmtY2xCewMlfIvmAK6DnXJ7O7g9llK4t VFaxlKeETGO+NmgA3d2rEff1cRHgQ7mZNLHxkq0AuvZdwAdy53OEuNpaTdmjguYTae4b Omch+/eYs73Hf5jWdTuLfYw0lpn9MqClXDgrWaq4vMy1yRX3tBuMlTUYMLKwX6IQ/F5S Kxfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:mime-version:date:message-id :dkim-signature:dkim-signature; bh=ITO3w4IVCpaUSe1FllTjPtCUpm43G3u9cVHiOVlMiuI=; fh=biCrrFUzwrk+s8uyLKz6iBSvFYsjRxTUJ8jpnJ9DprI=; b=QnPv6aeoM/m7aM3LkM6OXj7YszicPaLoRhijlBzd1l5MarR0d2UYZvSXjty81Ew1zx nD4quwjiRT0VOITe+pBsQ7Bw5z8B8ZvOZPErKkrSsGqxTsaqwigM2w0oFxiJBerebizy K4cjgFOV/U6MS9cdellK0Px1Wd7NW9Ug6zfKPc6njhWkP2BpbM6PnOaan2zbFv+97iLf gMD5/9MArwjKh3OdkMhSFg8q/X/pN39V2f/PLzqt46Om1oIcwPMRjIngdR8JZFnYxnQj p6ELPTTCW38zZqxxU/SESihhychP+1fa7sIsrvrAM7jWLXR50LiPg4FszYa2tBSopKqr 4yeA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776267662 header.b=TnD19jSe; dkim=pass header.i=@clients.mail.as397444.net header.s=1776267664 header.b=pa6va50v; 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 d9443c01a7336-2b4780f0797si774465ad.2.2026.04.15.09.03.27 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2026 09:03:27 -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 1wD2i4-00000005yfw-2g6N; Wed, 15 Apr 2026 16:03:24 +0000 Message-ID: <51cd9663-4ff8-4534-8622-ede77e190021@mattcorallo.com> Date: Wed, 15 Apr 2026 12:03:23 -0400 MIME-Version: 1.0 Subject: Re: [bitcoindev] In defense of a PQ output type To: Ethan Heilman Cc: conduition , Antoine Poinsot , Bitcoin Development Mailing List References: <779B3675-93F4-4175-84D2-55B6EA8930B2@mattcorallo.com> Content-Language: en-US From: Matt Corallo In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Original-Sender: lf-lists@mattcorallo.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776267662 header.b=TnD19jSe; dkim=pass header.i=@clients.mail.as397444.net header.s=1776267664 header.b=pa6va50v; 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: -0.8 (/) Yes, that is what I'm thinking of. Specifically as deployed by a wallet tha= t reuses a single address=20 for ~all transactions, as those are the "marginal" wallets which we want to= encourage to move (see=20 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=20 > leaf or a PQ leaf. Is that not what you mean? >=20 > On Wed, Apr 15, 2026, 11:17 Matt Corallo lists@mattcorallo.com>> wrote: >=20 >=20 >=20 >> On Apr 15, 2026, at 10:36, Ethan Heilman > wrote: >> >> =EF=BB=BF >> The proposal is P2MR with PQ sigs and no Schnorr address reuse. Addr= ess reuse in this setting >> should be treated as security vulnerability. >=20 > 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 signatu= res =E2=80=9Cuntil it=E2=80=99s time=E2=80=9D. >=20 > Yes, of course people could opt to not do that, but then we=E2=80=99r= e back to where we started - not > solving a useful problem for those who the problem actually impacts. >=20 >> > As such, P2MR with a EC-based key for short-term efficiency reason= s 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. >=20 > Right, the context is a =E2=80=9Cnormal=E2=80=9D wallet which transac= ts occasionally. A pure receive-only wallet > is fine but that=E2=80=99s such a narrow use-case I=E2=80=99m not eve= n sure it=E2=80=99s worth discussing? >=20 >> 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.=20 >=20 > 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= ? >=20 >> P2TR is **always** vulnerable to short and long exposure attacks. Th= ere is no better wallet >> hygiene that can fix this. >> >> You are comparing: >> >> P2MR + PQ signatures:=C2=A0 A wallet messing up their implementation= of PQ safe transactions and >> introducing a vulnerability and weakening a subset of outputs. If im= plemented correctly 100% >> of the outputs are safe. >> >> vs. >> >> P2TR: A design where 100% of outputs are vulnerable even if the impl= ementation is perfect. >> >> These aren't the same thing at all, nor do they provide the same sec= urity.=20 >=20 > No, I=E2=80=99m comparing a realistic deployment of P2MR for the wall= ets which are relevant to the =E2=80=9Cwe > should give them maximum time to migrate=E2=80=9D discussion in a wor= ld 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 a= s possible - large > custodians who won=E2=80=99t make any mistakes with their cold storag= e are just as capable of making no > mistakes later as they are today. >=20 > For the actual wallets that we want to get migrating as soon as possi= ble we=E2=80=99re talking about > things that aren=E2=80=99t going to pay a 10x cost increase and are g= oing to continue using a single > static address. >=20 > Matt >=20 >> 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 noted = 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 st= atic and does not change. >> As such, >> P2MR with a EC-based key for short-term efficiency reasons has t= he 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 "convinc= e" any quantum skeptics. >> What is our >> > job is making sure the *bitcoin system* is ready in case a CRQ= C does become a reality. >> That means >> > looking at the system as a whole, not individuals. Notably, th= is means that if the >> decisions we make >> > result in a bitcoin where some people who are super worried ab= out a CRQC have migrated >> but everyone >> > else hasn't, and a CRQC becomes an imminent reality, *we've fa= iled*. In such a world, >> bitcoin >> > becomes largely value-less and the paranoid folks who migrated= long ago 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 igno= red it. Its great that you >> can move >> >>> your coins into something so that your coins aren't stolen b= ut...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 und= erstand your point. >> >> >> >> To me, your point seems to be (I'm summarizing here) that "No= body 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 minim= al 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 thos= e same people (who >> wouldn't use P2MR) >> >> WOULD migrate to P2TRv2, because it is exactly as good as P2T= R until Q-Day. >> > >> > Yes, exactly. >> > >> >> I respectfully disagree with this argument, and I gave my rea= soning 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 pas= t its shelf-life. >> > >> > Nor does P2TRv2? No one is suggesting P2TRv2 becomes some stan= dard that all wallets use >> forever. No >> > matter what we do we carry the "cruft" of P2TR in Bitcoin fore= ver (+/-), P2TRv2 has >> literally zero >> > additional cruft. >> > >> >> - P2MR and P2TRv2 are both equivalent to quantum-skeptics, wh= o have no incentive to >> migrate either >> >> way. >> > >> > See below >> > >> >> - The short-term efficiency difference in P2MR and P2TRv2 is = a negligible trade-off to >> anyone who >> >> ISN'T a total quantum-skeptic. >> >> - Fee-sensitive users are online and adaptive, and can use P2= TR 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 ever= yone had their own custom- >> built wallet >> > that they designed to meet their goals exactly. In the real wo= rld 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 t= he same default configuration. >> > >> >> - P2MR has utility even if Q-day never comes. >> > >> > I disagree. The overall utility to the Bitcoin system of somet= hing 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 an= d 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 whe= re everyone uses P2MR with >> a single >> > left-hand leaf at depth one with a single EC schnorr key which= is musig2, but....come >> on. The value >> > of taproot is that its design natively adds this *for free* to= every contracting >> protocol, and not >> > only adds it for free but *forces* every contracting protocol = to carry at least some of >> the cost if >> > they decline to do this. This results in a massive net privacy= win across the entire >> Bitcoin >> > ecosystem, and I don't see how you can argue that these things= are equivalent in >> practice, just >> > because they could in theory be used in a way where they are i= n theory. >> > >> >> Therefore, P2MR is the better long-term choice. >> >> >> >> If we assume Bitcoin will survive long into the future after = CRQCs appear, then we >> should favor >> >> the best long-term design choices over short-term compromises= . Thus, we should deploy >> P2MR and NOT >> >> deploy P2TRv2. >> > >> > Not only do I disagree with most of your points here, but I di= sagree 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 lattice= s or isogenies or whatever >> we'll >> > actually end up using because those things aren't ready. They = likely will be by the time >> a CQRC is >> > imminent. If they aren't, we'll almost certainly be back to th= e drawing board on witness >> discounts >> > and whatever else which will mandate a new address format anyw= ay. There is basically >> zero chance >> > that whatever we do today will be what we end up using "normal= ly" 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 i= t and support for >> importing some new >> >>> seedphrase format that derives a SHRINCS key in addition to = the EC ones? That's much >> less of a >> >>> straw man and way more realistic - and also a place where so= meone 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, r= ight? Exchanges? Bitcoin >> businesses >> >> in general etc? And you're saying that the people running the= se 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] - Yo= u're saying that a >> subclass of these >> >> people - those who are "mostly" skeptical of quantum hype - W= OULD implement P2TRv2, but >> WOULDN'T >> >> implement P2MR? >> >> >> >> It's debatable how big that subclass would be, especially giv= en the current landscape. >> > >> > I don't think this is "very specific" at all? In fact I think = this is the *dominant* >> case. By coin >> > volume, yes, the biggest wallet is Coinbase's custody product.= By wallet count, the >> biggest wallet >> > is probably something like Trust Wallet. Its trash, doesn't ca= re about Bitcoin, makes >> many terrible >> > design decisions which are actively hostile to its users, and = yet they are the ones who >> actually >> > decide in what way most bitcoin are stored! I don't know what = their particular view on >> quantum is, >> > but my sense of most developers is that the view is generally = "well, it'll happen at >> some point, but >> > its not totally urgent". Meanwhile, people are almost without = question going to nag some >> wallets for >> > "quantum security" once its a thing. >> > >> > You might reasonably disagree with whether they would implemen= t P2TRv2 vs P2MR, I think its >> > definitely a subtle argument, but I don't think you can reason= ably disagree that these >> are exactly >> > the most important constituent here. >> > >> >=C2=A0 > But even if one confidently sees CRQCs as 50 years awa= y, then I'd refer back to my >> earlier >> > response, and argue that any such skeptical developer has no r= eason to implement either >> P2MR or >> > P2TRv2 today, apart from compatibility with other software whi= ch DOES implement them. If >> "nagging" >> > is the only motivation a dev or business owner has to implemen= t 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 f= ollow whatever is >> standardized just >> >> to get more market share. I somehow doubt devs will turn up t= heir noses and say "it's not >> >> efficient enough, I won't implement that even if a large chun= k 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 existen= tial threat to save users >> a few sats >> >> per transaction. >> > >> > It is far from only "pre-quantum fee-effeciency", its also the= value for the entire >> Bitcoin system >> > of the privacy taproot offers. But I think the more important = argument specifically here >> is the >> > question of what they will make the *default*. In a world with= P2MR I could absolutely >> see them >> > implementing a P2MR option which you can opt into in the setti= ngs. That fails to >> accomplish our >> > goals entirely. Maybe they also would do the same for P2TR/P2T= Rv2, but I at least think >> that's >> > somewhat less likely, but in any case better for the bitcoin s= ystem 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 tran= sacting pre-Q-Day, and use >> P2MR for >> >> high-security cold storage. The result is mostly the same as = if we deployed P2TRv2. >> Yes, there is >> >> some risk of being caught with your pants down on Q-day, but = the same is true of P2TRv2 >> because we >> >> might not time the key-spend disabling follow-up fork correct= ly. >> >> - 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 actu= ally being relevant. >> >> >> >> Our job is not to proselytize and convince people that the qu= antum threat is real, nor >> is it even >> >> to encourage migration by design. Our job is to prepare an op= timal migration path in >> case the >> >> threat is real. If CRQCs do appear, everyone will want to mig= rate 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 for= mat that isn't PQ-safe by >> default. >> >> Bitcoiners trust code, not promises, and P2TRv2 is only PQ-sa= fe if you trust its >> promise of a >> >> future soft fork, while its code would be PQ-vulnerable by de= fault. And the only >> benefit to >> >> accepting this risk seems to be a trivial discount in fees pr= e-Q-day. I don't speak for >> everyone >> >> of course, but personally I'd rather keep my cold-storage coi= ns 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 fut= ure. >> > >> > 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 tot= al 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 sign= atures and a CRQC exists >> in 20 years >> >>> that's a pretty terrible outcome. Hopefully by the time a CR= QC 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 P= 2MR remains useful >> regardless of the >> >> cryptography we use: lattice, isogeny, hash-based, multivaria= te, 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 ef= ficient overall to spend >> with SQIsign >> >> inside a P2MR tree, than it would be to use SQIsign to key-sp= end with some hypothetical >> "Pay-to- >> >> supersingular-curve" output type [^3]. I realize I'm kinda tr= ashing my own research by >> saying >> >> this, but it shows how hard it is to beat P2MR, even if you c= an accept new cryptographic >> >> assumptions and the accompanying 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 ge= nerally true across >> contracting >> > protocols and makes things net-cheaper with a taproot-style sy= stem 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 perm= its 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 t= he entire witness? If so, >> how many >> >> decades or centuries need to pass for everyone else to share = that confidence? >> >> >> >> Personally I think we should learn our lesson from this P2TR = debacle, and encourage >> users to hide >> >> public keys behind hash functions from now on, and to bolster= riskier algorithms with >> hash-based >> >> fallback keys, so that we always have at least one layer of p= rotection between keys and >> any novel >> >> cryptanalytic breakthroughs. Posting our plain pubkeys on-cha= in does sometimes have fun >> benefits, >> >> but the drawbacks are deadly serious. >> >> >> >> Until SHA256 collision resistance is broken, I'd expect P2MR = is probably the pinnacle >> of secure PQ >> >> address formats, and even then we'd probably end up reimpleme= nting P2MR with some newer >> hash >> >> function. Hopefully someday someone proves me wrong, but we c= an only engineer with what >> we know >> >> today, and today P2MR seems the most optimal conservative opt= ion for long-term security >> and >> >> cryptographic agility. >> > >> > As mentioned above if we end up in this situation we're almost= certainly going to be >> discussing a >> > P2MRv2 with an additional witness discount, so... >> > >> >>> And with them they will take bitcoin's value... >> >> >> >> If you're really worried about a supply glut caused by CRQCs = stealing and dumping them, >> then >> >> debating about P2TRv2 and P2MR is a distraction. IMO, most co= ins 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 imp= act on the integrity of >> the UTXO set >> >> after Q-day. I would instead suggest you pursue the retroacti= ve 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 i= t implies we should not >> also be >> > concerned with ensuring maximum possible migration. >> > >> > >> >> Anyways, I appreciate the good-spirited debate, but to save m= yself time I don't think I'll >> >> continue replying. I've laid out my argument for P2MR pretty = clearly and I feel it is as >> >> convincing as I can make it. I'd be happy to acknowledge any = misunderstanding I may >> have had about >> >> your earlier points in favor of P2TRv2. >> > >> > Fair enough. I continue to think we're talking past each other= somewhat but ultimately I >> think my >> > concern is for ensuring bitcoin survives, while you're more co= ncerned 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/= 51cd9663-4ff8-4534-8622-ede77e190021%40mattcorallo.com.