From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 14 Apr 2026 08:54:24 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wCg5m-00035u-VI for bitcoindev@gnusha.org; Tue, 14 Apr 2026 08:54:24 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-40ef793e45esf4141470fac.3 for ; Tue, 14 Apr 2026 08:54:22 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776182057; cv=pass; d=google.com; s=arc-20240605; b=aj+ZiXmyVtkiDjZmFbGzmyWLeuiZmQD7PvkjoGXAQsJTgmKTow3yzss97NKzqHlRq5 upH/vHKN/yjhkTDrHiswiPc+Wgrj7iTI7Miho3ElAPch1BNmB7TvCuCWnSyjD7M02dMt 8zOB/X87qsSp387Z/iAFYPvUM9Fr2XrhT1VaPpfvrGmSSXMepkdoe1wzg2WgFqG7Rdm4 J5eOy8T/8FmJWgCBu5NuR7F8RvQOoxVJ4L5yVNjay/xxnsIIL+u+JTyXFtAap8bjOkYi f91Y56toKp/Nc4/K3VsaKQcPobZ45PK9O/ccTESZk4+RDPLrIj8vujS0zZMEOpQrchcd CgCg== 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=P81fOBkQFQqd8wpW1tULveSTgUV3gbk8Pd+oqWE4POU=; fh=RREjTKdAFeHF0/2z1QteZ8vYMY4UrSpbGrvPM0PFbTM=; b=MiJFJN0NIh6/n58jhof3U+korMrhOPSyxn750XH54MgK07nb1nYTK7xvl8nEW0pdT/ 7zCjFz4aL/xF/jUO8tOLAmA/UFvllXYADMGMgheuQmEl1YYFxtWqW1No1YIDB5Bwi5rH Ku0u2Xf9HcUFGHeOZFJijjOrJTGleWStQj4zyhhD9picWfIXtNlGldwynuLCe05Jgate UwEZXq6BLLKos503iDFk3MgRalRjjWpMWDOZWr/k90TEMwLs0tbefDQB6/OLmI0dh0YJ W9ku6P0ZYCNhm06VbEw5uJ0KldX1BuYhSeo7Odn9fYM8fonfv8aO+9AdGrgFdO848D2C No9Q==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=OcXzL+iu; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.98 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=1776182057; x=1776786857; 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=P81fOBkQFQqd8wpW1tULveSTgUV3gbk8Pd+oqWE4POU=; b=duAI/fGlzektqYrVvlMkxs6UMj7mtHothSEZ7cWBFRaNTSdOFfG0PG4mCcYoJTR1U/ zTfqAawGsnQBTiTboQqETvGZBmTY/iW/FfGm49eACqO6WiM79z0FZMFiwsWvbabJNYLh AG4IG77yLlUt7xC0BmEMfcKi2fi3bKNzS/WaGOtnCNmF4mPwLG7k+5RGyDBr3ba74mkN 2veAqyMhwe2eq5oR3dBkrZmYMl4Gs1ZaTnsjKTFyS16nmB7Lx+ufe7+aII+uDTAKDvIl 2o6WnMDuTN/0+6WUGvrb4yy+0Nf0oostpBkJCb2K7j0E/gbzLMFVRmKs3hqUQCILICtm SQ+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776182057; x=1776786857; 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=P81fOBkQFQqd8wpW1tULveSTgUV3gbk8Pd+oqWE4POU=; b=mcutdS6SNtUfm/qLi40J70bd2oSfkRCDyKFZ2T1GEi2Wf+wFzotvI2d8XqBxK/Unh2 KBYU/pQlrWgF9cra7Qa9mNlEqrDeATd8leQtmBQjzcjxwCRXQmgAfBhNNrxDC1BDJf3o Al+AuD+gXkTFbLR2NLCqZYgkNflBWioM3l/eaolnOdIWOxTxih3cPFTGdYkcJSkd5F+X U/IPrU8IkQHdcLqcjqWGnVDf8Iz1auyqA69HXScCcnoZXBEXzb11/JWY+KznRiE6qmms 8nk5NR+FxY8dQ81tJUDnNoZQk8ZVQxxul++hlNpQoLxpT0d45ngJvTshiz/0XPyd6XyP QOhg== X-Forwarded-Encrypted: i=2; AFNElJ+/y3+a6uK1raHxsd2vsRIi59Gmx0Z+XB344GSQAuA+/y+1dPW5V2AaBrZGA09Z1fHLAuAn8SbWk/nc@gnusha.org X-Gm-Message-State: AOJu0YxfJ7Ki1AN/bhhi7AxM9KegP4QaJrbo4M6icoy45Hykwrlq/2Zs uAQkBV0YNbxhfs4A3DbMxpUz5r73wgmVbbjUPh3F0G/4oHuZ3eCGnllz X-Received: by 2002:a05:6871:781a:b0:423:7f5:1a6 with SMTP id 586e51a60fabf-423e1114ffbmr9331343fac.30.1776182056487; Tue, 14 Apr 2026 08:54:16 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiL1Hv8YcBBcf/93/zZCxxHCKx/UVaGvxzMiBYqNp3XiqQ==" Received: by 2002:a05:6870:b292:b0:41c:24d9:eb8b with SMTP id 586e51a60fabf-423dcff8779ls1615032fac.0.-pod-prod-02-us; Tue, 14 Apr 2026 08:54:11 -0700 (PDT) X-Received: by 2002:a05:6808:c2d9:b0:467:fcc9:7948 with SMTP id 5614622812f47-4789e71c993mr8136718b6e.20.1776182051424; Tue, 14 Apr 2026 08:54:11 -0700 (PDT) Received: by 2002:a05:600c:529b:b0:488:965a:b7a8 with SMTP id 5b1f17b1804b1-488cf323ff6ms5e9; Tue, 14 Apr 2026 07:52:01 -0700 (PDT) X-Received: by 2002:a5d:5d10:0:b0:43d:7ea8:a622 with SMTP id ffacd0b85a97d-43d7ea8a772mr6816814f8f.30.1776178319569; Tue, 14 Apr 2026 07:51:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776178319; cv=none; d=google.com; s=arc-20240605; b=Wh/gTLppiiORfz4MRkIIQ1+XKVnhcOVXcyJrziX8F8fh1prV5DeXds1J7/RK9kDq8l Br4652MeLW47yzlYdFhTiEG7wH4s999YnZrcvejLzLAgodK55S9Ov3WphCD2AhjwfV8v CjxJozUHfw7an/aT67d5pL3wuHXGJA/+hQbNZy6120M3U46j+uRqeIPo8jY5aGOJyFtG g5dLzgB1TqiOP3epxBHqKp8QV66/j7stwor6BwCFair6tNsNMTsIJpOtSnZCFJITw47g R5wYdNxLe1OWfK6EzRbPdb+O6ysHJ+HShKuX+FTnlyRdu3bjt2Nx9nHvM+Viuu5T3hWE 4cTQ== 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=if5ydSK2uae23R9nKI6uL8oZIhq++rmhD5DEjVVGJ7c=; fh=qsIjjjz9uHFgXy188rF0UCrA62ZKIfn8xtMqJJ6blB8=; b=Bk8NYgkK3qXdxPfkJTjVgerUa2rBt7SpzzphSMgUlUaCzKYfzblYC2f9v5Xu/5K4IM F6dtUEByI1PiqaJiUVOB4kQrIJDTwQNcCBq33ESQvkVriAvRJ5NV4DLtrN8Wk3fX3p8w ISncQjOIpmulXVGhIBWdHj6zIIbFCiPCrgBsPy5DOBDbml3CLtnaFFS0Yhr3uBqZs3fU tmuZ9GLYnqi7E+TKdwtqh/2fN+aKMOEnpFHMzTfLFriafs2wbzuHtimyArqVYsmXJybZ y0YHjPkZxSs0VzZmU0MT/t2TDPuSgNwufDuAPC2pLgCpMXLRqSTb4hEmzZr4mkeuL0Uj zFMw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b=OcXzL+iu; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.98 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-10698.protonmail.ch (mail-10698.protonmail.ch. [79.135.106.98]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-43d63e6dcebsi282240f8f.5.2026.04.14.07.51.59 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Apr 2026 07:51:59 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.98 as permitted sender) client-ip=79.135.106.98; Date: Tue, 14 Apr 2026 14:51:54 +0000 To: Thomas Suau From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] In defense of a PQ output type Message-ID: In-Reply-To: <34cb87e2-4d4e-4403-91ce-d1f1328ddb98n@googlegroups.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> <34cb87e2-4d4e-4403-91ce-d1f1328ddb98n@googlegroups.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: ea070e8cb759d8d4a4069353389588be5e40a28a MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------25fe8674ecfe78a243c15c460137e7552dc7f40ac05e521155e5814648a5dd8f"; 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=OcXzL+iu; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.98 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) --------25fe8674ecfe78a243c15c460137e7552dc7f40ac05e521155e5814648a5dd8f Content-Type: multipart/mixed;boundary=---------------------fe55d33d2bc9241f928620ff4343ea8c -----------------------fe55d33d2bc9241f928620ff4343ea8c Content-Type: multipart/alternative;boundary=---------------------774daef3c520eb250c77b103786e7134 -----------------------774daef3c520eb250c77b103786e7134 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Thomas, I just want to clarify a misconception in your email there: > In the meantime, wallets can already construct P2TR with a NUMS internal = key to force script-path spending. Same effect as P2MR =E2=80=94 output key= becomes unspendable, signing key stays hash-protected until spend time =E2= =80=94 but at the wallet level, no soft fork. CRQCs can spend NUMS point addresses with the key-spend path, even if nobod= y else can. So P2TR + NUMS is not equivalent to P2MR in security. A NUMS point is a point P produced by hashing some fixed public data and fi= nding a point on the curve with the resulting hash as an x-coordinate. For = instance, BIP341 suggests using SHA256 to hash the secp256k1 generator poin= t.=C2=A0 `P =3D lift_x(sha256(G))` This process used to create a NUMS point makes it unlikely for anyone to ha= ve the secret key of that NUMS point, because we assume it is hard to find = a collision between the hash function and secp256k1 point multiplication. Quantum computers break that assumption, because they don't need to find a = collision. A CRQC can compute a hash, find the curve point, and then use Sh= or's algo to find that point's discrete log (secret key) with respect to th= e generator point G. Once they have it, they could key-spend from=C2=A0any= =C2=A0P2TR (or P2TRv2) address which uses this trick, provided they also kn= ow the corresponding tap script tree merkle roots. regards, conduition On Tuesday, April 14th, 2026 at 8:54 AM, Thomas Suau = wrote: > Hi Antoine, list, >=20 > +1 on separating PQ availability from the freeze question. >=20 > conduition put it well =E2=80=94 adding a PQ opcode to tapscript and addi= ng a new output type aren't independent decisions. A PQ opcode alone doesn'= t remove the key-path, so the output key remains a bare curve point on-chai= n, vulnerable at rest. We'd still need to bump the witness version to disab= le it. P2MR (BIP 360) does exactly this without requiring any new opcode, a= nd PQ opcodes can come later through OP_SUCCESSx. Both are needed, I think = the question is more about sequencing =E2=80=94 P2MR addresses long exposur= e with a smaller consensus change. >=20 > In the meantime, wallets can already construct P2TR with a NUMS internal = key to force script-path spending. Same effect as P2MR =E2=80=94 output key= becomes unspendable, signing key stays hash-protected until spend time =E2= =80=94 but at the wallet level, no soft fork. You lose key-path efficiency,= and it requires proper key rotation (unique HD derivation per script leaf,= not just per address), but the mechanism is specified in BIP-341 and can s= hip today. >=20 > Regards, > Thomas Suau > Le mardi 14 avril 2026 =C3=A0 03:52:39 UTC+2, conduition a =C3=A9crit : >=20 > > Hi Matt, > >=20 > > > Yes, we have to figure out what kind of output type we want, whether = P2MR (360), P2TRv2 or just P2TR. There are strong arguments for each. But n= one of that has any bearing on whether we add hash based signatures to taps= cript. We have to add hash based signatures to tapscript first no matter wh= at output type we want! > >=20 > > Apologies, there must be some mixup. I think we agree with each other a= bout this - adding a new PQ opcode to tapscript is always going to be neces= sary, and our choice of PQ output type doesn't affect that =F0=9F=91=8D > >=20 > > My earlier clarification was that we must go further: We must add a new= output type in order to disentangle opt-in PQC opcodes from any confiscato= ry soft fork that disables P2TR key-spending. Otherwise, if we only enable = the hash-based opcode and do nothing else, then we must disable key spendin= g later or else the opcode is useless. > >=20 > > So the two concepts are not completely independent. Adding hash-based s= ignatures to tapscript necessitates a new opt-in output type that we can st= andardize quantum-resistant wallets under. Similarly, adding a quantum-resi= stant output type doesn't seem very useful without a quantum safe way to au= thorize spending. > >=20 > > =3D=3D=3D=3D=3D=3D=3D > >=20 > > At the risk of this thread further devolving into a debate around P2MR = and P2TRv2... > >=20 > > > 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 migra= te. > >=20 > > 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. > >=20 > > 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. > >=20 > > > That includes both "consumer" wallets which may be infrequently used = by 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 = until its urgent. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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]. > >=20 > > It is a mistake to compromise on long-term design choices [^2] to pleas= e quantum-skeptics, because: > >=20 > > 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. > > 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. > >=20 > > 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. > >=20 > > regards, > > conduition > >=20 > >=20 > > [^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. > >=20 > > [^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. > >=20 > >=20 > >=20 > > On Monday, April 13th, 2026 at 9:23 AM, Matt Corallo wrote: > >=20 > > > > >=20 > > > > >=20 > > > On 4/10/26 8:20 PM, Ethan Heilman wrote: > > > > > IMO even something like P2MR's additional cost will strongly disc= ourage adoption. > > > > > > > > I don't agree. > > > > > > > > Over time as quantum attacks become a bigger and bigger concern for= holders, wallets will want to > > > > show that they can offer security against CRQCs. This is especially= true for wallets focused on high > > > > value Bitcoin outputs. Even if someone thinks there is only a 2% ch= ance they lose all their Bitcoin > > > > because of a quantum computer, that 2% chance will keep them up at = night. > > > > > > > > P2MR would have 17.25 more vBytes, an 11% overhead. > > > > > > > > P2TR 1 input, 2 output - key path spend. 154 vbytes > > > > P2MR 1 input, 2 output - spending a schnorr sig leaf of a P2MR outp= ut with two leafs: 1. PQ sig leaf > > > > and 2. Schnorr sig leaf. 171.25 vbytes > > > > > > > > I'm stacking the deck against P2MR here. Under some circumstances P= 2MR has lower fees than P2TR. > > > > > > > > It is hard to imagine someone holding significant quantities of Bit= coin not wanting to pay 50 > > > > sats to ensure their Bitcoin isn't stolen by a quantum computer. > > > > >=20 > > > Right, but I think we're focusing on two very different groups. The "= holds significant quantities of > > > Bitcoin" group I'm much less worried about vs the "holds some quantit= y of Bitcoin in an average > > > consumer Bitcoin wallet". The first group includes institutions, fund= s, and people relatively "into" > > > bitcoin - they're paying attention, (hopefully) using decent wallet s= oftware, holding funds in cold > > > storage, and aren't fee-sensitive. But this group is going to have no= problem migrating no matter > > > what the solution is - the institutions and funds camp can migrate in= a few days in an urgent > > > scenario and the long-term holder with a significant portion of their= net-wroth in Bitcoin is also, > > > likely, paying reasonably close attention to Bitcoin and can react qu= ickly. > > > > >=20 > > > Because those groups are quite capable of reacting quickly, I don't r= eally buy that they're the > > > "target market" for short-term PQC in Bitcoin. 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 migrate. > > > That includes both "consumer" wallets which may be infrequently used = by people who bought a pile of > > > bitcoin and touch it once every few years as well as those who are qu= antum-skeptical and will see no > > > reason to upgrade until its urgent. Importantly, the decisions here a= re made by the developers of > > > the software, generally not the actual end users holding Bitcoin. > > > > >=20 > > > To put it a different way, the goal of adding PQC to Bitcoin is *not*= to "give people an option to > > > migrate" but rather to "make use of the PQC scheme the default" acros= s the ecosystem. The former may > > > get the migration process started, yes, but it does not ease the futu= re community's difficulties > > > materially - the slower-to-migrate coins will still be just as stuck = as before and just as much > > > Bitcoin will be available to steal by a theoretical CRQC. Thus, ISTM = the focus *has* to be on > > > something that has minimal drawbacks - not losing the script policy p= rivacy of P2TR, low or no fee > > > overhead, etc. > > > > >=20 > > > Of course that isn't to say that P2MR might not also make sense in ad= dition, but focusing only on > > > that misunderstands the goal. > > > > >=20 > > > Matt > > > > >=20 > > > -- > > > You received this message because you are subscribed to the Google Gr= oups "Bitcoin Development Mailing List" group. > > > To unsubscribe from this group and stop receiving emails from it, sen= d an email to bitcoindev+...@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/6d075872-0db8-4e7b-ac2a-452624c991ad%40mattcorallo.com. > > > >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/34cb87e2-4d4e-4403-91ce-d1f1328ddb98n%40googlegroups.com. --=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/= ClVeaJo5mBlMKDFiGoOzbbxhpcoLFOzSdx5PNJXPWoAAGX-mmDKR3SCyjBU748Ma5_xYncfkay_= uYoKJBBtRS6zrWVimi_Qf0kRuHLZkkPg%3D%40proton.me. -----------------------774daef3c520eb250c77b103786e7134 Content-Type: multipart/related;boundary=---------------------d9cd03f563ae1ab8201c1959b751b470 -----------------------d9cd03f563ae1ab8201c1959b751b470 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Thomas,<= /div>

I just = want to clarify a misconception in your email there:

In the meantime= , wallets can already construct P2TR with a NUMS internal key to force scri= pt-path spending. Same effect as P2MR =E2=80=94 output key becomes unspenda= ble, signing key stays hash-protected until spend time =E2=80=94 but at the= wallet level, no soft fork.

CRQCs c= an spend NUMS point addresses with the key-spend path, even if nobody e= lse can. So P2TR + NUMS is not equivalent to P2MR in security.
=

<= /span>
A NUMS point is a point P produced by hashing some fixed public data= and finding a point on the curve with the resulting hash as an x-coordinat= e. For instance, BIP341 suggests using SHA256 to hash the secp256k1 = generator point. 

P =3D lift_x(sha256(G))=E2=80=8B

This process used to create a NUMS point makes it= unlikely for anyone to have the secret key of that NUMS point, because we = assume it is hard to find a collision between the hash function and secp256= k1 point multiplication.

Quantum computers break that assumpti= on, because they don't need to find a collision. A CRQC can compute a hash,= find the curve point, and then use Shor's algo to find that point's discre= te log (secret key) with respect to the generator point G. Once they have i= t, they could key-spend from any P2TR (or P2TRv2) address = which uses this trick, provided they also know the corresponding tap script= tree merkle roots.

regards,
conduition
On Tuesday, April 14th, 2026 at 8:54 AM, Thomas Suau <tomeclair@= gmail.com> wrote:
Hi Antoine, list,

+1 on separating PQ availability from = the freeze question.

conduition put it well =E2=80=94 adding a PQ op= code to tapscript and adding a new output type aren't independent decisions= . A PQ opcode alone doesn't remove the key-path, so the output key remains = a bare curve point on-chain, vulnerable at rest. We'd still need to bump th= e witness version to disable it. P2MR (BIP 360) does exactly this without r= equiring any new opcode, and PQ opcodes can come later through OP_SUCCESSx.= Both are needed, I think the question is more about sequencing =E2=80=94 P= 2MR addresses long exposure with a smaller consensus change.

In the = meantime, wallets can already construct P2TR with a NUMS internal key to fo= rce script-path spending. Same effect as P2MR =E2=80=94 output key becomes = unspendable, signing key stays hash-protected until spend time =E2=80=94 bu= t at the wallet level, no soft fork. You lose key-path efficiency, and it r= equires proper key rotation (unique HD derivation per script leaf, not just= per address), but the mechanism is specified in BIP-341 and can ship today= .

Regards,

Thomas Suau
Le mardi 14 avril 2026 =C3=A0 = 03:52:39 UTC+2, conduition a =C3=A9crit :
Hi Matt,

> Yes, we have to figure out what kind of output type we want, wheth= er P2MR (360), P2TRv2 or just P2TR. There are strong arguments for each. Bu= t none of that has any bearing on whether we add hash based signatures to t= apscript. We have to add hash based signatures to tapscript first no matter= what output type we want!

Apologies, there must be some mixup. I think we agree with each other a= bout this - adding a new PQ opcode to tapscript is always going to be neces= sary, and our choice of PQ output type doesn't affect that =F0=9F=91=8D

My earlier clarification was that we must go further: We must add a new= output type in order to disentangle opt-in PQC opcodes from any confiscato= ry soft fork that disables P2TR key-spending. Otherwise, if we only enable = the hash-based opcode and do nothing else, then we must disable key spendin= g later or else the opcode is useless.

So the two concepts are not completely independent. Adding hash-based s= ignatures to tapscript necessitates a new opt-in output type that we can st= andardize quantum-resistant wallets under. Similarly, adding a quantum-resi= stant output type doesn't seem very useful without a quantum safe way to au= thorize spending.

=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 rea= lly means focusing on the wallets that are likely to take the longest to mi= grate.

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.

> That includes both "consumer" wallets which may be infrequently us= ed by 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 upgra= de until 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].

It is a mistake to compromise on long-term design choices [^2] to pleas= e quantum-skeptics, because:

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.
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.

[^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.



On Monday, April 13th, 2026 at 9:23 AM, Matt Corallo <lf-l...@mattcorallo.com> wrote:

>

>

> On 4/10/26 8:20 PM, Ethan Heilman wrote:
> > > IMO even something like P2MR's additional cost will str= ongly discourage adoption.
> >
> > I don't agree.
> >
> > Over time as quantum attacks become a bigger and bigger conce= rn for holders, wallets will want to
> > show that they can offer security against CRQCs. This is espe= cially true for wallets focused on high
> > value Bitcoin outputs. Even if someone thinks there is only a= 2% chance they lose all their Bitcoin
> > because of a quantum computer, that 2% chance will keep them = up at night.
> >
> > P2MR would have 17.25 more vBytes, an 11% overhead.
> >
> > P2TR 1 input, 2 output - key path spend. 154 vbytes
> > P2MR 1 input, 2 output - spending a schnorr sig leaf of a P2M= R output with two leafs: 1. PQ sig leaf
> > and 2. Schnorr sig leaf. 171.25 vbytes
> >
> > I'm stacking the deck against P2MR here. Under some circumsta= nces P2MR has lower fees than P2TR.
> >
> > It is hard to imagine someone holding significant quantities = of Bitcoin not wanting to pay 50
> > sats to ensure their Bitcoin isn't stolen by a quantum comput= er.
>

> Right, but I think we're focusing on two very different groups. Th= e "holds significant quantities of
> Bitcoin" group I'm much less worried about vs the "holds some quan= tity of Bitcoin in an average
> consumer Bitcoin wallet". The first group includes institutions, f= unds, and people relatively "into"
> bitcoin - they're paying attention, (hopefully) using decent walle= t software, holding funds in cold
> storage, and aren't fee-sensitive. But this group is going to have= no problem migrating no matter
> what the solution is - the institutions and funds camp can migrate= in a few days in an urgent
> scenario and the long-term holder with a significant portion of th= eir net-wroth in Bitcoin is also,
> likely, paying reasonably close attention to Bitcoin and can react= quickly.
>

> Because those groups are quite capable of reacting quickly, I don'= t really buy that they're the
> "target market" for short-term PQC in Bitcoin. Our goal is to get = as many wallets migrated as
> possible, which really means focusing on the wallets that are like= ly to take the longest to migrate.
> That includes both "consumer" wallets which may be infrequently us= ed by 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 until its urgent. Importantly, the decisions her= e are made by the developers of
> the software, generally not the actual end users holding Bitcoin.
>

> To put it a different way, the goal of adding PQC to Bitcoin is *n= ot* to "give people an option to
> migrate" but rather to "make use of the PQC scheme the default" ac= ross the ecosystem. The former may
> get the migration process started, yes, but it does not ease the f= uture community's difficulties
> materially - the slower-to-migrate coins will still be just as stu= ck as before and just as much
> Bitcoin will be available to steal by a theoretical CRQC. Thus, IS= TM the focus *has* to be on
> something that has minimal drawbacks - not losing the script polic= y privacy of P2TR, low or no fee
> overhead, etc.
>

> Of course that isn't to say that P2MR might not also make sense in= addition, but focusing only on
> that misunderstands the goal.
>

> Matt
>

> --
> 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 email to bitcoindev+...@googlegroups.= com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/6d075872-0db8-4e7b-= ac2a-452624c991ad%40mattcorallo.com.
>

--
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/34cb87e2-4d4e-4403-91ce-d1f1328ddb98n%40googlegroups.com= .

--
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/ClVeaJ= o5mBlMKDFiGoOzbbxhpcoLFOzSdx5PNJXPWoAAGX-mmDKR3SCyjBU748Ma5_xYncfkay_uYoKJB= BtRS6zrWVimi_Qf0kRuHLZkkPg%3D%40proton.me.
-----------------------d9cd03f563ae1ab8201c1959b751b470-- -----------------------774daef3c520eb250c77b103786e7134-- -----------------------fe55d33d2bc9241f928620ff4343ea8c 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== -----------------------fe55d33d2bc9241f928620ff4343ea8c-- --------25fe8674ecfe78a243c15c460137e7552dc7f40ac05e521155e5814648a5dd8f Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmneVHoJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmfrpJ1LI6ZCF2Kj4p9Z43E2t3pJcDqjpLPsqVAL Vj+/rRYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAB3hAD/UJgeOfEPrvm12gUR p4B9+zFtwYIng10eJAdoSUdQ918A/iqCkMl30XOd11Uf0PtaxMqqqKi1WbjX CHHRJ/DVWUcM =J/mH -----END PGP SIGNATURE----- --------25fe8674ecfe78a243c15c460137e7552dc7f40ac05e521155e5814648a5dd8f--