From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 14 Apr 2026 06:54:52 -0700 Received: from mail-qv1-f55.google.com ([209.85.219.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wCeE7-0001pu-G4 for bitcoindev@gnusha.org; Tue, 14 Apr 2026 06:54:52 -0700 Received: by mail-qv1-f55.google.com with SMTP id 6a1803df08f44-8ac04b2fc4esf150577496d6.0 for ; Tue, 14 Apr 2026 06:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1776174885; x=1776779685; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=ISiZycnpEB4o/zftqE0+elO0ALvJZiO+K2FDhl/jHp0=; b=qigB/6OgNvWPUSx2i4GTXirSOKMTgHhHBmAHoOjBgnsDWApKGyjpRdKkKn3JvgOUFI mYAKC7B9StCpzvrQL4wEATLjDKdGCPvy03HE//mibxCmFcSPixoaB/Kt98Eb7X14bJrt phO9n+ihP4jTvVR4SNcsstbDbw/AqNOk3KsLcIF3t3DqZrvUinR+hJw5PHxvdP4fa4s4 hTfCerfFWxBCOyU0sdUz77ddQp1mq1G8z9wpU9OBUQPDw/+fgtmm15QeEsatEIEBFI40 gXQ+Mjl8KOHcysGIIgWcvB9VVfxuHM9QAyl4gwWOIzOcqgzRpWo4vkP3EfLaHMGMUCt1 eW2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776174885; x=1776779685; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=ISiZycnpEB4o/zftqE0+elO0ALvJZiO+K2FDhl/jHp0=; b=psMIHcIGPFS/CP7BDnJKGfNFhAwP0Jl0wiSLMqLkOLycn+hM0hiktNfqY6mg97Sl+u h4v8GQZeLyd1jiEZZ56YPPEwNUq065sI9TzG/CmUkza3S6CGfbfTbJMqSSZAeKqfdvca cHRZQVpgdviPKSvX7Td9pwdFuBPnziTaJhH1fg39/JHWs4jCli3tvYpjuGqSdnEecxNy Q0aBpOEgPr/bbpjw9FHX2VvrJJ3v9dO2l1s80V8CeHX6JPYmh6th0slzJgQTegd/BnZf mz3I6o8Po+amP8/yZiDz0AxQNru0CIWbwMQi8dyZ0vlUMwah8/2R+rU2OmJJ+RgxantG eQ+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776174885; x=1776779685; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=ISiZycnpEB4o/zftqE0+elO0ALvJZiO+K2FDhl/jHp0=; b=JotWa2z47ulyk7nx0ATL5lCgUKDiGnHONh6qFX3n+dRzSoWWJ1sftcIXrVf+5WG6Qt g70PMXYJ2Ed5VyW4o8VyRxWhm9xe/nfGcuMaDlEG/dlktcWvP3kgiJKf+aF94w/4dEwe NUOMqLhtudiiau9J8TY48MTMk9hjylidZ/BNt0O4NBi6NTRj4QNIufGntWv+CtdhnHn1 aGtRf/VBDBzrT3Tx/nu72BC2bcI13XNJRt6ao5iqUu6kXJJ+UFgL1EuX1ndUKwByAyHM FY5t1K6QP54FkU2+GlFNm0MIJOg8TV1SSPnt0d7Q2+aaI0ubwVq9TQTfJrJVfyfBpkDC /crw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ+WLuqJwjZiFTyrqLQILUP8G1oIdMvCkHo4B6yLblFxDyeJ3CDx/cWhbXzEX9Gpi1eXEoT3V17HS0r8@gnusha.org X-Gm-Message-State: AOJu0YzRimubuzRbYjYekWNtqjtXN6Ea/A4eJEnCYQLjPbAVmRF80N3t mE+qvQHcjtsjqGIn6VjcoYAM8P8AGR+lZSrzK/7kERxtDzmCFCnxGyIM X-Received: by 2002:a05:6214:4e14:b0:89c:4f67:8d17 with SMTP id 6a1803df08f44-8ac860ba64emr253154876d6.8.1776174885053; Tue, 14 Apr 2026 06:54:45 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiLaa13bcUCCN+mFVWFfm/OmGVCXAqAl2LWjw+WwmIRGng==" Received: by 2002:a05:6214:5015:b0:89c:6948:e1e5 with SMTP id 6a1803df08f44-8ac8336f02dls82317176d6.0.-pod-prod-01-us; Tue, 14 Apr 2026 06:54:39 -0700 (PDT) X-Received: by 2002:a05:6214:5786:b0:89c:4ea7:a70f with SMTP id 6a1803df08f44-8ac861b62famr271677876d6.14.1776174878992; Tue, 14 Apr 2026 06:54:38 -0700 (PDT) Received: by 2002:a05:690c:d91:b0:7b3:443:26a9 with SMTP id 00721157ae682-7b304434911ms7b3; Tue, 14 Apr 2026 05:36:21 -0700 (PDT) X-Received: by 2002:a05:690c:19:b0:7b2:6177:2af1 with SMTP id 00721157ae682-7b2617737f9mr93395307b3.31.1776170180859; Tue, 14 Apr 2026 05:36:20 -0700 (PDT) Date: Tue, 14 Apr 2026 05:36:20 -0700 (PDT) From: Thomas Suau To: Bitcoin Development Mailing List Message-Id: <34cb87e2-4d4e-4403-91ce-d1f1328ddb98n@googlegroups.com> In-Reply-To: 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> Subject: Re: [bitcoindev] In defense of a PQ output type MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_131034_577596300.1776170180427" X-Original-Sender: tomeclair@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_131034_577596300.1776170180427 Content-Type: multipart/alternative; boundary="----=_Part_131035_1004809532.1776170180427" ------=_Part_131035_1004809532.1776170180427 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Antoine, list, +1 on separating PQ availability from the freeze question. conduition put it well =E2=80=94 adding a PQ opcode to tapscript and adding= a new=20 output type aren't independent decisions. A PQ opcode alone doesn't remove= =20 the key-path, so the output key remains a bare curve point on-chain,=20 vulnerable at rest. We'd still need to bump the witness version to disable= =20 it. P2MR (BIP 360) does exactly this without requiring any new opcode, and= =20 PQ opcodes can come later through OP_SUCCESSx. Both are needed, I think the= =20 question is more about sequencing =E2=80=94 P2MR addresses long exposure wi= th a=20 smaller consensus change. In the meantime, wallets can already construct P2TR with a NUMS internal=20 key to force script-path spending. Same effect as P2MR =E2=80=94 output key= becomes=20 unspendable, signing key stays hash-protected until spend time =E2=80=94 bu= t at the=20 wallet level, no soft fork. You lose key-path efficiency, and it requires= =20 proper key rotation (unique HD derivation per script leaf, not just per=20 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, whether=20 > P2MR (360), P2TRv2 or just P2TR. There are strong arguments for each. But= =20 > none of that has any bearing on whether we add hash based signatures to= =20 > tapscript. We have to add hash based signatures to tapscript first no=20 > matter what output type we want! > > Apologies, there must be some mixup. I think we agree with each other=20 > about this - adding a new PQ opcode to tapscript is always going to be=20 > necessary, 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= =20 > output type in order to disentangle opt-in PQC opcodes from any=20 > confiscatory soft fork that disables P2TR key-spending. Otherwise, if we= =20 > only enable the hash-based opcode and do nothing else, then we must disab= le=20 > key spending later or else the opcode is useless. > > So the two concepts are not completely independent. Adding hash-based=20 > signatures to tapscript necessitates a new opt-in output type that we can= =20 > standardize quantum-resistant wallets under. Similarly, adding a=20 > quantum-resistant output type doesn't seem very useful without a quantum= =20 > safe way to authorize spending. > > =3D=3D=3D=3D=3D=3D=3D > > At the risk of this thread further devolving into a debate around P2MR an= d=20 > P2TRv2... > > > Our goal is to get as many wallets migrated as possible, which really= =20 > means focusing on the wallets that are likely to take the longest to=20 > migrate. > > I can't speak for others, but my goal is to design and deploy a secure an= d=20 > efficient soft-fork upgrade package so that myself and other bitcoin user= s=20 > may retain control of our bitcoins in a world where the future security o= f=20 > the ECDLP is uncertain. Encouraging adoption is a secondary goal which=20 > follows immediately if we design the upgrade well. > > I personally don't see P2TRv2 as a suitable path towards this goal,=20 > because it still depends on ECDLP. At best, P2TRv2 PROMISES to be=20 > quantum-secure later, at the chaotic whim of the future Bitcoin community= .=20 > Personally, I would rather keep my coins on P2WPKH than on P2TRv2. No: If= =20 > we are going to have a PQ soft fork, it should be conclusive,=20 > self-contained, and require no follow up. Otherwise, we haven't actually= =20 > fixed the core uncertainty we need to address. > > > That includes both "consumer" wallets which may be infrequently used by= =20 > people who bought a pile of bitcoin and touch it once every few years as= =20 > well as those who are quantum-skeptical and will see no reason to upgrade= =20 > until its urgent. > > Low-frequency users aren't fee sensitive, almost by definition, so I don'= t=20 > see them caring much about the minor witness size increase of P2MR compar= ed=20 > to P2TR. > > As for quantum-skeptical users, I see no reason why they would migrate=20 > their coins to ANY quantum-resistant output type, whether P2TRv2 or P2MR.= =20 > To someone who today sees quantum computers as 100% FUD with zero room fo= r=20 > doubt, they will see any PQ output type as a slightly worse version of=20 > whatever they use today. So I don't really understand why it would be so= =20 > important to encourage this class of user to migrate. They won't - not=20 > until their world-view about the quantum threat changes. > > If and when their attitude does change, then a few vbytes of overhead=20 > compared to P2TR won't deter them - not with an existential threat=20 > motivating them to migrate. If fees DO deter them, then they're probably = an=20 > active high-frequency user like a miner or exchange, who can keep tabs on= =20 > the situation and continue to grind savings out of P2TR until the very la= st=20 > minute [^1]. > > It is a mistake to compromise on long-term design choices [^2] to please= =20 > quantum-skeptics, because: > > 1. If the quantum threat is indeed real, then sooner or later, whether by= =20 > 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,= =20 > then everyone becomes a quantum-skeptic, and we can all return to P2TR=20 > while the new PQ output type slowly fades into obscurity. > > Note in scenario (2), P2MR actually still has utility: P2MR can be used a= s=20 > a more-efficient way to construct script-path-only addresses, without the= =20 > 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=20 > corporate users are not fee-sensitive. If anything they are more=20 > fee-sensitive than Joe-Average - When you conduct thousands of transactio= ns=20 > per day, 10% larger witnesses could mean a lot. > > [^2]: P2TRv2 is a compromise in the long-term compared to P2MR, because= =20 > after key-spending is disabled, P2TRv2 is strictly worse than P2MR: It=20 > would have worse performance and larger witnesses, more cryptographic=20 > complexity, and it commits us to carry legacy ECC as cruft well into the= =20 > future.=20 > > > > On Monday, April 13th, 2026 at 9:23 AM, Matt Corallo < > lf-l...@mattcorallo.com> wrote: > > >=20 > > >=20 > > > On 4/10/26 8:20 PM, Ethan Heilman wrote: > > > > IMO even something like P2MR's additional cost will strongly=20 > discourage adoption. > > > > > > I don't agree. > > > > > > Over time as quantum attacks become a bigger and bigger concern for= =20 > holders, wallets will want to > > > show that they can offer security against CRQCs. This is especially= =20 > true for wallets focused on high > > > value Bitcoin outputs. Even if someone thinks there is only a 2%=20 > chance they lose all their Bitcoin > > > because of a quantum computer, that 2% chance will keep them up at=20 > 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= =20 > 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 P2M= R=20 > has lower fees than P2TR. > > > > > > It is hard to imagine someone holding significant quantities of=20 > 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. The=20 > "holds significant quantities of > > Bitcoin" group I'm much less worried about vs the "holds some quantity= =20 > of Bitcoin in an average > > consumer Bitcoin wallet". The first group includes institutions, funds,= =20 > and people relatively "into" > > bitcoin - they're paying attention, (hopefully) using decent wallet=20 > software, holding funds in cold > > storage, and aren't fee-sensitive. But this group is going to have no= =20 > problem migrating no matter > > what the solution is - the institutions and funds camp can migrate in a= =20 > few days in an urgent > > scenario and the long-term holder with a significant portion of their= =20 > net-wroth in Bitcoin is also, > > likely, paying reasonably close attention to Bitcoin and can react=20 > quickly. > >=20 > > > Because those groups are quite capable of reacting quickly, I don't=20 > really buy that they're the > > "target market" for short-term PQC in Bitcoin. Our goal is to get as=20 > many wallets migrated as > > possible, which really means focusing on the wallets that are likely to= =20 > take the longest to migrate. > > That includes both "consumer" wallets which may be infrequently used by= =20 > people who bought a pile of > > bitcoin and touch it once every few years as well as those who are=20 > quantum-skeptical and will see no > > reason to upgrade until its urgent. Importantly, the decisions here are= =20 > 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* t= o=20 > "give people an option to > > migrate" but rather to "make use of the PQC scheme the default" across= =20 > the ecosystem. The former may > > get the migration process started, yes, but it does not ease the future= =20 > community's difficulties > > materially - the slower-to-migrate coins will still be just as stuck as= =20 > before and just as much > > Bitcoin will be available to steal by a theoretical CRQC. Thus, ISTM th= e=20 > focus *has* to be on > > something that has minimal drawbacks - not losing the script policy=20 > privacy of P2TR, low or no fee > > overhead, etc. > >=20 > > > Of course that isn't to say that P2MR might not also make sense in=20 > addition, but focusing only on > > that misunderstands the goal. > >=20 > > > Matt > >=20 > > > -- > > You received this message because you are subscribed to the Google=20 > Groups "Bitcoin Development Mailing List" group. > > To unsubscribe from this group and stop receiving emails from it, send= =20 > an email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/6d075872-0db8-4e7b-ac2a-4526= 24c991ad%40mattcorallo.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 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. ------=_Part_131035_1004809532.1776170180427 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Antoine, list,

+1 on separating PQ availability from the free= ze question.

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 doesn't remove the key-path, so the output key remains a ba= re curve point on-chain, vulnerable at rest. We'd still need to bump the wi= tness version to disable it. P2MR (BIP 360) does exactly this without requi= ring any new opcode, and PQ opcodes can come later through OP_SUCCESSx. Bot= h are needed, I think the question is more about sequencing =E2=80=94 P2MR = 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=C2=A0:
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 t= o authorize 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 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.

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 uncer= tainty we need to address.

> That includes both "consumer" wallets which may be infre= quently 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 reaso= n to upgrade until its urgent.

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 P= 2MR compared 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 imp= ortant to encourage this class of user to migrate. They won't - not unt= il 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 motiv= ating them to migrate. If fees DO deter them, then they're probably an = active high-frequency user like a miner or exchange, who can keep tabs on t= he situation 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 = 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.

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



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

>=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 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 circu= mstances 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 co= mputer.
>=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 "h= olds some quantity of Bitcoin in an average
> consumer Bitcoin wallet". The first group includes institutio= ns, funds, and people relatively "into"
> bitcoin - they're paying attention, (hopefully) using decent w= allet 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.
>=20

> Because those groups are quite capable of reacting quickly, I don&= #39;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 infre= quently 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. Importantly, the decisions her= e 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 *n= ot* to "give people an option to
> migrate" but rather to "make use of the PQC scheme the d= efault" across 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.
>=20

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

> Matt
>=20

> --
> You received this message because you are subscribed to the Google= Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, = send an email to bitcoindev+...@= googlegroups.com.
> To view this discussion visit https://g= roups.google.com/d/msgid/bitcoindev/6d075872-0db8-4e7b-ac2a-452624c991ad%40= mattcorallo.com.
>=20

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