From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 14 Apr 2026 12:15:20 -0700 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wCjEE-0005M4-Sb for bitcoindev@gnusha.org; Tue, 14 Apr 2026 12:15:20 -0700 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-40ee506cf49sf9965960fac.2 for ; Tue, 14 Apr 2026 12:15:18 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776194113; cv=pass; d=google.com; s=arc-20240605; b=VFAw+IDMSpm5uft+04Uk42OSHSz0l8grQdsp+5n+dz3w4gTCEcZpZ45kiNqP7EpKkC nHuK0d3DaFk/D7NfI2K3M7bT1kVYPOPGOX2/4OXpic1hehKtr2kD0sz8+9w88wyqxILz NpgCNW7UjKOPNgLfutUBjSX5V/7sCkFWFg3bUjQbTNeAGQq+34tVUxBzQ4kqiJGVT0cO LGjKG3Nv/j0cvABbwIzNnaRqRtJiC61m2dhUtG4lf0Yr4w91XAj2Mmq7s77bYzydFHFw sIz9XdWipVPg9K0dZIRLQrn6fI/tjw+cOlTAWMBFJMu1nvGmBB15xGK6H4HDM0xb4lLU X+oA== 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=9HASi+X8n6RKl/Ax94vBZ0apTpjG/iDKwMO62F5D98E=; fh=2bx0/dkhyfVxiyUq1q8m95fA3AenDHQs8Lwc5gmuzUg=; b=FJI7VDy37oFzY3h0shISe2XsmtSXyLWjPXPsTfQtPZXL9NNCxWuknYs8sdMt93WkuK xi1M5op8SCn51PuelGZOWhencT0DzGZFiqFugo4ghQVfQBVoFQBQft/dPqUDsAEu9ceH Ey7LL56x3M81mORenwUPS5jn3p6S6S0+jRgKLK36CUcb0Hid6gusYMBooPMjuJxRXDzk P3xASBaPyQpMlih+Ud+rhNAwiaPXFBRu8BZqWNvKqFL2lcpraBTz3KZRBLeQzl7WRpEf vmD7LAMlJX7wxSCuN/vsjvLtSVkvCPmK13/wVCLvp+/eF/GiL+j5BCZZ1X486a7o+khq tn+w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="E87I/N0R"; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.166 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=1776194113; x=1776798913; 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=9HASi+X8n6RKl/Ax94vBZ0apTpjG/iDKwMO62F5D98E=; b=a1Cp/lw9LuwRRkP8LQyZbX0wTSKuQFNThtY3R/V0Br/qN/k1sEB3vkUvFQgagYjqz7 crFLK2JV1aLjATJu+GlM0gro11vm611Nq+qSAs2+0yjEM7KKdqdmlegat/IMF3sf84pf N+38lOzoRFiabtiCc5GwPxeBiu+GtaRuo707m3in8dEVP+M/2KMK/DfT5vSOUwPbz9CX QTkCdIAecm7TYJFlSLEYaWkDS3i6XhUv9lvE8y2a3/gbnFrmui1/YgB0z7K2HyiqmC8h 1IHMI4K+FRF4SKg8jpN2ZWpKB6P0ThTUtTA+CK73JaE19XZCX6KvobZtqmSfEUH45LSv s/uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776194113; x=1776798913; 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=9HASi+X8n6RKl/Ax94vBZ0apTpjG/iDKwMO62F5D98E=; b=g/C51uWmsRfudq0UxGeThay8rRO/mSbCTDrEgL5d8QO2w53Z/W4GfDXFE8pzwJYC9E 9i1ROjX224+e+t56B6UYNxwuU9WgIrPkbwn8Dp1rYyUdg/pe3oZuQCm15bFDKR0G7N2R GDr7yxT6Ra3q/kmul61IkL34wI1EftdPBxiHqxWjYxFATSCnid6U0ArlIttj+db/9Xke RF1nebMr02U1u1qxPJHvJrB5T+fKL9vJRuv21TVgApPpvCBnML6JGerSadfw49xLTmhn 077DZ2buZB3jaXBDXXU/L63AleVNnAGnn/AHGsCfd9nmuauxL7snYk9VnVqC+l9F/ZGV x/9g== X-Forwarded-Encrypted: i=2; AFNElJ+MWoD/SlRmkjmNxE69kKvjrxzEsTZY5A+ckZhmW18btIRp6PL6HANkHe7mCOUeC4KWKtvdbRkbuuOw@gnusha.org X-Gm-Message-State: AOJu0YxdkAsbmJoydBnJjPe9d45Hp+j6Sv4gX2WwEyh3LzzWsm4rBWBC mzTYx3WAs1w2aQUX0HX+2gqqMPg9704x5C61Dr6wkrqLJ4xFRGur4A1s X-Received: by 2002:a05:6871:5289:b0:417:69c2:4026 with SMTP id 586e51a60fabf-423e0e98a3amr10442286fac.19.1776194112753; Tue, 14 Apr 2026 12:15:12 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiIQm/ivtyLVGfYPx+7zuTG0raUpJ0GWWzRPcnnuoqlEsg==" Received: by 2002:a05:6871:3591:b0:416:1b5c:16df with SMTP id 586e51a60fabf-423dd9d9554ls3135721fac.2.-pod-prod-08-us; Tue, 14 Apr 2026 12:15:07 -0700 (PDT) X-Received: by 2002:a05:6808:1907:b0:44d:a3e3:40a9 with SMTP id 5614622812f47-4789c649f9emr9020323b6e.8.1776194107598; Tue, 14 Apr 2026 12:15:07 -0700 (PDT) Received: by 2002:a05:600c:2288:b0:485:53e3:ec5e with SMTP id 5b1f17b1804b1-488f0766957ms5e9; Tue, 14 Apr 2026 12:09:15 -0700 (PDT) X-Received: by 2002:a05:600c:8591:b0:486:fab9:a578 with SMTP id 5b1f17b1804b1-488d67eca69mr197898175e9.11.1776193754410; Tue, 14 Apr 2026 12:09:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776193754; cv=none; d=google.com; s=arc-20240605; b=aaQyfVoZiLgOjRf/ue/gCR2TUUz5V7Hvbsi0AP58y5wqacflrnL91Zv9y7w6bgODcQ Y3URt1/ewpbt3ZFFiG+WOGU/4zpJ2yS0uRKw0q6AcPOCteHvfjULEu+heuj+OHPG9+Li GkJ+G1y5g+xwJAPB9HDDmNni3u0b31yuFKxhzx6tfuQTRaXbX5pZYDQSfy8bhR8n0mji 1kSTgdmosIcM7FqMndRXRYov+0+4UxVg/YblnSFtKPZxqXvuJAzeCEh2EfRFGipO2l+B 25c+RC5HDPe9QFCw8k7d7zfhFoILuqmZ3lOoXyThDh+c83rlmm+ypfX8PxZkA1iWbhSh k/EA== 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=7/J+tmeWWNPqvvS59DCuB+Jhh1QduTeMPcOKM6SgQJ8=; fh=caAy3wgak+LG+DeVPK0QkUpwcEHP5OPDbY0ojxKxrA8=; b=fnnu2IlTwxjz0B4NWMrFrbZsSyONOeW6NWY3QhhyaebgNsVsYkUIiSDNO4AnomFE9K KGibFeKeoF3NpPp6btRG8COYak3DD40RHCyZC6p9vQKFNthabbTXu8OqVhPoiyyMrYBx MliiPU5IMRANBw5e+7drAE9TPespe54GZsUD3NEcgmsjph8eyLpJAac/TAlVISVziZZX BM+fwwaZr95ED8fmHI31JgQ+1vqwWl5gLkRO3gAZpHbCuailQooA+iw01u+bJZvVidBj ORxJZYLX58N9jOKW49FIVlfcgM5rQS7K7NGVt0QbkzbI4mfJHH2+WrXenCUZkVNA6tLX NIFw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=protonmail header.b="E87I/N0R"; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.166 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-43166.protonmail.ch (mail-43166.protonmail.ch. [185.70.43.166]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-488eddb1a5csi577705e9.0.2026.04.14.12.09.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Apr 2026 12:09:14 -0700 (PDT) Received-SPF: pass (google.com: domain of conduition@proton.me designates 185.70.43.166 as permitted sender) client-ip=185.70.43.166; Date: Tue, 14 Apr 2026 19:09:10 +0000 To: thomas suau From: "'conduition' via Bitcoin Development Mailing List" Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] In defense of a PQ output type Message-ID: In-Reply-To: <3E7B6DB3-7DF3-47F1-AA88-D0DC1CC9502D@gmail.com> References: <3E7B6DB3-7DF3-47F1-AA88-D0DC1CC9502D@gmail.com> Feedback-ID: 72003692:user:proton X-Pm-Message-ID: 0e762f857b0964248ecde51460a9e84c981be8e6 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------b12707b7baec44b5f361d84717099017058a843039de962394ba073e32586b3c"; 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="E87I/N0R"; spf=pass (google.com: domain of conduition@proton.me designates 185.70.43.166 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) --------b12707b7baec44b5f361d84717099017058a843039de962394ba073e32586b3c Content-Type: multipart/mixed;boundary=---------------------e67c7bbdb89da7eb20c4b49d7f642b47 -----------------------e67c7bbdb89da7eb20c4b49d7f642b47 Content-Type: multipart/alternative;boundary=---------------------35f4c370e33bf929654e1b2561948362 -----------------------35f4c370e33bf929654e1b2561948362 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Thomas, > So basically every P2TR is vulnerable, since script-path only enforcement= relies on NUMS point? Exactly. Unless we enact some future (contentious) soft-fork to disable key= -path spending and possibly replace it with something else like a commit/re= veal or STARK-based rescue protocol, then every P2TR would be vulnerable to= a CRQC. > Conduition, do you think P2MR is a good natural solution? Looks like the = closest to Taproot logic, just removing the key-path spend. Absolutely. P2MR has all the advantages of P2TR's script tree commitment st= ructure, with none of the vulnerable cryptography. It does have slightly la= rger witnesses than P2TR when using BIP340 key-spending, but for script-pat= h spending, P2MR is always more efficient than P2TR. But P2MR is not the only option - As Matt has pointed out, we could also de= ploy a clone of P2TR with a new segwit version number, called P2TRv2. The o= nly technical difference between P2TR and P2TRv2 is that P2TRv2 explicitly = opts into a future soft fork that disables key-spending, and so it should= =C2=A0become quantum safe at an undefined future time.=C2=A0Personally I th= ink that's a short-sighted solution, for reasons I outlined in prior emails= . regards, conduition On Tuesday, April 14th, 2026 at 10:54 AM, thomas suau = wrote: > Hi conduition,=C2=A0Ah yes, indeed NUMS is broken as well I missed that. = Big difference and big break.=C2=A0 >=20 > So basically every P2TR is vulnerable, since script-path only enforcement= relies on NUMS point?=C2=A0 > I=E2=80=99ve read that using a different generator wouldn=E2=80=99t help = either, Schor solves the dlog directly on the curve. Even a secret point wo= uld be broken?=C2=A0 >=20 > In that=E2=80=99s case P2TR is just quantum dead=E2=80=A6=C2=A0 >=20 > Conduition, do you think P2MR is a good natural solution? Looks like the = closest to Taproot logic, just removing the key-path spend.=C2=A0 >=20 > Regards,=C2=A0 > Thomas=C2=A0 >=20 >=20 > >=20 > > On 14 Apr 2026, at 16:51, conduition wrote: >=20 > > =EF=BB=BFHi Thomas, > >=20 > > I just want to clarify a misconception in your email there: > >=20 > >=20 > > > In the meantime, wallets can already construct P2TR with a NUMS inter= nal 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. > >=20 > >=20 > >=20 > > CRQCs can spend NUMS point addresses with the key-spend path, even if n= obody else can. So P2TR + NUMS is not equivalent to P2MR in security. > >=20 > >=20 > > A NUMS point is a point P produced by hashing some fixed public data an= d finding a point on the curve with the resulting hash as an x-coordinate. = For instance, BIP341 suggests using SHA256 to hash the secp256k1 generator = point.=C2=A0 > >=20 > >=20 > > `P =3D lift_x(sha256(G))` > >=20 > >=20 > > This process used to create a NUMS point makes it unlikely for anyone t= o have the secret key of that NUMS point, because we assume it is hard to f= ind a collision between the hash function and secp256k1 point multiplicatio= n. > >=20 > >=20 > > Quantum computers break that assumption, because they don't need to fin= d a collision. A CRQC can compute a hash, find the curve point, and then us= e Shor's algo to find that point's discrete log (secret key) with respect t= o the generator point G. Once they have it, they could key-spend from=C2=A0= any=C2=A0P2TR (or P2TRv2) address which uses this trick, provided they also= know the corresponding tap script tree merkle roots. > >=20 > > regards, > > conduition > > On Tuesday, April 14th, 2026 at 8:54 AM, Thomas Suau wrote: > >=20 > > > 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 = adding a new output type aren't independent decisions. A PQ opcode alone do= esn'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 the witness version to d= isable it. P2MR (BIP 360) does exactly this without requiring any new opcod= e, and PQ opcodes can come later through OP_SUCCESSx. Both are needed, I th= ink the question is more about sequencing =E2=80=94 P2MR addresses long exp= osure with a smaller consensus change. > > >=20 > > > In the meantime, wallets can already construct P2TR with a NUMS inter= nal 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 efficie= ncy, and it requires proper key rotation (unique HD derivation per script l= eaf, not just per address), but the mechanism is specified in BIP-341 and c= an ship 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, whet= her P2MR (360), P2TRv2 or just P2TR. There are strong arguments for each. B= ut none of that has any bearing on whether we add hash based signatures to = tapscript. We have to add hash based signatures to tapscript first no matte= r what output type we want! > > > >=20 > > > > Apologies, there must be some mixup. I think we agree with each oth= er about this - adding a new PQ opcode to tapscript is always going to be n= ecessary, 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 confis= catory soft fork that disables P2TR key-spending. Otherwise, if we only ena= ble the hash-based opcode and do nothing else, then we must disable key spe= nding later or else the opcode is useless. > > > >=20 > > > > So the two concepts are not completely independent. Adding hash-bas= ed signatures to tapscript necessitates a new opt-in output type that we ca= n standardize quantum-resistant wallets under. Similarly, adding a quantum-= resistant output type doesn't seem very useful without a quantum safe way t= o authorize spending. > > > >=20 > > > > =3D=3D=3D=3D=3D=3D=3D > > > >=20 > > > > At the risk of this thread further devolving into a debate around P= 2MR and P2TRv2... > > > >=20 > > > > > Our goal is to get as many wallets migrated as possible, which re= ally means focusing on the wallets that are likely to take the longest to m= igrate. > > > >=20 > > > > I can't speak for others, but my goal is to design and deploy a sec= ure and efficient soft-fork upgrade package so that myself and other bitcoi= n users may retain control of our bitcoins in a world where the future secu= rity of the ECDLP is uncertain. Encouraging adoption is a secondary goal wh= ich follows immediately if we design the upgrade well. > > > >=20 > > > > I personally don't see P2TRv2 as a suitable path towards this goal,= because it still depends on ECDLP. At best, P2TRv2 PROMISES to be quantum-= secure later, at the chaotic whim of the future Bitcoin community. Personal= ly, I would rather keep my coins on P2WPKH than on P2TRv2. No: If we are go= ing to have a PQ soft fork, it should be conclusive, self-contained, and re= quire no follow up. Otherwise, we haven't actually fixed the core uncertain= ty we need to address. > > > >=20 > > > > > That includes both "consumer" wallets which may be infrequently u= sed by people who bought a pile of bitcoin and touch it once every few year= s as well as those who are quantum-skeptical and will see no reason to upgr= ade until its urgent. > > > >=20 > > > > Low-frequency users aren't fee sensitive, almost by definition, so = I don't see them caring much about the minor witness size increase of P2MR = compared to P2TR. > > > >=20 > > > > As for quantum-skeptical users, I see no reason why they would migr= ate their coins to ANY quantum-resistant output type, whether P2TRv2 or P2M= R. To someone who today sees quantum computers as 100% FUD with zero room f= or doubt, they will see any PQ output type as a slightly worse version of w= hatever they use today. So I don't really understand why it would be so imp= ortant to encourage this class of user to migrate. They won't - not until t= heir world-view about the quantum threat changes. > > > >=20 > > > > If and when their attitude does change, then a few vbytes of overhe= ad compared to P2TR won't deter them - not with an existential threat motiv= ating them to migrate. If fees DO deter them, then they're probably an acti= ve high-frequency user like a miner or exchange, who can keep tabs on the s= ituation and continue to grind savings out of P2TR until the very last minu= te [^1]. > > > >=20 > > > > It is a mistake to compromise on long-term design choices [^2] to p= lease quantum-skeptics, because: > > > >=20 > > > > 1. If the quantum threat is indeed real, then sooner or later, whet= her 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 P2T= R while 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, witho= ut the 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 = corporate users are not fee-sensitive. If anything they are more fee-sensit= ive 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, bec= ause after key-spending is disabled, P2TRv2 is strictly worse than P2MR: It= would have worse performance and larger witnesses, more cryptographic comp= lexity, 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 = discourage 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 especi= ally 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 P2MR = 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 circumstanc= es 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 computer= . > > > > > > > > >=20 > > > > > Right, but I think we're focusing on two very different groups. T= he "holds significant quantities of > > > > > Bitcoin" group I'm much less worried about vs the "holds some qua= ntity of Bitcoin in an average > > > > > consumer Bitcoin wallet". The first group includes institutions, = funds, and people relatively "into" > > > > > bitcoin - they're paying attention, (hopefully) using decent wall= et software, holding funds in cold > > > > > storage, and aren't fee-sensitive. But this group is going to hav= e no problem migrating no matter > > > > > what the solution is - the institutions and funds camp can migrat= e in a few days in an urgent > > > > > scenario and the long-term holder with a significant portion of t= heir net-wroth in Bitcoin is also, > > > > > likely, paying reasonably close attention to Bitcoin and can reac= t quickly. > > > > > > > > >=20 > > > > > 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 lik= ely to take the longest to migrate. > > > > > That includes both "consumer" wallets which may be infrequently u= sed by people who bought a pile of > > > > > bitcoin and touch it once every few years as well as those who ar= e quantum-skeptical and will see no > > > > > reason to upgrade until its urgent. Importantly, the decisions he= re are 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" a= cross the ecosystem. The former may > > > > > get the migration process started, yes, but it does not ease the = future community's difficulties > > > > > materially - the slower-to-migrate coins will still be just as st= uck as before and just as much > > > > > Bitcoin will be available to steal by a theoretical CRQC. Thus, I= STM the focus *has* to be on > > > > > something that has minimal drawbacks - not losing the script poli= cy privacy of P2TR, low or no fee > > > > > overhead, etc. > > > > > > > > >=20 > > > > > Of course that isn't to say that P2MR might not also make sense i= n addition, but focusing only on > > > > > that misunderstands the goal. > > > > > > > > >=20 > > > > > Matt > > > > > > > > >=20 > > > > > -- > > > > > You received this message because you are subscribed to the Googl= e 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/b= itcoindev/6d075872-0db8-4e7b-ac2a-452624c991ad%40mattcorallo.com. > > > > > > > >=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+unsubscribe@googlegroups.com. > > > To view this discussion visit https://groups.google.com/d/msgid/bitco= indev/34cb87e2-4d4e-4403-91ce-d1f1328ddb98n%40googlegroups.com. > >=20 > > >=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/3E7B6DB3-7DF3-47F1-AA88-D0DC1CC9502D%40gmail.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/= h5gQ0PjtFheoHTlevAG3fXbYLqDDTzgHXbvdkF0_RRh-G4a8U24hIl4nth0Lv_wL9faydmQj9lO= _A08UmH9PjxKxyampfcCR6bfgJ1pBLME%3D%40proton.me. -----------------------35f4c370e33bf929654e1b2561948362 Content-Type: multipart/related;boundary=---------------------9666f7d7322ec5692711621d93c4d2a3 -----------------------9666f7d7322ec5692711621d93c4d2a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

