From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 12 Feb 2026 10:41:43 -0800 Received: from mail-oa1-f58.google.com ([209.85.160.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vqbdG-0001dq-Ae for bitcoindev@gnusha.org; Thu, 12 Feb 2026 10:41:43 -0800 Received: by mail-oa1-f58.google.com with SMTP id 586e51a60fabf-40ed781f705sf894483fac.0 for ; Thu, 12 Feb 2026 10:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1770921696; x=1771526496; 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=d+ZYtUmHgZ6QpE2ggOyIM19caZmEKpdJIOb00bMiqmE=; b=SYhEisIJg7+qKFmessruOSXYuSF8Y9lxB7a8swVlwjQ5GsFLwgDP1dTqF6KYuztZBM KLhMNq06Wm0vlHDKhvVofkyY4AnwxzZQB93vAHb/NiIHgigYlIijoxH331P31SkUPpH2 0/De9unlgSftNXofnUxwcwewHAm4oLut4/UV3CmCqAooVI729N0muM5Qf8GaD/f5TUXk 7xGDTeFqCTPPJW8C/eqFLzIZV+fZlTv7zrwZP81GXcl0gsEt9zS2wR4SlPo+KSFhVBbe K6UkLzG37aNf/wnB+tnoq1Y5hCs4ifyi/PF2E0QdmrAewoo3hvRxAHN8wFnPCH2b0i3X s/rA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770921696; x=1771526496; 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=d+ZYtUmHgZ6QpE2ggOyIM19caZmEKpdJIOb00bMiqmE=; b=MRZSJD1sQEbmtVIxln4TpfNWCZzTh7ZcFeppI0JKkPsYKKLBprbBBqwSlHNSW+RG17 S2Tv4i5J9l9Jlmg3kRgd03zPqVPjIMCZRHU/y3oOD/oyvQ/MEZIJn3Q6ob376myeOz3+ mpTUOPBqsbjhMH+MVLLtXCoompXzHzUTHB1CAG128e+G02bK4QbVPA1mDp1KdfOO36/w R/90/Sm8Qg6FxKCX4+2LZQscFsDB6JQIfiYzGJbiIKZQGiYbxmRkvLNH6vXWGl2/qJBB OfBGZZzW6p0dRrlJ/dLy96zUNP/+nys0x2v/tdqvJDkY+b19ToCeVwIrfu4YpW6CTMBP 3nCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770921696; x=1771526496; 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=d+ZYtUmHgZ6QpE2ggOyIM19caZmEKpdJIOb00bMiqmE=; b=vU573BpAsukYst94pmwQCo4HjZpheCaGxCcI4nLPAZwV7Nax6nNau4rPZaa1cbZswV DkFXO70AcYwRPJU0187/i3XYbEDZO2P0ozFXGKjUEUl09VBKONdyxXrwE4vsMT3Ju2CU dxQ1wcvNbE2IcR7YHr56MkgSbruZBm1UTdIdTIBTMMjQCsYSgwDRGV7zhmQE12gQpK/R j/XnVYpSvHnnAuZDNGy5bOD5njeRqQ0Dh+VlK+Of9rlBgRNxn2Cb9MQy9EY2kQX9ywqe jQKH5oS72C4x0m4UemGuaYipZ1WOp8srINu5Fn8p/XO8ogCR9P/KiGuv6FJb6fhHGT53 DCeA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXlM4uhXsEGOrCyzLOq12EQCA+wrN/2yKcvZu8raAazKpEHqoS4MHtut+W6dVaosCTGJGclsE4sZOOq@gnusha.org X-Gm-Message-State: AOJu0Yx+hobjdFevjCF1BXHghxlfSVQ4TZk4vDYl0Gf/pyrdqsNM9Qsk 5SD5rCd94ksyr+eom8MR7qZc7dtLViegTxqiJRItqGn/88t4XkzV2gUT X-Received: by 2002:a05:6870:658d:b0:409:6862:aba5 with SMTP id 586e51a60fabf-40ee9890ffamr214968fac.25.1770921696306; Thu, 12 Feb 2026 10:41:36 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+GY1knflgL/00eg7DoPbYdPSi0/dWsCMHzH6dAxijYHFw==" Received: by 2002:a05:6870:b292:b0:409:4c04:fab5 with SMTP id 586e51a60fabf-40edbfae595ls471012fac.2.-pod-prod-05-us; Thu, 12 Feb 2026 10:41:32 -0800 (PST) X-Received: by 2002:a05:6808:199a:b0:45e:bfe0:21f2 with SMTP id 5614622812f47-4637b680dddmr2116510b6e.10.1770921692399; Thu, 12 Feb 2026 10:41:32 -0800 (PST) Received: by 2002:a05:690c:3101:b0:796:6bfb:cf56 with SMTP id 00721157ae682-7966bfbd7eems7b3; Thu, 12 Feb 2026 07:35:32 -0800 (PST) X-Received: by 2002:a05:690c:399:b0:794:fcd9:4aa1 with SMTP id 00721157ae682-7973768b20dmr28973307b3.69.1770910530925; Thu, 12 Feb 2026 07:35:30 -0800 (PST) Date: Thu, 12 Feb 2026 07:35:30 -0800 (PST) From: Alex To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <1f0ebca9-2d23-44f9-8e6d-aaea99a832e3@mattcorallo.com> References: <22073a56-1cbf-4ba9-a2ea-46c621d4619c@mattcorallo.com> <1f0ebca9-2d23-44f9-8e6d-aaea99a832e3@mattcorallo.com> Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_87822_1512002138.1770910530525" X-Original-Sender: alexhultman@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_87822_1512002138.1770910530525 Content-Type: multipart/alternative; boundary="----=_Part_87823_617333437.1770910530525" ------=_Part_87823_617333437.1770910530525 Content-Type: text/plain; charset="UTF-8" > wallets aren't going to have a lot of incentive to adopt technologies that make things marginally more expensive. This claim is not rooted in reality. We literally just now saw Trezor market their Safe 7 as Quantum Ready and they had a major ad campaign specifically for this. There is major incentive for wallets to "sell" the quantum threat as a problem to fix, and therefore sell more wallets or claim compliance to gain market share. The quantum threat is mainstream. Retail knows about it, talks about it all the time. > many bitcoiners writing off the quantum threat Yes because psychologically, the most successful Bitcoiners are those who never reacted to any FUD and therefore never sold. And so they are essentially naturally selected by their history of never reacting to FUD. We've basically evolved the most non-reactant people and so obviously they are not going to react to the quantum threat because why would they change their strategy of never reacting if it worked so well so far? torsdag 12 februari 2026 kl. 16:01:27 UTC+1 skrev Matt Corallo: > > > On 2/11/26 5:57 PM, Ethan Heilman wrote: > > > For what its worth I do not see a scenario where a decision ultimately > made by the market will > > pick the fork side with materially, say 5-10x higher, supply, over the > side with lower supply... > > > > Completely agree, the incentives favor lower supply. I wouldn't want to > count on it happening and > > even if it does happen the freeze fork might not freeze P2TR. According > to the 2025 chaincode report > > [0] P2TR represents only 0.75% of total supply. > > I believe we're talking past each other, then. This was a side note - as > Jonas mentioned it seems > reasonable that a P2TR-based QC signature validation opcode could come > with an on-chain signaling > bit (i.e. a "Taproot V2" that is functionally identical but indicates the > presence of a QC signature > script path available). > > > > ~all wallets today use seedphrases, which could still be spent with a > ZK proof-of-seedphrase :). > > > > I'm all for putting ZKPs in consensus, but it seems unlikely to me that > it will happen. > > We just agreed that its highly likely that insecure spend paths are > disabled. I do not remotely see > how such an action could occur if the result is that a large number of > coins are seized. The only > viable approach way for that is to allow seedphrase-based wallets to > retain access. > > > It is better > > to make Bitcoin safe than promise safety that requires a future hardfork. > > There is no hardfork required here. > > > This is especially true > > since as you point out lower supply is incentivized, so a soft fork that > freezes coins would be > > fighting an uphill battle. > > I'm confused by this comment - a soft fork that disables insecure spend > paths to avoid them being > stolen is likely going to have a very easy time, not "fight an uphill > battle"? > > > > Hell, *any* PQ soft fork is going to see limited adoption in "consumer > wallets" until its > > urgent, hence why I think the community will be basically forced to > disable insecure spend paths and > > only > > allow spends via ZK proof-of-seedphrase. But at least something that > doesn't also 10x > > transaction costs might reasonably be adopted by default by wallets that > don't use seedphrases like > > Bitcoin Core. > > > > I disagree. If we get P2MR and SLH_DSA/SHRINCS the wallets can use > quantum-safe outputs (Schnorr OR > > PQ) with Schnorr as the default spend. The wallets can market themselves > as quantum safe. > > This flies in the face of the last 15 years of experience with Bitcoin > wallets. Yea, it sounds > great, but we've got 15 years of experience showing that wallets only > adapt when they go out of > business/stop being maintained and get replaced with new wallets (which > often ship with the latest > technology). Worse, many bitcoiners (maybe rightfully, maybe not) entirely > write off the quantum > threat - all the more reason they will simply not adopt any changes. > > > The cost > > in transaction fees to a user is small, a 1 input P2MR transaction would > only be 37 bytes larger > > when compared with a 1 input P2TR transaction. Those 37 bytes are in the > witness, so the real cost > > is ~10 vbytes. > > Apologies, I had understood the P2MR proposal to only feature PQC-based > schemes, rather than also > offering schnorr as an option, leading me to incorrectly conclude it would > be drastically more > expensive, rather than marginally so. > > Still, I think my point stands - in the face of many bitcoiners writing > off the quantum threat, > wallets aren't going to have a lot of incentive to adopt technologies that > make things marginally > more expensive. > > Worse, there's no real advantage here over just doing in the taproot key > path - because of address > reuse a wallet relying on P2MR + schnorr anyway will ~always have its > public key revealed so we > might as well continue relying on P2TR to save the 37 witness bytes and > get the same result (that > wallets can do something cheap with "just" a key derivation change and > explicitly opt in to a future > soft fork which disables the then-insecure spend paths). > > > Yes, if Q-day happens, time passes and then quantum computers become > powerful enough to perform > > short-exposure attacks, anyone needing to move their coins to an output > have to pay fees for an > > additional 8,000 bytes (SLH_DSA) or 324 bytes (SHRINCs). This is still > better than a PQ ZKP proof of > > the seed which would be between 20,000 to 120,000 bytes and more likely > to have a security flaw than > > SLH_DSA. > > Yep, I'm not proposing at all that we do nothing because a ZKP of > seedphrase is an option, rather we > should add support for SHRINCS and encourage wallet adoption. But at the > same time we should > understand that we're incredibly unlikely to see the kind of adoption in > time to avoid the need to > do something like a ZKP of seedphrase when the time comes. > > This is also probably the least interesting point of contention, FWIW - > this is a decision for a > future bitcoin community, not a decision for us to make today. > > > If efficient quantum signatures or compression techniques are developed, > we can and should adopt > > them. If they are efficient enough, they can become the default. This > proposal is designed to keep > > funds safe in the intermediate period while better techniques are > developed to cover the tail risk > > where Q-day happens before the technology we need to completely ready. > > Yep, we absolutely agree! I just don't see a reason to do P2MR over just > utilizing P2TR (or maybe > P2TRv2). > > > > No it doesn't - it requires a soft fork when the risk is imminent, but > it happening somewhat > > before that time is okay too. > > > > We might wait too long and misjudge the risk and Q-day happens before > the soft fork activates? What > > happens if freeze fork is activated but then 3 years pass and it looks > like a CRQC isn't going to > > happen after all? Now people who had their coins frozen are pushing to > undo the soft fork. > > > This approach carries too much risk from uncertainty and it was "the > plan" it signles that Bitcoin > > leaving things up to chance that don't have to be left to chance. > > > > Enabling people to opt in as early as possible enables the prudent to > protect themselves for very > > little effort and cost. Those people know their coins are safe and can > still use their coin as they > > did before. > > We agree. I believe your response is based on a misunderstanding of my > argument, hopefully clarified > above. > > > > I mean people can create invalid addresses today in plenty of ways. > How is this unique? > > > > P2TRD would be an address, which looks exactly like a 100% valid address > and which can be spend from > > like a valid address and hwoever at some future time, it may or may not, > become frozen. > > Sure, but this is still no different than any other P2TR script-path > structure - you have to test > things you use, even if you use them rarely, which is the entire point of > the P2TR design :). > > 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+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/dd2fcc40-cedc-48ae-b23d-6029f678c184n%40googlegroups.com. ------=_Part_87823_617333437.1770910530525 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >=C2=A0 wallets aren't going to have a lot of incentive to adopt technologies that = make things marginally
more expensive.

This claim is not ro= oted in reality. We literally just now saw Trezor market their Safe 7 as Qu= antum Ready and they had a major ad campaign specifically for this. There i= s major incentive for wallets to "sell" the quantum threat as a problem to = fix, and therefore sell more wallets or claim compliance to gain market sha= re. The quantum threat is mainstream. Retail knows about it, talks about it= all the time.

>=C2=A0 many bitcoiners writing off the quantum threat

Yes because psych= ologically, the most successful Bitcoiners are those who never reacted to a= ny FUD and therefore never sold. And so they are essentially naturally sele= cted by their history of never reacting to FUD. We've basically evolved the= most non-reactant people and so obviously they are not going to react to t= he quantum threat because why would they change their strategy of never rea= cting if it worked so well so far?

torsdag 12 februari 2026 kl. 16:= 01:27 UTC+1 skrev Matt Corallo:


On 2/11/26 5:57 PM, Ethan Heilman wrote:
> > For what its worth I do not see a scenario where a decision = ultimately made by the market will=20
> pick the fork side with materially, say 5-10x higher, supply, over= the side with lower supply...
>=20
> Completely agree, the incentives favor lower supply. I wouldn'= t want to count on it happening and=20
> even if it does happen the freeze fork might not freeze P2TR. Acco= rding to the 2025 chaincode report=20
> [0] P2TR represents only 0.75% of total supply.

I believe we're talking past each other, then. This was a side note= - as Jonas mentioned it seems=20
reasonable that a P2TR-based QC signature validation opcode could come = with an on-chain signaling=20
bit (i.e. a "Taproot V2" that is functionally identical but i= ndicates the presence of a QC signature=20
script path available).

> > ~all wallets today use seedphrases, which could still be spe= nt with a ZK proof-of-seedphrase :).
>=20
> I'm all for putting ZKPs in consensus, but it seems unlikely t= o me that it will happen.

