From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 14 Apr 2026 12:02:26 -0700 Received: from mail-oa1-f63.google.com ([209.85.160.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wCj1l-0005CJ-9F for bitcoindev@gnusha.org; Tue, 14 Apr 2026 12:02:26 -0700 Received: by mail-oa1-f63.google.com with SMTP id 586e51a60fabf-4236c3b8f32sf11678556fac.0 for ; Tue, 14 Apr 2026 12:02:25 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776193339; cv=pass; d=google.com; s=arc-20240605; b=g9VSGAI8CFRjkuuiZ79YcG0dczWU0a8omW5jUfDwJrFKrQIN5QhlI+eZGP8b5KeyqU WQ0bDI0wgnzH4MXaXmAPZs/FoLKmCcm9dBdE6em59+npPbKGPkdVjwV+vKwqtOqr8Uuf EutDFeX91+lnxaLMEBBm8xO//NI+PzrSC5fN/J/eDt0ssbiJE97Z1RpqeuUxcrP3OvvH PSJ1FdFijOX6/ZFP5fKFgcjmY4YL2pen++wcNQR3l2o0hVyeRg27yFY/ZzYH2T3dFUrV 5KRc+kwWaXVYYMP2UCYKNOPN95FI0/BhyGp5/cF08GADAhcc1IRVRwk2fgNGl+jpfMVJ XiCA== 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:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=9lxn/bXS10lMnSBkBhgcdLOr7/GcJaDzP/o+9JO2h54=; fh=f1NZ6rSOxAif1PBJkKW4USzGxwJurfwJtFSGxlmf4OU=; b=FWTx5pSRisShCM3ob9sZFdN0tQ4XBIO3XtvaV14lw9Ba5IaIRBBZKgv6COR3mIBTSn 4GrSiX1bMEQHtSN74ouujSo5bc63RZQjlVTbkeTXdNjKGY7EWWdvzoBiuuHkONCF4ryY adrahELwhUuyY4xuGcRO7fWwtU5mJ7jjxpNkyC/Cr5CFuxi86lXelHLA8jFvlLHer+nj GNieqUyaNbTjbY1LrtHDJzk6MoLQuqOGtz0nSsDrTieHu+Us6qJR2+lK6i8qCM41Ns49 iPMXPv0QfAJlJt1bORR7HVEF26FDKNteyoqD5aRthcbYiWEasC4u8Rv2ghpv2upi663+ jYWw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=YE3K+jQ9; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.19 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776193339; x=1776798139; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=9lxn/bXS10lMnSBkBhgcdLOr7/GcJaDzP/o+9JO2h54=; b=bqerev+GhicalqRE3N7ZVw0WS79Ikg4hullnp8SIOXHsMhB4IS1IccH9/vl3J06vA2 XoK+0zOaM3nlOZxDnJNDurqnakNsbnxeWG2d/CXTJzuJyoMVxqGfkTBMN4tqH8qP5mY8 LZlm3/b11paoexIRphL0F4BWdz1LinMQGtqXkaVll5KGrLsP+bNrPKihoWvgODnSdIqo e3mLuNFWvWMvjTU5wJBxPJVck4YvmKBxrfVqT4iuomVjh/USIuCZT1RJVKhuT0iG21YO byR+nmHko17gzG4gluFkHbvZbh+Py/4zUY9su/VC2wWaxrZ1lEIVTO0w1GN7tmBGUJBH /ibw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776193339; x=1776798139; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=9lxn/bXS10lMnSBkBhgcdLOr7/GcJaDzP/o+9JO2h54=; b=mCZNN0N8wWpznE/84yUSg3flCRA10fHkGeqgF7M9l3D7SECcrE+3CGRLlvzchHx5M1 V7c8uC2PUrEgpBIAb9soBGsoychk893oEpRnMYDQMU5/gZM7GFmOUfhOCks523pvshK7 jmwoULr/ydToToAw/ku6CSgh27yRvbBcr3yIFLdpeu1wsJutmP1YGyhEFUa0gyiEpUdZ Jo/S+PyeaGXEUXEGtUn+9+i8+lkljHDHIwumP8U5WAqS+iC+VCF5ynqtasQxLrxaZNEM atfra8zDEPVhNFwweihYuj5KrHqRUSfdCEm0zwc68vuxG6UVYjdVjPFl47dEqzSdZaDt 9C1g== X-Forwarded-Encrypted: i=2; AFNElJ9y5NB5mQ7YYO86kforeGbJc5ob8uoh89gghmqWuWZmzR0RzNIP6PCYrUWvZWSCd3sGQREGkcyJdN66@gnusha.org X-Gm-Message-State: AOJu0YzB76ZJXlj73021T6VVukxoPIjoO4nxXo/8BRWlr6F+t5VyWGtw OxhJQRCLZIclDXiMoS0OM5b10Fl8OxNhoMy1Q0te+oab8di7LK37Q2cl X-Received: by 2002:a05:6870:3263:b0:404:1843:e5bf with SMTP id 586e51a60fabf-423e1e97c11mr9714113fac.18.1776193338379; Tue, 14 Apr 2026 12:02:18 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiIrnbHY5RibvAGlbxOFMTh0Ze1+GPPE9jwuVx0Lk6HveA==" Received: by 2002:a05:6870:8dcf:b0:41c:6a62:2ef1 with SMTP id 586e51a60fabf-4246f10f9e2ls45658fac.2.-pod-prod-00-us-canary; Tue, 14 Apr 2026 12:02:14 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ9ER0VmmgDny4gEwM+Hjg5fz4Ovr2uSGhtpjYHyR9D9glqdDEuPKHE61YxSJ0oU7LGKkSRQyvBPRIZF@googlegroups.com X-Received: by 2002:a05:6808:3a13:b0:467:697:7bbf with SMTP id 5614622812f47-478b37b79d3mr8362890b6e.0.1776193334104; Tue, 14 Apr 2026 12:02:14 -0700 (PDT) Received: by 2002:ab3:6544:0:b0:2f4:51e0:7d3e with SMTP id a1c4a302cd1d6-2f72e3499c1msc7a; Tue, 14 Apr 2026 11:56:38 -0700 (PDT) X-Forwarded-Encrypted: i=2; AFNElJ8tRpB47yvdEevvLuveZCbjxu4Bysw5saEHnG0kXHg7Tk4IxOJh7uosuFF1EyyalSaK1Yeb63qxi0Dh@googlegroups.com X-Received: by 2002:a05:6512:63db:10b0:5a3:fcb2:c6a1 with SMTP id 2adb3069b0e04-5a3fcb2c809mr2159481e87.13.1776192996361; Tue, 14 Apr 2026 11:56:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776192996; cv=none; d=google.com; s=arc-20240605; b=BhEm7D68EsRzmDzODUSSKvVEbAELX6aWm0edYzU77E9a6jiL5mGLXWtMGCgHSROEk5 KHpKCeOYyu6qrZLrMrU7CJsgRlJOmg9Vfn9s74nBMc5jGJJhSVqGvV/k9BmDaM7yJ+HC P8n2eToNohUs0Vo5Lkwzq+TrBcvEmNXqJXl8ttfS7tA4QErPF8S/zS7Q+nnLozXSc56g g3qG0O8fIVf5mqRjkqazrCidsFgKCfjBcGzEQ+Hn7ZywIPNBXK7gqe57WXTUBbfbRCgC 84BgxGMeHLv6AC+J2S2QwxZIVC8vtAFfeQBImu84J9Iu92FGC54ztQDQ3UcOnz5lwkd1 q9gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=zVtxdf9Ugdh/EeM6KKJaVE+xVjqhlF34MKpYvOFficE=; fh=JscRoQWfVjASGdrrQ9flE5fSaik2YIEk9HCJPg7sC0o=; b=U2Qu/Pax6KRWS0VxmeO2+fLhsSRFEO9Afphw/FoqGaqjWjBnxA6JjfW0UvKCnlEfSv EKzZUkLRF5lf9pdTSsV+LHsCjbyMZNhpjSqk0vmchmX/UMPrHylBCf9XUbvkur9X7inY vtgx3i+GVseRkmE2OqmxWdxnFsgkNXvYcSJSqSylOujBU2IfJIn5fNUlCzd+jlkoEKP0 IpntCYGe1Qzmi8LyNYlXWy7rIZBwi2QF9etdSg76BB+Vni0Q8ujX3mTQ8WITS5ojlulS lmwFaq/2Df5lk3XboKTm8Qsnbu7koufUpX2azbfZdKAqwDWNLC5rpiLpbweHCsc30rU1 hw0A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=YE3K+jQ9; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.19 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch. [185.70.43.19]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-38e49a4a61fsi3186131fa.4.2026.04.14.11.56.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Apr 2026 11:56:36 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.19 as permitted sender) client-ip=185.70.43.19; Date: Tue, 14 Apr 2026 18:56:30 +0000 To: Matt Corallo From: "'conduition' via Bitcoin Development Mailing List" Cc: Ethan Heilman , Antoine Poinsot , Bitcoin Development Mailing List Subject: Re: [bitcoindev] In defense of a PQ output type Message-ID: In-Reply-To: <42806684-3cc4-42e2-8052-43288a93e91e@mattcorallo.com> 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> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 823f8ddb88721ad8026a9a53e87606f43fd5eafb MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------c2152fa5852f965a64a18f3b728286075daa7c565063cb301a4d4f32460311a4"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=YE3K+jQ9; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.19 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition 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.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------c2152fa5852f965a64a18f3b728286075daa7c565063cb301a4d4f32460311a4 Content-Type: multipart/mixed;boundary=---------------------839882b15d2db2bb1fbd8a8d43674616 -----------------------839882b15d2db2bb1fbd8a8d43674616 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Matt, > Right but you didn't contend with my point at all, only ignored it. Its g= reat 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 stolen= ! I don't think I ignored anything, but maybe I just didn't understand your p= oint. To me, your point seems to be (I'm summarizing here) that "Nobody will migr= ate 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 same people = (who wouldn't use P2MR) WOULD migrate to P2TRv2, because it is exactly as g= ood as P2TR until Q-Day. I respectfully disagree with this argument, and I gave my reasoning as to w= hy in my last reply. To review: - P2MR is quantum-secure by default. - P2MR is more efficient long-term. - P2MR does not commit us to carrying legacy crypto cruft past its shelf-li= fe. - P2MR and P2TRv2 are both equivalent to quantum-skeptics, who have no ince= ntive to migrate either way. - The short-term efficiency difference in P2MR and P2TRv2 is a negligible t= rade-off to anyone who ISN'T a total quantum-skeptic. - Fee-sensitive users are online and adaptive, and can use P2TR until Q-day= ; They do not need P2TRv2 any more than fee-insensitive users. - P2MR has utility even if Q-day never comes. - 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 fallb= ack leaf script. 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 comp= romises. Thus, we should deploy P2MR and NOT deploy P2TRv2. > But what about someone who sees quantum computers as 90% FUD that might h= appen eventually but won't for 50 years but still gets users nagging them a= bout 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 an= d way more realistic - and also a place where someone might do the work (or= , well, merge a PR if its done for them) but probably won't if they're buil= ding 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 fo= rgot about it for five years). Very specific. You're talking about wallet developers here, right? Exchange= s? Bitcoin businesses in general etc? And you're saying that the people run= ning these businesses and building the wallets - those who are being "nagge= d" to implement something that the rest of the cryptographic world has alre= ady starting rolling out in production [1] - You're saying that a subclass = of these people - those who are "mostly" skeptical of quantum hype - WOULD = implement P2TRv2, but WOULDN'T implement P2MR? It's debatable how big that subclass would be, especially given the current= landscape. But even if one confidently sees CRQCs as 50 years away, then I= 'd refer back to my earlier response, and argue that any such skeptical dev= eloper has no reason to implement either P2MR or P2TRv2 today, apart from c= ompatibility with other software which DOES implement them. If "nagging" is= the only motivation a dev or business owner has to implement a PQ output t= ype, then one need not distinguish between the two. They'd just implement w= hatever is standardized to please their users, and carry on with their day. If I'm being a little more realistic, most wallet devs will follow whatever= is standardized just to get more market share. I somehow doubt devs will t= urn up their noses and say "it's not efficient enough, I won't implement th= at 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-efficienc= y in the new output type, so much so that you seem to think devs would will= ingly ignore a potential existential threat to save users a few sats per tr= ansaction. But maybe look at it this way: - Whether quantum computers are 5, 10, 50 years or more away, anyone who tr= uly cares about a few extra sats per TX can continue to use P2TR when activ= ely transacting 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 ris= k of being caught with your pants down on Q-day, but the same is true of P2= TRv2 because we might not time the key-spend disabling follow-up fork corre= ctly. - Mining fees are a part of everyday life for Bitcoiners, and the pre-quant= um fee difference between P2TR and P2MR is NOTHING compared to the fee spik= e we'll all have to endure after Q-day, no matter what fancy cryptography w= e may end up using by then. There are far more important things we can opti= mize. > Again, you ignore that the impact is global, not local. Yes, quantum-skep= tics have to be brought along over time if you want to have any hope of bit= coin actually being relevant. Our job is not to proselytize and convince people that the quantum threat i= s real, nor is it even to encourage migration by design. Our job is to prep= are an optimal migration path in case the threat is real. If CRQCs do appea= r, everyone will want to migrate to PQC sooner or later. If they do not, ev= eryone moves on with their lives and the new output type becomes a relic (i= n P2MR's case, an occasionally useful one). Even if you feel your job IS to convince and migrate as many users as possi= ble, I would argue it'll be hard to convince anyone to migrate to an addres= s format that isn't PQ-safe by default. Bitcoiners trust code, not promises= , and P2TRv2 is only PQ-safe if you trust its promise of a future soft fork= , while its code would be PQ-vulnerable by default. And the only benefit to= accepting this risk seems to be a trivial discount in fees pre-Q-day. I do= n't speak for everyone of course, but personally I'd rather keep my cold-st= orage 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. > Sure, but any short term hash-based signature migration path is really no= t intended as the final state anyway - if Bitcoin is stuck with only hash b= ased signatures and a CRQC exists in 20 years that's a pretty terrible outc= ome. Hopefully by the time a CRQC becomes a real threat we have much more c= onfidence 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 m= ean P2MR isn't. We're talking about output types here, not opcodes. I would= argue P2MR remains useful regardless of the cryptography we use: lattice, = isogeny, hash-based, multivariate, whatever. Merkle trees have been around = for almost 50 years and seem hard to beat. For instance, we could reconstruct P2TR using isogenies [2], but would we r= eally 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 wo= uld be to use SQIsign to key-spend with some hypothetical "Pay-to-supersing= ular-curve" output type [^3]. I realize I'm kinda trashing my own research = by saying this, but it shows how hard it is to beat P2MR, even if you can a= ccept new cryptographic assumptions and the accompanying performance penalt= ies. Even if we do someday find some novel cryptosystem which permits rerandomiz= ation, 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 f= ew vbytes - a small fraction of the 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 e= ncourage users to hide public keys behind hash functions from now on, and t= o bolster riskier algorithms with hash-based fallback keys, so that we alwa= ys have at least one layer of protection between keys and any novel cryptan= alytic breakthroughs. Posting our plain pubkeys on-chain does sometimes hav= e fun benefits, but the drawbacks are deadly serious. Until SHA256 collision resistance is broken, I'd expect P2MR is probably th= e pinnacle of secure PQ address formats, and even then we'd probably end up= reimplementing P2MR with some newer hash function. Hopefully someday someo= ne proves me wrong, but we can only engineer with what we know today, and t= oday P2MR seems the most optimal conservative option for long-term security= and cryptographic agility. > And with them they will take bitcoin's value... If you're really worried about a supply glut caused by CRQCs stealing and d= umping them, then debating about P2TRv2 and P2MR is a distraction. IMO, mos= t coins will probably not migrate before Q-Day regardless of what output ty= pes we deploy, because many coins are held by dead hands, or by living hand= s 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 litt= le impact on the integrity of the UTXO set after Q-day. I would instead sug= gest you pursue the retroactive area of research (rescue protocols, quantum= canaries, hourglass, exposure statistics, etc). This is a domain where rea= l impact can be made to mitigate the risk of a supply glut when/if CRQCs ap= pear. Opportunities abound. We would be glad of the help :) =3D=3D=3D=3D=3D=3D=3D=3D Anyways, I appreciate the good-spirited debate, but to save myself time I d= on't think I'll continue replying. I've laid out my argument for P2MR prett= y clearly and I feel it is as convincing as I can make it. I'd be happy to = acknowledge any misunderstanding I may have had about your earlier points i= n favor of P2TRv2. As to the original subject of the email thread, and Antoine's original poin= ts, seems like we are all in agreement. regards, conduition [1]: https://blog.cloudflare.com/pq-2025/ [2]: https://conduition.io/cryptography/isogenies-intro/ [^3]: SQIsign signatures are 148 bytes, pubkeys are 65 bytes. Situation 1, = key-spending P2SC: a 65 byte pubkey goes on-chain in a witness program, and= the spender provides a 148 byte signature in the witness. Total weight: 65= *4 + 148 =3D 408, AKA 102 vbytes. Situation 2, script-spending with P2MR: a= 32 byte merkle root goes on-chain in a witness program, and the spender pr= ovides a 67 byte script (65 byte pubkey + 2 bytes of script), a 32-byte mer= kle node (for alternative script spend paths), and a 148 byte signature in = the witness. Total weight: 32*4 + 67 + 32 + 148 =3D 375 =3D 93.75 vbytes. N= otice in situation 1 the user who creates the output actually pays MORE in = fees than user who spends the output. Smart business owners listen to what the market demands, and leave their pe= rsonal opinions at the door. If the market demands they add quantum-safe ad= dresses, they'll do it sooner or later. This... seems like a lot of "what-if". I think it maybe reveals the source = of our disagreement. In your arguments, you are placing a lot of weight on = the importance of pre-quantum fee-efficiency, whereas in my arguments, I am= placing more weight on conclusive quantum-security and long-term fee-effic= iency. On Tuesday, April 14th, 2026 at 10:33 AM, Matt Corallo wrote: > > > On 4/13/26 9:45 PM, conduition wrote: > > =3D=3D=3D=3D=3D=3D=3D > > > > At the risk of this thread further devolving into a debate around P2MR = and P2TRv2... > > > >> Our goal is to get as many wallets migrated as possible, which really = means focusing on the wallets that are likely to take the longest to migrat= e. > > > > I can't speak for others, but my goal is to design and deploy a secure = and efficient soft-fork upgrade package so that myself and other bitcoin us= ers may retain control of our bitcoins in a world where the future security= of the ECDLP is uncertain. Encouraging adoption is a secondary goal which = follows immediately if we design the upgrade well. > > > > I personally don't see P2TRv2 as a suitable path towards this goal, bec= ause it still depends on ECDLP. At best, P2TRv2 PROMISES to be quantum-secu= re later, at the chaotic whim of the future Bitcoin community. Personally, = I would rather keep my coins on P2WPKH than on P2TRv2. No: If we are going = to have a PQ soft fork, it should be conclusive, self-contained, and requir= e no follow up. Otherwise, we haven't actually fixed the core uncertainty w= e need to address. > > Right but you didn't contend with my point at all, only ignored it. Its g= reat 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 o= wn coins were being stolen! > Pieter put this very well in his "The limitations of cryptographic agilit= y in Bitcoin" thread. > > >> That includes both "consumer" wallets which may be infrequently used b= y people who bought a pile of bitcoin and touch it once every few years as = well as those who are quantum-skeptical and will see no reason to upgrade u= ntil its urgent. > > > > Low-frequency users aren't fee sensitive, almost by definition, so I do= n't see them caring much about the minor witness size increase of P2MR comp= ared to P2TR. > > > > As for quantum-skeptical users, I see no reason why they would migrate = their coins to ANY quantum-resistant output type, whether P2TRv2 or P2MR. T= o someone who today sees quantum computers as 100% FUD with zero room for d= oubt, they will see any PQ output type as a slightly worse version of whate= ver they use today. So I don't really understand why it would be so importa= nt to encourage this class of user to migrate. They won't - not until their= world-view about the quantum threat changes. > > > > If and when their attitude does change, then a few vbytes of overhead c= ompared to P2TR won't deter them - not with an existential threat motivatin= g them to migrate. If fees DO deter them, then they're probably an active h= igh-frequency user like a miner or exchange, who can keep tabs on the situa= tion and continue to grind savings out of P2TR until the very last minute [= ^1]. > > But what about someone who sees quantum computers as 90% FUD that might h= appen eventually but won't > for 50 years but still gets users nagging them about it and support for i= mporting 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 someone might do the = work (or, well, merge a PR > if its done for them) but probably won't if they're building a consumer w= allet 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). > > > It is a mistake to compromise on long-term design choices [^2] to pleas= e quantum-skeptics, because: > > Again, you ignore that the impact is global, not local. Yes, quantum-skep= tics have to be brought > along over time if you want to have any hope of bitcoin actually being re= levant. > > > 1. If the quantum threat is indeed real, then sooner or later, whether = by theft or migration, this class of bitcoin user will no longer exist. > > And with them they will take bitcoin's value... > > > 2. On the other hand, if CRQCs turn out to be not-so-relevant after all= , then everyone becomes a quantum-skeptic, and we can all return to P2TR wh= ile the new PQ output type slowly fades into obscurity. > > > > Note in scenario (2), P2MR actually still has utility: P2MR can be used= as a more-efficient way to construct script-path-only addresses, without t= he need to commit to a NUMS point. P2TRv2 has no such secondary utility. > > > > regards, > > conduition > > > > > > [^1]: By the way Matt, I think it's a mistake to assume that large corp= orate users are not fee-sensitive. If anything they are more fee-sensitive = than Joe-Average - When you conduct thousands of transactions per day, 10% = larger witnesses could mean a lot. > > Sure, their hot wallet that is probably true, but also not super interest= ing - they can/will migrate > their hot wallet over the course of an hour if/when Q-day starts to be a = real threat. > > > [^2]: P2TRv2 is a compromise in the long-term compared to P2MR, because= after key-spending is disabled, P2TRv2 is strictly worse than P2MR: It wou= ld have worse performance and larger witnesses, more cryptographic complexi= ty, and it commits us to carry legacy ECC as cruft well into the future. > > Sure, but any short term hash-based signature migration path is really no= t intended as the final > state anyway - if Bitcoin is stuck with only hash based signatures and a = CRQC exists in 20 years > that's a pretty terrible outcome. Hopefully by the time a CRQC becomes a = real threat we have much > more confidence in lattice-based systems (or whatever PQC is popular then= ) and we can add whatever > output type makes sense at that point. > > Matt > --=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/= FK4r4I9x1v2s7NWZWm26e7rhmove8ckpdjJ4l6hwhpEomvIHxqVFgFws5ElDhIBnhaALGfTqaAj= 2NchrX0T8i4vYvUuxyh19sPmcrqG_Sy8%3D%40proton.me. -----------------------839882b15d2db2bb1fbd8a8d43674616 Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------839882b15d2db2bb1fbd8a8d43674616-- --------c2152fa5852f965a64a18f3b728286075daa7c565063cb301a4d4f32460311a4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0Fgmnejc4JEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmcLUtq/9tjiGhASwsBMB2Onm4PCk/s6KShwQhaw iqbl1hYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAD1wgD+OT7a8rmlKwIsq9YG ix0QJcH7svEF0BtNBn6yal59kKoA/35y9Tp9u4amURsClsgHAj86NH6M9eAt WURq7GXhvycA =ewnY -----END PGP SIGNATURE----- --------c2152fa5852f965a64a18f3b728286075daa7c565063cb301a4d4f32460311a4--