So basically every P2TR is vulnerable, sinc= e script-path only enforcement relies on NUMS point?

Exactly. Unless we enact some future (contentious) sof= t-fork to disable key-path spending and possibly replace it with something = else like a commit/reveal or STARK-based rescue protocol, then every P2TR w= ould be vulnerable to a CRQC.

Conduit= ion, do you think P2MR is a good natural solution? Looks like the closest t= o Taproot logic, just removing the key-path spend.
<= /blockquote>

Absolutely. P2MR has all the advantages of P2TR's = script tree commitment structure, with none of the vulnerable cryptography.= It does have slightly larger witnesses than P2TR when using BIP340 key-spe= nding, but for script-path spending, P2MR is always more efficient than P2T= R.

=
But P2MR is not the only option - = As Matt has pointed out, we could also deploy a clone of P2TR with a new se= gwit version number, called P2TRv2. The only technical difference between P= 2TR and P2TRv2 is that P2TRv2 explicitly opts into a future soft fork that = disables key-spending, and so it should become quantum safe at an undefined future time. 
regards,
conduition
On Tuesday, April 14th, 2026 at 10:54 AM, thomas suau <tomeclair= @gmail.com> wrote:
Hi conduition, 
Ah yes, indeed NUMS is broken as well = I missed that. Big difference and big break. 