We just agreed that its highly likely that insecure spend paths are dis= abled. I do not remotely see=20
how such an action could occur if the result is that a large number of = coins are seized. The only=20
viable approach way for that is to allow seedphrase-based wallets to re= tain access.

> It is better=20
> to make Bitcoin safe than promise safety that requires a future ha= rdfork.

There is no hardfork required here.

> This is especially true=20
> since as you point out lower supply is incentivized, so a soft for= k that freezes coins would be=20
> fighting an uphill battle.

I'm confused by this comment - a soft fork that disables insecure s= pend paths to avoid them being=20
stolen is likely going to have a very easy time, not "fight an uph= ill battle"?

> > Hell, *any* PQ soft fork is going to see limited adoption in= "consumer wallets" until its=20
> urgent,=C2=A0hence why I think the community will be basically for= ced to disable insecure spend paths and=20
> only
> allow spends via ZK proof-of-seedphrase. But at least something th= at doesn't also 10x=20
> transaction=C2=A0costs might reasonably be adopted by default by w= allets that don't use seedphrases like=20
> Bitcoin Core.
>=20
> I disagree. If we get P2MR and SLH_DSA/SHRINCS the wallets can use= quantum-safe outputs (Schnorr OR=20
> PQ) with Schnorr as the default spend. The wallets can market them= selves as quantum safe.

