From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 14 Apr 2026 13:05:51 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wCk17-000606-Vm for bitcoindev@gnusha.org; Tue, 14 Apr 2026 13:05:51 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-423306870bdsf10954628fac.3 for ; Tue, 14 Apr 2026 13:05:49 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776197144; cv=pass; d=google.com; s=arc-20240605; b=eesAta0zA5FPuMc7NmA7rtEwftq36iqeTsoPvsD6yr9Y6HirJfhcEuepjMtHz755II ATrV3T6SWzYKKbXv52n61LiE8tjf0trfTmmnUui38igx0BIaIMYJ9IYMveNMlxaRYd0F k5xi5bZgI3h7bUk68VCStvxNVv+Uv/hf8W10BX6iwLPE9yK1i7PXtTBqgEH16uiy9y9K IncbzU7gp6KLwEjNQbf7PNNO32mwU+IwWLFmX7E95OmC0oJn+2qnoQ3fMkHAU7D8Yfai 4mIDoxo+Gwu/BCE3cxtLCzXMf3E3TDpPhIVR03//9x2uJQHAD2/0gG8oQE7JHmcFIOEF L6Ig== 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=Xls9DT4pujun57TUAdx1BP58p6nXAS2HUqvBLc4xwfQ=; fh=HDtFxe1sJsD/rCOHGJf5xIMzj902FSam+TxxgnbCzdU=; b=GvHbDbW5OD/h3K0qPMbr6e9uSLbXm6Ug6sdTYvqBAxo2R5RaYb4/KGD58Y2BKFUtYM cYumxOrRXe2I12Z4RmTHUaLfaUF6T2s4mIGE0g9MBnmNWPEbk1STqvJJWfWl/jWiU3HL tj4WAZna15N13FrxwnDvdnWgrhbWzbaKkiiK2+IP4ZFS1HA7eCztYCIkgCM0NlLP/isH PHu2LYzXJvnXS/Op6JlluaQZd1gkWoqQAYMrrQoJ5NAiHa9MsLiONpP7WlPx7odVUZfX MagZSwdaXIFaubG+79NITxSbWTkd8UEDMAmzKulwy+dajwy9woGU1oHL8KtNOgMRJb2t QxmA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776195662 header.b=pC5zxIgH; dkim=pass header.i=@clients.mail.as397444.net header.s=1776195664 header.b=Akp1CXoe; 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=1776197144; x=1776801944; 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=Xls9DT4pujun57TUAdx1BP58p6nXAS2HUqvBLc4xwfQ=; b=L42xJzoPXxZRmtlrAmO1UlmR16OWbyJcDTJjboY/B+lnHh7Q3Uxf1jwSVLbhJ+V8T2 9F0Y8cV8+CD1rTD3b7O9gsYxpzR8YvlGvcWENJOBpQEvnZ+osX9ACEHxikwZ48dvUyIg HNyHJLoH94NLiKizIv+9uWEXJ5gqj7AAEdP9KjG9dGFj1WGZDy/8wHCOeIBr5UlQ6hEL LKiydgfPPz3RJlDYMHBNocMJv+e1/YzUDS8W8jQ/En9ag3BXKEURJXO5J4N/1/2lcSxl zhFuQbeyDNT6b2u/bdE01dDKB1H6wl4rsmjuLGx0frgn0+kY/Jg4vV9PaTKJIq//31q3 WBVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776197144; x=1776801944; 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=Xls9DT4pujun57TUAdx1BP58p6nXAS2HUqvBLc4xwfQ=; b=Gd+bEjxvJdyIX5j6SdsE+JA+UojP6EoKsV73CtR2b11oC2hf9Y0qd9pGO+nEc7qfaG xi+bY5qGc/WDMkP0LSeH+iqelIIDfvorsNU8s3oQuUFqQsorU4eumWqzNLpyycVxklV1 fvmjCd0LZqNZTgMfL4fLyvcMrzlOrXfH4oHGTl2fPbzz32eIH9DvamJTWOnb+6GVAFJv uVK7Cqi8ReSiqnrnEFE1atE9tKMyt3UoKuoGsbRUEIzznIN0Qw4GohVPHyXw2pIfFTJ8 +iBlzcMx46DlnItcAfuaMA6MPO0HT4gT5rL2QwuR3q9Zfs93Otf8IOy8ln+JEjnZShjD zOOQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ8e8z9CS7hrcl5xS+sLwjhrang4rRmaa/W7iZ1aooSp9Rwvo5a3yvu+8U1ijQJpCwJcAwGMZaq2ePTU@gnusha.org X-Gm-Message-State: AOJu0Yy2FH/bJL/+1dMdHo7/GfcexGo9VQriCQ24cEqzDSiZEFoAkxOR 1vui2VdtzwTEMQu7a8n5FILEUJzAlHJGm7/Koyhn3rvUB9bByzoNpeNl X-Received: by 2002:a05:6870:ab0d:b0:41c:9c97:21b3 with SMTP id 586e51a60fabf-423e0eb8cc5mr11004732fac.16.1776197143637; Tue, 14 Apr 2026 13:05:43 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKHQLaMgWFHbO9QluummIlFHEVqQOGZCAuLTTTGKu6n/A==" Received: by 2002:a05:6870:d441:b0:422:f32a:6626 with SMTP id 586e51a60fabf-423dd99bcfcls2196582fac.2.-pod-prod-09-us; Tue, 14 Apr 2026 13:05:39 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ+M/LiBkl6Qf2wd+ygtHdbTxATVKr9HzQ0lG+4WI7TJ/PwgrV6e2JF7NvyidLYrA5hM+H6j/nLLiT+y@googlegroups.com X-Received: by 2002:a05:6808:6a83:b0:46a:d8b7:1101 with SMTP id 5614622812f47-478a0307b3emr10998945b6e.41.1776197139245; Tue, 14 Apr 2026 13:05:39 -0700 (PDT) Received: by 2002:a05:620a:2d8c:b0:8cd:90d4:fad8 with SMTP id af79cd13be357-8e33ea5ced2ms85a; Tue, 14 Apr 2026 13:04:08 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ8d4xfvRLbekF7eAroOED1GU/Tf/7ULMHEWr2lYCv2ftbTknVPBE67yzvXYSnldnCDco/c3nIHupT91@googlegroups.com X-Received: by 2002:a05:6122:8483:b0:56f:6add:9029 with SMTP id 71dfb90a1353d-56f6addb153mr3343761e0c.1.1776197047261; Tue, 14 Apr 2026 13:04:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776197047; cv=none; d=google.com; s=arc-20240605; b=E3xFt5V46BMneUM9xjVWpGu0/Cl/h+tlSrske33idUXwUZBdF7/DkNgFCG4+EHmIPI DmlQ6x6fx/bxPWo2uD/PzoikuLbJ2/3MxKDqSXoIjmF2Mh8qHK0YZwuA1VOExhotO9Uc DobK4E5AkTk2j0Xe64SERhIdbvyL9GZswBAaxazijrdQIuMKBdgBD3/PKS4sA6d1fhb9 l6o7U7enKP6TqYaeDik1QpeYRgRA/OCfwtv2dU+MJzGIMZ40uc1RGAMD5oox1Cp8XjT+ ENiAb9PvtnLbcyNPqd46k7RV53t8udYpBCKP1oNktFVs+W3Z4t9/KPMGoclZPs4iSNS8 2kzQ== 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=JUOObUEU7Pm/eSevGvSgJX+sAKg4XUg7oWbUdY6+WAI=; fh=8VGnW6GupFp+E22ewfmp7L0nA8NNaiauNQDEKq5OUV0=; b=UtAuSP2RsgmQf9DqL7N9V8G7eMQX/TWoVrN0g8Ttunb0ViIHLr3aun67acKMDdIKGU 5DXrAEEM9lmMbPwNXzewJ/CoJpuPEiZJtX9QX3dWh1YBTWnHZKWP3kyBZ+nLUcnBToQu k31jiRo8Wb5eOIjuh+sbMb9XylD6ZdjZhIFUHy9jqIEPHxwo/dkPgXO6J8cJRrR7jlVH Ww82gfo9fdje1VcgVKqH3NShsDquSbMrkmIeXFMJTxF+wRrejNu3ZFng5M9Wzgfgz76v mhUK6hrWtX12Ghp2tMubuVHqHors4YHwJblio/oDuaxqTZepPzKskQ8nX2SpKpanagaP 0Nkg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@mattcorallo.com header.s=1776195662 header.b=pC5zxIgH; dkim=pass header.i=@clients.mail.as397444.net header.s=1776195664 header.b=Akp1CXoe; 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 71dfb90a1353d-56f3b6b02edsi505491e0c.0.2026.04.14.13.04.06 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Apr 2026 13:04:07 -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 1wCjzP-00000005otC-3MXX; Tue, 14 Apr 2026 20:04:03 +0000 Message-ID: Date: Tue, 14 Apr 2026 16:04:02 -0400 MIME-Version: 1.0 Subject: Re: [bitcoindev] In defense of a PQ output type To: conduition Cc: Ethan Heilman , Antoine Poinsot , Bitcoin Development Mailing List References: <0vqF88LoOnY4GiUB4vf-MdeZpTAtR70tokS3cLwt2DX0e6_fD1X_wyhPwWEdIdm6R88AULObIU08CWsb5QfeoaM5c4yXPqN5wHyCrqMCtfQ=@protonmail.com> <6wBygQ_pK40ZpU_CMXfzIy-6LkthOmEh-xd2g9bwUl-f8w2K6G4rUWJEssE2zeJgxyipGe2GrFH9y_TUUI48asqfh7dhi9A2rl7NpWyFW1o=@proton.me> <765490aa-5df3-4619-86cc-17570b6d3e99@mattcorallo.com> <6d075872-0db8-4e7b-ac2a-452624c991ad@mattcorallo.com> <42806684-3cc4-42e2-8052-43288a93e91e@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=1776195662 header.b=pC5zxIgH; dkim=pass header.i=@clients.mail.as397444.net header.s=1776195664 header.b=Akp1CXoe; 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 (/) I'm gonna top-post because I think we're too far in the weeds and the high-= level argument is getting=20 lost. No, of course I do not thing that our job is to "convince" any quantu= m skeptics. What is our=20 job is making sure the *bitcoin system* is ready in case a CRQC does become= a reality. That means=20 looking at the system as a whole, not individuals. Notably, this means that= if the decisions we make=20 result in a bitcoin where some people who are super worried about a CRQC ha= ve migrated but everyone=20 else hasn't, and a CRQC becomes an imminent reality, *we've failed*. In suc= h a world, bitcoin=20 becomes largely value-less and the paranoid folks who migrated long ago and= paid for it have=20 accomplished absolutely nothing. I hope we can at least agree on this point= . On 4/14/26 2:56 PM, conduition wrote: > Hi Matt, >=20 >> Right but you didn't contend with my point at all, only ignored it. Its = great that you can move your coins into something so that your coins aren't= stolen but...who cares? If a huge % of outstanding bitcoin supply is being= stolen that impacts you just as much as if your own coins were being stole= n! >=20 > I don't think I ignored anything, but maybe I just didn't understand your= point. >=20 > To me, your point seems to be (I'm summarizing here) that "Nobody will mi= grate to P2MR before Q-day because it is slightly worse than P2TR until Q-d= ay". And your conclusion is, in your own words: >=20 >> 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, et= c. >=20 > This seems to imply you're arguing that at least some of those same peopl= e (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: >=20 > - P2MR is quantum-secure by default. > - P2MR is more efficient long-term. This assumes a CRQC. > - P2MR does not commit us to carrying legacy crypto cruft past its shelf-= life. Nor does P2TRv2? No one is suggesting P2TRv2 becomes some standard that all= wallets use forever. No=20 matter what we do we carry the "cruft" of P2TR in Bitcoin forever (+/-), P2= TRv2 has literally zero=20 additional cruft. > - P2MR and P2TRv2 are both equivalent to quantum-skeptics, who have no in= centive to migrate either way. See below > - The short-term efficiency difference in P2MR and P2TRv2 is a negligible= trade-off to anyone who ISN'T a total quantum-skeptic. > - Fee-sensitive users are online and adaptive, and can use P2TR until Q-d= ay; They do not need P2TRv2 any more than fee-insensitive users. I disagree very strongly with this. This would be true if everyone had thei= r own custom-built wallet=20 that they designed to meet their goals exactly. In the real world people pi= ck wallets based on many=20 other factors, and developers build wallets for many different users, some = of which may be fee=20 sensitive and some of which may not be, all of whom will use the same defau= lt configuration. > - P2MR has utility even if Q-day never comes. I disagree. The overall utility to the Bitcoin system of something like P2T= R is also the global=20 default that is strongly baked in which results in > - Also, I failed to make this point in my last reply: P2MR and P2TRv2 hav= e the same privacy profile AFAICT, assuming both commit to a hash-based fal= lback leaf script. I don't see how this is true in practice. Maybe in a world where everyone u= ses P2MR with a single=20 left-hand leaf at depth one with a single EC schnorr key which is musig2, b= ut....come on. The value=20 of taproot is that its design natively adds this *for free* to every contra= cting protocol, and not=20 only adds it for free but *forces* every contracting protocol to carry at l= east some of the cost if=20 they decline to do this. This results in a massive net privacy win across t= he entire Bitcoin=20 ecosystem, and I don't see how you can argue that these things are equivale= nt in practice, just=20 because they could in theory be used in a way where they are in theory. > Therefore, P2MR is the better long-term choice. >=20 > 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 co= mpromises. Thus, we should deploy P2MR and NOT deploy P2TRv2. Not only do I disagree with most of your points here, but I disagree that w= e should be optimizing=20 for a "long-term design" which we intend to be *the* design we use in the f= ace of an imminent CRQC.=20 We already know we're not doing that - we're not using lattices or isogenie= s or whatever we'll=20 actually end up using because those things aren't ready. They likely will b= e by the time a CQRC is=20 imminent. If they aren't, we'll almost certainly be back to the drawing boa= rd on witness discounts=20 and whatever else which will mandate a new address format anyway. There is = basically zero chance=20 that whatever we do today will be what we end up using "normally" in a worl= d with a CRQC. >> But what about someone who sees quantum computers as 90% FUD that might = happen eventually but won't for 50 years but still gets users nagging them = about it and support for importing some new seedphrase format that derives = a SHRINCS key in addition to the EC ones? That's much less of a straw man a= nd way more realistic - and also a place where someone might do the work (o= r, well, merge a PR if its done for them) but probably won't if they're bui= lding a consumer wallet that is used by some to transact regularly (but, le= t's face it, used primarily by some people who put some money in and then f= orgot about it for five years). >=20 > Very specific. You're talking about wallet developers here, right? Exchan= ges? Bitcoin businesses in general etc? And you're saying that the people r= unning these businesses and building the wallets - those who are being "nag= ged" to implement something that the rest of the cryptographic world has al= ready starting rolling out in production [1] - You're saying that a subclas= s of these people - those who are "mostly" skeptical of quantum hype - WOUL= D implement P2TRv2, but WOULDN'T implement P2MR? >=20 > It's debatable how big that subclass would be, especially given the curre= nt landscape. I don't think this is "very specific" at all? In fact I think this is the *= dominant* case. By coin=20 volume, yes, the biggest wallet is Coinbase's custody product. By wallet co= unt, the biggest wallet=20 is probably something like Trust Wallet. Its trash, doesn't care about Bitc= oin, makes many terrible=20 design decisions which are actively hostile to its users, and yet they are = the ones who actually=20 decide in what way most bitcoin are stored! I don't know what their particu= lar view on quantum is,=20 but my sense of most developers is that the view is generally "well, it'll = happen at some point, but=20 its not totally urgent". Meanwhile, people are almost without question goin= g to nag some wallets for=20 "quantum security" once its a thing. You might reasonably disagree with whether they would implement P2TRv2 vs P= 2MR, I think its=20 definitely a subtle argument, but I don't think you can reasonably disagree= that these are exactly=20 the most important constituent here. > But even if one confidently sees CRQCs as 50 years away, then I'd refer = back to my earlier=20 response, and argue that any such skeptical developer has no reason to impl= ement either P2MR or=20 P2TRv2 today, apart from compatibility with other software which DOES imple= ment them. If "nagging"=20 is the only motivation a dev or business owner has to implement a PQ output= type, then one need not=20 distinguish between the two. They'd just implement whatever is standardized= to please their users,=20 and carry on with their day.> > If I'm being a little more realistic, most wallet devs will follow whatev= er 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." >=20 > I think this reveals the source of our disagreement. In your arguments, y= ou are placing a lot of weight on the importance of pre-quantum fee-efficie= ncy in the new output type, so much so that you seem to think devs would wi= llingly ignore a potential existential threat to save users a few sats per = transaction. It is far from only "pre-quantum fee-effeciency", its also the value for th= e entire Bitcoin system=20 of the privacy taproot offers. But I think the more important argument spec= ifically here is the=20 question of what they will make the *default*. In a world with P2MR I could= absolutely see them=20 implementing a P2MR option which you can opt into in the settings. That fai= ls to accomplish our=20 goals entirely. Maybe they also would do the same for P2TR/P2TRv2, but I at= least think that's=20 somewhat less likely, but in any case better for the bitcoin system overall= if that's where we land. > But maybe look at it this way: >=20 > - 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 act= ively transacting pre-Q-Day, and use P2MR for high-security cold storage. T= he result is mostly the same as if we deployed P2TRv2. Yes, there is some r= isk 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 cor= rectly. > - Mining fees are a part of everyday life for Bitcoiners, and the pre-qua= ntum fee difference between P2TR and P2MR is NOTHING compared to the fee sp= ike 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 op= timize. >=20 >> Again, you ignore that the impact is global, not local. Yes, quantum-ske= ptics have to be brought along over time if you want to have any hope of bi= tcoin actually being relevant. >=20 > 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 pr= epare an optimal migration path in case the threat is real. If CRQCs do app= ear, 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). >=20 > Even if you feel your job IS to convince and migrate as many users as pos= sible, I would argue it'll be hard to convince anyone to migrate to an addr= ess format that isn't PQ-safe by default. Bitcoiners trust code, not promis= es, and P2TRv2 is only PQ-safe if you trust its promise of a future soft fo= rk, while its code would be PQ-vulnerable by default. And the only benefit = to accepting this risk seems to be a trivial discount in fees pre-Q-day. I = don't speak for everyone of course, but personally I'd rather keep my cold-= storage coins on a P2WSH address than on P2TRv2, because at least then I kn= ow for sure a CRQC will have a hard time stealing my coins regardless of wh= at upgrades the community does or doesn't deploy in the future. See intro. I don't really see how you can reasonably conclude that our goal= is only to enable a=20 small subset of people to migrate. That way leas only to a total failure of= the bitcoin system. >> Sure, but any short term hash-based signature migration path is really n= ot intended as the final state anyway - if Bitcoin is stuck with only hash = based signatures and a CRQC exists in 20 years that's a pretty terrible out= come. Hopefully by the time a CRQC becomes a real threat we have much more = confidence in lattice-based systems (or whatever PQC is popular then) and w= e can add whatever output type makes sense at that point. >=20 > 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 wou= ld argue P2MR remains useful regardless of the cryptography we use: lattice= , isogeny, hash-based, multivariate, whatever. Merkle trees have been aroun= d for almost 50 years and seem hard to beat. >=20 > For instance, we could reconstruct P2TR using isogenies [2], but would we= really want to? Using today's witness discount levels, it would actually b= e 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-supersi= ngular-curve" output type [^3]. I realize I'm kinda trashing my own researc= h by saying this, but it shows how hard it is to beat P2MR, even if you can= accept new cryptographic assumptions and the accompanying performance pena= lties. Yes, we probably would. Not because of efficiency but because a goal of tap= root is *privacy* while=20 offering efficiency for the common (all-sign) case. That is generally true = across contracting=20 protocols and makes things net-cheaper with a taproot-style system where yo= u hit the common case=20 often. This is another reason why P2MR is quite a loss - > Even if we do someday find some novel cryptosystem which permits rerandom= ization, and we design a new output type as efficient and performant as P2T= R 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 decad= es or centuries need to pass for everyone else to share that confidence? >=20 > 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 al= ways have at least one layer of protection between keys and any novel crypt= analytic breakthroughs. Posting our plain pubkeys on-chain does sometimes h= ave fun benefits, but the drawbacks are deadly serious. >=20 > Until SHA256 collision resistance is broken, I'd expect P2MR is probably = the pinnacle of secure PQ address formats, and even then we'd probably end = up reimplementing P2MR with some newer hash function. Hopefully someday som= eone proves me wrong, but we can only engineer with what we know today, and= today P2MR seems the most optimal conservative option for long-term securi= ty and cryptographic agility. As mentioned above if we end up in this situation we're almost certainly go= ing to be discussing a=20 P2MRv2 with an additional witness discount, so... >> And with them they will take bitcoin's value... >=20 > 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, m= ost 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 ha= nds who just don't read the news. >=20 > If this concerns you (and it concerns me too), then saving a few vbytes p= er spend pre-Q-day is trivial by comparison, and optimizing it will make li= ttle impact on the integrity of the UTXO set after Q-day. I would instead s= uggest you pursue the retroactive area of research (rescue protocols, quant= um canaries, hourglass, exposure statistics, etc). This is a domain where r= eal impact can be made to mitigate the risk of a supply glut when/if CRQCs = appear. Opportunities abound. We would be glad of the help :) This is fair, and we should do this too, but I don't see how it implies we = should not also be=20 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 pre= tty clearly and I feel it is as convincing as I can make it. I'd be happy t= o 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=20 concern is for ensuring bitcoin survives, while you're more concerned with = giving those who are=20 concerned an option to feel warm and fuzzy :). > As to the original subject of the email thread, and Antoine's original po= ints, 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/= ba187dd7-6181-43e0-831a-6580d2c93433%40mattcorallo.com.