So basically every P2TR is vulnerable, since script-path only enforcement = relies on NUMS point? 
I=E2=80=99ve read that using a differ= ent generator wouldn=E2=80=99t help either, Schor solves the dlog directly = on the curve. Even a secret point would be broken? 

In that=E2=80=99s case P2TR is just quantum dead=E2=80=A6 

Conduition, do you think P2MR is a good natural soluti= on? Looks like the closest to Taproot logic, just removing the key-path spe= nd. 

Regards, 
Thomas 


On 14 Apr 2026, at 16:51, conduition <condui= tion@proton.me> wrote:

=EF=BB=BF
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 spen= d time =E2=80=94 but at the wallet level, no soft fork.
<= span>
CRQCs can spend NUMS point addresses with the key-s= pend path, even if nobody else can. So P2TR + NUMS is not equivalent to P2M= R in security.

A NUMS point is a point P produced by has= hing some fixed public data and finding a point on the curve with the resul= ting hash as an x-coordinate. For instance, BIP341 suggests using SH= A256 to hash the secp256k1 generator point. 

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

This process used to c= reate a NUMS point makes it unlikely for anyone to have the secret key of t= hat NUMS point, because we assume it is hard to find a collision between th= e hash function and secp256k1 point multiplication.

Quantum c= omputers 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 Shor's algo= to find that point's discrete log (secret key) with respect to the generat= or point G. Once they have it, they could key-spend from any&nb= sp;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= .