This flies in the face of the last 15 years of experience with Bitcoin = wallets. Yea, it sounds=20
great, but we've got 15 years of experience showing that wallets on= ly adapt when they go out of=20
business/stop being maintained and get replaced with new wallets (which= often ship with the latest=20
technology). Worse, many bitcoiners (maybe rightfully, maybe not) entir= ely write off the quantum=20
threat - all the more reason they will simply not adopt any changes.

> The cost=20
> in transaction fees to a user is small, a 1 input P2MR transaction= would only be 37 bytes larger=20
> when compared with a 1 input P2TR transaction. Those 37 bytes are = in the witness, so the real cost=20
> is ~10 vbytes.

Apologies, I had understood the P2MR proposal to only feature PQC-based= schemes, rather than also=20
offering schnorr as an option, leading me to incorrectly conclude it wo= uld be drastically more=20
expensive, rather than marginally so.

Still, I think my point stands - in the face of many bitcoiners writing= off the quantum threat,=20
wallets aren't going to have a lot of incentive to adopt technologi= es that make things marginally=20
more expensive.

Worse, there's no real advantage here over just doing in the taproo= t key path - because of address=20
reuse a wallet relying on P2MR + schnorr anyway will ~always have its p= ublic key revealed so we=20
might as well continue relying on P2TR to save the 37 witness bytes and= get the same result (that=20
wallets can do something cheap with "just" a key derivation c= hange and explicitly opt in to a future=20
soft fork which disables the then-insecure spend paths).

