From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 14 Apr 2026 08:54:49 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wCg6C-00036H-G9 for bitcoindev@gnusha.org; Tue, 14 Apr 2026 08:54:49 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-40ee506cf49sf9460091fac.2 for ; Tue, 14 Apr 2026 08:54:48 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776182083; cv=pass; d=google.com; s=arc-20240605; b=I+XrJSNYSmhpQDNOQ1zOMEfh4Xnombd1byG1oUHwJTE5KHfFeDf+7KYeTu28o5juXr 6G7uJOptC6SXCT6a/nwXDGxQgEja6tSDqoygjaPK+JQachrTS8M4t13yx8mten9rmcur snAv1GHd50V+VeBuMcMoR8OR5KlfGeXHogYy9mo0KuOvptlSPlDzsQrhGXY46wP1zgxC IFE17Hu64NO7GwYKGn+SUSBz7wcIxVFM+EwaCtN1K0A9Txz+TzjzVCkYOYfyswRMhqpb MkvI8yNUbtnI6Rzguf10iKQauXhCYJlYCvuXcbUoKWp4EBxERaTa9UP1Z2GDTMVL8FUI HcDw== 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:to:in-reply-to:cc:references :message-id:date:subject:mime-version:from:content-transfer-encoding :sender:dkim-signature:dkim-signature; bh=FT634EqvD58p9VWRaQwbMtLNwM1qMzUI7+utLjFn6SI=; fh=JHGXoHHtjKylAUjmcd0I48brV+/iHYx1udLIAAtJDko=; b=XN/ZN2KtFkyLVY8qhVZQS8gIT6gbt6+aR/wgT0m6tqRWIGyFdPL8L4CaCZ1mpehiNl nmrDHAFZ2Q5BGVFg9CxPhqqX0pk1YZCMkmAjQwEc6xnrSTBildWMzjqP3MpugAluqyju xb2Y0HmJg2L9C7msE4SROOeLll3CH8GYiLsvxNskD3oqXv1FA1/mLjezfV9edmgfvqBU FQ1LyUhhpkVfuK9UGApWSC66C3Fp87rBwfSIf8J0fke2EsuHiKNYs6qQlhoNIEFZCdSj 8X/0BlsPoq+7wwIe9zIF+7FBYykzzsVrXCOHsCvXoTICK1Oc8lFjp5RxBLhOOjgKPKmR M5gg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=qRAmsKIp; spf=pass (google.com: domain of tomeclair@gmail.com designates 2a00:1450:4864:20::32a as permitted sender) smtp.mailfrom=tomeclair@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776182083; x=1776786883; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:in-reply-to:cc:references:message-id:date :subject:mime-version:from:content-transfer-encoding:sender:from:to :cc:subject:date:message-id:reply-to; bh=FT634EqvD58p9VWRaQwbMtLNwM1qMzUI7+utLjFn6SI=; b=iRdYnVsxVVWzJUGraRnbX4f292dtYeOQ3ElDx369Bi6wRpKZylbqzW8a07MhWYdcJU 5BMHN2CjXIdMR6qCcHLHBir9lTthWT8RZEVpSs1qTCiWyG6TxwhFXc9PcLBq37MCDqQK fT5aI+BCg4qwm/sk00gEi6wkYHXcMpoMk0gExcX8I7DZn8reHE6QvFcDM2EUgn/42FZe PqK3XsyyHwjoICkaFFXplKlE2SWo9sNTwXYdEWAe/SbkURPQyhsCfCLH7K3aJ0XSYzPt naH2mp6Cj5b+mJ64+lRGjcjg639aYcaLHstWChP6ikJS1Y3NspqFBNidMcFkFf9Rn3Ll rqbw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776182083; x=1776786883; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:in-reply-to:cc:references:message-id:date :subject:mime-version:from:content-transfer-encoding:from:to:cc :subject:date:message-id:reply-to; bh=FT634EqvD58p9VWRaQwbMtLNwM1qMzUI7+utLjFn6SI=; b=b4g25g4+DFjIWfyPoCzWUE7Ch/8RWnVRUE9K2FphuHZhdaL5K5x/90fi+JcaIGUp1L oGLgBeYoWFyRnep168dhza/JRPc4km2xSkc59H4ig26YFQQpCGzjRYGqRIPi5WV/PnGE 5Xtad3YFXGC6wVHa7E6sm/uc0Fqp4gU9cGGty4V01xzb9affyzE8Czs7tz8o2W863pk1 QmPfh3tA2S9lnJ8G57QroVanm39Rr7DaWSS4eWnVUTHuHOLUnyYofJS7SP8AcT77g7Or tBf3uWV+Y24c4ULXCfJyQP+dgV9mvx8U3a9v3EvaSxkjySLYTImkXIN4d8iltq6auXH6 Ms4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776182083; x=1776786883; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:in-reply-to:cc:references:message-id:date :subject:mime-version:from:content-transfer-encoding:x-gm-gg :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=FT634EqvD58p9VWRaQwbMtLNwM1qMzUI7+utLjFn6SI=; b=G59oo/rfTCWiNYYOixgERX/8o1QMJAPnp+MIibUX7UJnfGjPeQJlil4Ejgj5vNa6Uh U/0vZHFOZIHL029cZgDDhMK/GKo8/XVURvdVmQRNiZD9PDd0bdhW+QcmYeSdWcbqWqt1 ieBM0Ilz8AunO4FVc5j62DYCD1RnhquZYkr6k/z5suSl4Scyvq5XrOnPubQgDwJ1dFhs NPnkjglxiCk1aQkCWUYwiim+IGcW+qUiX/x0DfzendvzL8dYq2mZPwC2nz8829K1T/5+ Xhbcmx1buQvrGO0vfWNovYISk6vbhy7asRkJGijghGxIgzo6N2Hu5J4k0EGexawWTodF iwZg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AFNElJ//XIrWfK1DaQvMRt3ko5gb1zkw8o2kACm4Jc6Bia/+X2qMXUZ1JFhpcyAd27psuHtjzqeVD+/Nfirj@gnusha.org X-Gm-Message-State: AOJu0Yz50fK14ezcnm4Om82Q6g+Lw9365eoiUOZQ1mdJLmNEuhNbQpHg 1n5BASYERawL5OECFD35lmqEPWTZxnydAXwkheEi79B7iI6w1mUy9K1s X-Received: by 2002:a05:6871:c91a:b0:2e9:93c6:6e4a with SMTP id 586e51a60fabf-423e11b9a91mr10194864fac.38.1776182082411; Tue, 14 Apr 2026 08:54:42 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKwqB6dmWbm+CRZWi5ZUg84JGt7wz2TDdOyzg066I3pAQ==" Received: by 2002:a05:6870:a092:b0:422:c0f1:a9e4 with SMTP id 586e51a60fabf-423dd0223a3ls2676731fac.0.-pod-prod-08-us; Tue, 14 Apr 2026 08:54:37 -0700 (PDT) X-Received: by 2002:a05:6808:c2b4:b0:45c:881c:e0c0 with SMTP id 5614622812f47-4789f905c23mr10225916b6e.47.1776182077491; Tue, 14 Apr 2026 08:54:37 -0700 (PDT) Received: by 2002:a05:600c:8a18:b0:488:963a:630a with SMTP id 5b1f17b1804b1-488f07ce094ms5e9; Tue, 14 Apr 2026 08:50:47 -0700 (PDT) X-Received: by 2002:a05:600c:3107:b0:488:8b52:f7de with SMTP id 5b1f17b1804b1-488d6860930mr214323745e9.12.1776181845504; Tue, 14 Apr 2026 08:50:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776181845; cv=none; d=google.com; s=arc-20240605; b=I+FCWU17+WiGtkKUwdqY8V7/mdbSAjiX1XxCiHah4TwxkQdyWSM/2DQCmE10Rf56m7 tmiOQWshD6vzlpz58MIJtA0qWcpraqzeKN+1L+MHuoqbnjnHKN2VGNj+HOBlZM/gPVKr rOTr49aLzNrOnOZzxOxEXaep8TS0/ieIww54DH/BvpaFvQNG+quFJI5+PCWjbB7meUyj IbyISjyNE2puhRgn2l3Vsp2erSovmYMxg4zd040+ybWKot48O3PycBNSrWyqtApQijmm RfXLzttcpJAB9RaUNSV0RUMmHOdeuCowQWVrZIU/D82pnpFRvBBBCVbS/997HLmUGNPx 96PA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:dkim-signature; bh=x+FX0YIrXYhtCl7ru8nvuW4zPXRXAapnxRnj5QKfJAE=; fh=lis+KD+NNIUj1x3QEUx4cEY7p+des9rqQA3n6aEnjZc=; b=JFmUBBb4RZ+oO6gNx6IFzaTwgI0563CQkLRzcgZVaxG+0klq6t5+ijuvZJr381H5yG HrMyuK9zXXga2YIghAWnp9LGC2XxG6D41cstEjLC3MhukFNAH5QqPjBbbqZLfi1zRKKy 5Q/H02SZ+aAhm2jxSB2xxHBA6NaB5gXabl2Yv7Cm+PlTg/DgchB+wZB2qepLS/1dCTvg 0cnIescvejTV7wxwYuLlWFQ6C1hxEGkLXJO9uwM2dPBvbKbSXDQXGVG4ImCFgTFlB21p rD6xjjpp5sfcyunafMZNt5udNUtxLd4YG2XEBY4KNVZWxtuDnZQbUPixwN8C+S3KIp1N q98w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=qRAmsKIp; spf=pass (google.com: domain of tomeclair@gmail.com designates 2a00:1450:4864:20::32a as permitted sender) smtp.mailfrom=tomeclair@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com. [2a00:1450:4864:20::32a]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-488ee019c79si443205e9.1.2026.04.14.08.50.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Apr 2026 08:50:45 -0700 (PDT) Received-SPF: pass (google.com: domain of tomeclair@gmail.com designates 2a00:1450:4864:20::32a as permitted sender) client-ip=2a00:1450:4864:20::32a; Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-488af9fdaa7so40298515e9.1 for ; Tue, 14 Apr 2026 08:50:45 -0700 (PDT) X-Gm-Gg: AeBDieuuKInn2Dyv3XS0evUQEN6/ZLzjL3Go9ceTqTLedr5t7AcsFI5rDyqJQE018MB wuNvTmesglfYntlF5ZhyWGvnVtRATLIwqcQkjkM3pzsNvEm6jPE8I33vzW74qbPuPjkS31VEBaZ XzQNL6GKqPNzidtmXt+KbdjFCUXerSzrTswt4zIjy5Xbpzf9S+QDTgD70dMPr4O9FrD/a4I+gkY /Ns20BOywQZZOWBsn/blbLplbKgmKUe5zxoTrpkVcdQNmibF6PMjDneRgL72OaCnrnPvWrzYJI3 ICWR6GNicT9Q9+KnwHfinymz7xcg5aCHsdHw6JcH4mFVFxeOobiN+5Of0jKnmp3q3JwmZYsIXn1 /Ey+oalENq6HoqwE8XkDuwQWqgoJINgzZECniT7X18a31aECiqkzmkERQ6AvvsPuuhAnczBLfin mvgssHv+tCwCPvBblcwFgs/TF7Fbxd6uWDt+eUM02AF7eI333u2erY X-Received: by 2002:a05:600c:628b:b0:487:1fbf:e0bb with SMTP id 5b1f17b1804b1-488d680851fmr238283955e9.6.1776181844278; Tue, 14 Apr 2026 08:50:44 -0700 (PDT) Received: from smtpclient.apple ([2a01:e0a:2f0:5440:302b:3c97:2298:32a0]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488ede1513csm66057615e9.2.2026.04.14.08.50.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Apr 2026 08:50:43 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E9DBAAD9-5602-487C-AE55-0BDAF88129DF Content-Transfer-Encoding: 7bit From: thomas suau Mime-Version: 1.0 (1.0) Subject: Re: [bitcoindev] In defense of a PQ output type Date: Tue, 14 Apr 2026 17:50:33 +0200 Message-Id: <3E7B6DB3-7DF3-47F1-AA88-D0DC1CC9502D@gmail.com> References: Cc: bitcoindev@googlegroups.com In-Reply-To: To: conduition X-Mailer: iPhone Mail (23D8133) X-Original-Sender: tomeclair@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20251104 header.b=qRAmsKIp; spf=pass (google.com: domain of tomeclair@gmail.com designates 2a00:1450:4864:20::32a as permitted sender) smtp.mailfrom=tomeclair@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: 1.8 (+) --Apple-Mail-E9DBAAD9-5602-487C-AE55-0BDAF88129DF Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi conduition, 
Ah yes, indeed NUMS is broken as well I = missed that. Big difference and big break. 

S= o basically every P2TR is vulnerable, since script-path only enforcement re= lies on NUMS point? 
I=E2=80=99ve read that using a differen= t 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 
<= div>
Conduition, do you think P2MR is a good natural solution= ? Looks like the closest to Taproot logic, just removing the key-path spend= . 

Regards, 
Thomas 


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

=EF=BB=BF
Hi Thomas,

I just want to clarify a misconception in your email th= ere:
<= br>
In the meantime, wallets can already construct P2TR with a NUMS i= nternal key to force script-path spending. Same effect as P2MR =E2=80=94 ou= tput 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-spe= nd path, even if nobody else can. So P2TR + NUMS is not equivalent to P2MR = in security.

A NUMS point is a point P produced by hashi= ng some fixed public data and finding a point on the curve with the resulti= ng hash as an x-coordinate. For instance, BIP341 suggests using SHA2= 56 to hash the secp256k1 generator point. 

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

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

<= div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Quantum comp= uters 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 generator = point G. Once they have it, 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= .

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

--
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/3E7B6= DB3-7DF3-47F1-AA88-D0DC1CC9502D%40gmail.com.
--Apple-Mail-E9DBAAD9-5602-487C-AE55-0BDAF88129DF--