<publickey - conduition@proton.me - 0x474891AD.asc>

--
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/3E7B6DB3-7DF3-47F1-AA88-D0DC1CC9502D%40gmail.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/h5gQ0P= jtFheoHTlevAG3fXbYLqDDTzgHXbvdkF0_RRh-G4a8U24hIl4nth0Lv_wL9faydmQj9lO_A08Um= H9PjxKxyampfcCR6bfgJ1pBLME%3D%40proton.me.
-----------------------9666f7d7322ec5692711621d93c4d2a3-- -----------------------35f4c370e33bf929654e1b2561948362-- -----------------------e67c7bbdb89da7eb20c4b49d7f642b47 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== -----------------------e67c7bbdb89da7eb20c4b49d7f642b47-- --------b12707b7baec44b5f361d84717099017058a843039de962394ba073e32586b3c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmnekMIJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmdMfur3OMZ3Yzv3aJSUmHOC+chhlp14qAUPpo5P FgWrYhYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAACBQD/YR8csXShj9vIH3SO KKSEFmx1jEGD/O/lMkJGeTc8ozcA/0qr2eV8flLjFB02mhKeEBwkJ3s/x6J9 cyeI0KkK3moF =sYq1 -----END PGP SIGNATURE----- --------b12707b7baec44b5f361d84717099017058a843039de962394ba073e32586b3c--