> Yes, if Q-day happens, time passes and then quantum computers beco= me powerful enough to perform=20
> short-exposure attacks, anyone needing to move their coins to an o= utput have=C2=A0to pay fees for an=20
> additional 8,000 bytes (SLH_DSA) or=C2=A0324 bytes (SHRINCs). This= is still better than a PQ ZKP proof of=20
> the seed which would be between 20,000 to 120,000 bytes and more l= ikely to have a security flaw than=20
> SLH_DSA.

Yep, I'm not proposing at all that we do nothing because a ZKP of s= eedphrase is an option, rather we=20
should add support for SHRINCS and encourage wallet adoption. But at th= e same time we should=20
understand that we're incredibly unlikely to see the kind of adopti= on in time to avoid the need to=20
do something like a ZKP of seedphrase when the time comes.

This is also probably the least interesting point of contention, FWIW -= this is a decision for a=20
future bitcoin community, not a decision for us to make today.

> If efficient quantum signatures or compression techniques are deve= loped, we can and should adopt=20
> them. If they are efficient enough, they can become the default. T= his proposal is designed to keep=20
> funds safe in the intermediate period while better techniques are = developed to cover the tail risk=20
> where Q-day happens before the technology we need to completely re= ady.

Yep, we absolutely agree! I just don't see a reason to do P2MR over= just utilizing P2TR (or maybe=20
P2TRv2).

> > No it doesn't - it requires a soft fork when the risk is= imminent, but it happening somewhat=20
> before that time is okay too.
>=20
> We might wait too long and misjudge the risk and Q-day happens bef= ore the soft fork activates? What=20
> happens if freeze fork is activated but then 3 years pass and it l= ooks like a CRQC isn't going to=20
> happen after all? Now people who had their coins frozen are pushin= g to undo the soft fork.

> This approach carries too much risk from uncertainty and it was &q= uot;the plan" it signles that Bitcoin =20
> leaving things up to chance that don't have to be left to chan= ce.
>=20
> Enabling people to opt in as early as possible enables the prudent= to protect themselves for very=20
> little effort and cost. Those people know their coins are safe and= can still use their coin as they=20
> did before.

We agree. I believe your response is based on a misunderstanding of my = argument, hopefully clarified=20
above.

> > I mean people can create invalid addresses today in plenty o= f ways. How is this unique?
>=20
> P2TRD would be an address, which looks exactly like a 100% valid a= ddress and which can be spend from=20
> like a valid address and hwoever at some future time, it may or ma= y not, become frozen.

Sure, but this is still no different than any other P2TR script-path st= ructure - you have to test=20
things you use, even if you use them rarely, which is the entire point = of the P2TR design :).

Matt

--
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/dd2fcc40-cedc-48ae-b23d-6029f678c184n%40googlegroups.com.
------=_Part_87823_617333437.1770910530525-- ------=_Part_87822_1512002138.1770910530525--