From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 12 Feb 2026 10:41:47 -0800 Received: from mail-oi1-f190.google.com ([209.85.167.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vqbdK-0001dt-5Y for bitcoindev@gnusha.org; Thu, 12 Feb 2026 10:41:47 -0800 Received: by mail-oi1-f190.google.com with SMTP id 5614622812f47-45c8a31b1fcsf343506b6e.1 for ; Thu, 12 Feb 2026 10:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1770921700; x=1771526500; 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=waE637As6ZiH1BEcA6XsZGNF1PBtzumoUeSKgaJxCBw=; b=JkoH2tdXvOmdA/b1a+Ezgftrot0ZA9jbmS2KrtfqkxpfRGZ2TqxiNED/3YxD/dcjNQ C0KQCwqcnAO54r5E+EvDE0sX/axHy9bM4fQt8/fB33k20315h/Q3hNgKBDVSJby+OlOE a+OMQ0BGkBf2mc3Y8GM7CdvZa7YsejlQOPEaVBSE25Z62peIkwnEI3+RnN5y/LsY4IiV EuPqLANQwN9K+tk+AqCKaT38tJsiO7H1Iu8Vqp+o7mrRhg3FXzT/OpPk+16TeJtiCrVd vv0lyuUUi3MBOcyIj/Of46RdxCi3oUJqYl/QH52/QF8MjdImJ6kDTCkHapLhzOKVni7k pJIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770921700; x=1771526500; 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=waE637As6ZiH1BEcA6XsZGNF1PBtzumoUeSKgaJxCBw=; b=Y5GMFdQJai3d7SvXvpF/YIWJqsMViGIYbQeX0wqxTMxqlvLkZo9sbBkTdiVpOPDhkI lDEZFpQYP2Bj0qtzIzzD+ehYq8ai7niCToFvnuC3kr2+xF3U3pq98VWaQqdtW2HUMbp6 0YmKTBkwbKanvzXKImkdBDkhzj1P5VmZtezXZj/B+CAfSnFO3YeOUWAbhhWrgevLiEeN dg/cXKWXfu5ZpsIEGdAo9KPp1XR0Y3GjMY+e5S5hpBoNd8tSXo9cVesf2jSeJP9Dei6F QSICCpyvdOfswZ+Xsgrud6aFQ5YTOZCGGAT/Re3XCn6kDqNRN7lZI/5RLg8zQFPMtfeE GlgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770921700; x=1771526500; 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=waE637As6ZiH1BEcA6XsZGNF1PBtzumoUeSKgaJxCBw=; b=bLW7i3yvMnbwzJGOgrdlchC0fWR3bi55tv8eP7sWC7P8KAh6LCEF5grrdaway+6vci Xp3jOBXGYR7sEM9kg6Ymx5niqbVPdg1BHPtwXvgrvHTuTQnuohu8JwgW6wsNj5pqySp/ WV3wGCbwZH2zaC6DP9tkzJbPaqYbHP/+LyjTsewf5DvzvzbzfcEVkpYkHpT2vaYI6M3H NNhMpp2wuXhMTZ6UsvDX8UUlcaFBJMoHxJYZgsU1JBQfGuqWIV7KxtW7gf8JBDYcn3jg vZp8Vf+cyRNUSa1MD9EPYdzms2TqhI0PvNzxbvkzFddy7+wwCi3sG+ODRbXOkwnEh/Xr 3nsg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVBJV053b5UizBldttmm4PBHXJtFMLRwycG+LE1Wtl1aFVvQUxklVUxqcwcXCdhtjLN3IhmbhFtqP10@gnusha.org X-Gm-Message-State: AOJu0YyA6otu7VehrXuIYc/+o7EbT+cKMEV3I/ax3fLsD9lJxtonsQsZ gxEbKNLZjjCAXB0xl2M7IJDrarsOlWFqVs1SQAYXcYIpYyC21JYoD/SP X-Received: by 2002:a05:6820:4610:b0:663:888:73d1 with SMTP id 006d021491bc7-6759b9b5a83mr1255943eaf.60.1770921699965; Thu, 12 Feb 2026 10:41:39 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+EdjeChBQw/M6pTDn4TSWf9Bpqu5kLwFu/Ox5DdkEuaOw==" Received: by 2002:a05:6820:1508:b0:656:cea8:d380 with SMTP id 006d021491bc7-675cfe82da1ls482581eaf.0.-pod-prod-02-us; Thu, 12 Feb 2026 10:41:35 -0800 (PST) X-Received: by 2002:a05:6808:1304:b0:45e:dbc1:d3e9 with SMTP id 5614622812f47-46397ab3f8emr151552b6e.33.1770921695710; Thu, 12 Feb 2026 10:41:35 -0800 (PST) Received: by 2002:a05:690c:3101:b0:796:6bfb:cf56 with SMTP id 00721157ae682-7966bfbd7eems7b3; Thu, 12 Feb 2026 07:36:51 -0800 (PST) X-Received: by 2002:a05:690c:397:b0:796:6c4b:28f9 with SMTP id 00721157ae682-7972f12179fmr33432437b3.8.1770910610438; Thu, 12 Feb 2026 07:36:50 -0800 (PST) Date: Thu, 12 Feb 2026 07:36:50 -0800 (PST) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <22073a56-1cbf-4ba9-a2ea-46c621d4619c@mattcorallo.com> References: <22073a56-1cbf-4ba9-a2ea-46c621d4619c@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_87942_308077765.1770910610016" X-Original-Sender: ekaggata@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_87942_308077765.1770910610016 Content-Type: multipart/alternative; boundary="----=_Part_87943_807011673.1770910610016" ------=_Part_87943_807011673.1770910610016 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > For what its worth I do not see a scenario where a decision ultimately=20 made by the market will pick=20 the fork side with materially, say 5-10x higher, supply, over the side with= =20 lower supply...supply=20 and demand is king, especially with the "confiscatory" nature is basically= =20 nil as ~all wallets today=20 use seedphrases, which could still be spent with a ZK proof-of-seedphrase= =20 :). This line of reasoning is wrong imo. If supply and demand is king, why not just delete supply as much as=20 possible? No more mining? Arbitrary freezing of various actors' coins (but= =20 with warning! so it's only confiscation in quotes, right?). Hypothetical: someone proposes a fork which freezes all coins residing at= =20 utxos with addresses containing "234" (insert technical description as=20 appropriate - you get the idea). It'll be a bit like the rules about=20 driving into town with various letters in your license plate, though, a bit= =20 more permanent :) The vast majority will benefit economically from the lazy= =20 few who don't notice, since if they pay attention, they can hop out of the= =20 frozen addresses with time to spare, so why doesn't it happen? Obviously, ridiculous examples, but .. point stands in general: It's a curious kind of self-referential. The "market" here is really the=20 set of holders, their *short term* interest is to grab any they can, but=20 their long term interest is to have their stash keep its value. There is=20 *nothing* that will destroy bitcoin's value more effectively (certainly not= =20 technical issues like bugs, certainly not an unexpected unlock of a big=20 amount of coins to be moved in the market) than an event that questions the= =20 "private property promise": 1/ coin inflation schedule is set in stone; 2/ if you can cryptographically validate a transfer, bitcoin will let you= =20 do it, i.e. you can always spend your own money; 3/ if you "locked" a utxo with a certain ruleset in the past, that ruleset= =20 will still be active and let you spend in future, i.e. you can't be locked= =20 out of your own money. Bitcoin is the only digital asset in the world for which those assertions= =20 are credible; it has never yet violated them, and imo it's the thing that= =20 keeps it unique and important (PoW ties in; it's another aspect of the same= =20 rigid adherence to no controlling entities). That's why both this idea and Peter Todd's tail emission idea, both high=20 quality engineering-safety thinking, will not happen, in my opinion. > ZK proof-of-seedphrase :). Oh cool, that's a good point. Ethan's counterpoint is good too, that we=20 would need a consensus rule and that's v. hard, but: my spidey sense is=20 tingling a bit about whether people might find tricks to avoid it: if you= =20 consider the very clever tricks recently discovered around Glock, ArgoMAC= =20 and so on, they enable gating txs behind ZKP schemes w/o new consensus but= =20 what we're talking about here is way more narrowly defined than the larger= =20 problem they're trying to solve, which might support being optimistic ...). Cheers, AdamISZ/waxwing On Wednesday, February 11, 2026 at 12:55:19=E2=80=AFPM UTC-6 Matt Corallo w= rote: > > > On 2/10/26 11:44 AM, Ethan Heilman wrote: > > > If Bitcoin disables Taproot key path spends before Q-day, then doing= =20 > this via Taproot instead of=20 > > BIP 360 would be preferable. > >=20 > > I worry about making the transition to quantum-safe outputs depend on a= =20 > contentious debate over a=20 > > confiscatory soft fork. Uncertainty over whether the soft fork would be= =20 > released and if released=20 > > would be activated means that wallets and custodians are unlikely to=20 > have invested the resources=20 > > into upgrading to support script only P2TR. > > For what its worth I do not see a scenario where a decision ultimately=20 > made by the market will pick=20 > the fork side with materially, say 5-10x higher, supply, over the side=20 > with lower supply...supply=20 > and demand is king, especially with the "confiscatory" nature is basicall= y=20 > nil as ~all wallets today=20 > use seedphrases, which could still be spent with a ZK proof-of-seedphrase= =20 > :). > > > The benefit of BIP 360's P2MR (Pay-to-Merkle-Root) + SLH_DSA is that it= =20 > avoids this controversy by=20 > > being opt-in and non-confiscatory. This also means that BIP 360 +=20 > SLH_DSA is likely to activated=20 > > early, allowing wallets and custodians ample time to build support afte= r=20 > activation. > > The drawback being that it will see zero relevant adoption until its way= =20 > too late. > > The only entities that would reasonably adopt something like this are=20 > large custodians, who aren't=20 > worth worrying about as they'll easily migrate all their coins over the= =20 > course of a few days or=20 > weeks in an emergency scenario, and highly specialty wallets. The point o= f=20 > any PQ soft fork today is=20 > if it can actually drive wallets to start making progress on PQ=20 > deployment. A new address type that=20 > is 10x more expensive to transact with is going to see ~zero adoption in= =20 > "consumer wallets" until=20 > its urgent, at which point its obviously way, way too late. > > Hell, *any* PQ soft fork is going to see limited adoption in "consumer=20 > wallets" until its urgent,=20 > hence why I think the community will be basically forced to disable=20 > insecure spend paths and only=20 > allow spends via ZK proof-of-seedphrase. But at least something that=20 > doesn't also 10x transaction=20 > costs might reasonably be adopted by default by wallets that don't use=20 > seedphrases like Bitcoin Core. > > > > We could define a new SegWit version that is a copy of Taproot. The= =20 > new version number simply=20 > > signals that the owner consents to a future deactivation of key path=20 > spends. Unlike BIP 360, this > > approach would still require actually disabling the key path before=20 > Q-day, but it is not=20 > > confiscatory and allows using Taproot's benefits until then (with=20 > a privacy hit from having two=20 > > versions of Taproot in parallel). > >=20 > > Let's call this P2TRD (Pay-to-Tap-Root-Disablable). BIP 360 evolved fro= m=20 > this P2TRD idea, to=20 > > minimize the following hazards in P2TRD. > >=20 > > 1. P2TRD requires a soft fork that depends on accurately predicting=20 > Q-day or when EC Schnorr is=20 > > classically broken. We must not only predict Q-day but also convince th= e=20 > community that the=20 > > prediction is correct. If we mess up the timing, Bitcoin is=20 > significantly harmed. This means that=20 > > people will constantly be yelling that we are messing up the timing. It= =20 > will make quantum FUD worse=20 > > not better. > > No it doesn't - it requires a soft fork when the risk is imminent, but it= =20 > happening somewhat before=20 > that time is okay too. > > > 2. P2TRD (Pay-to-Tap-Root-Disablable) to be non-confiscatory users mus= t=20 > create a script spend that=20 > > replicates their key spend, But users and wallets are likely to screw= =20 > this up and not create script=20 > > spends. The is no way to see if a wallet is actually creating the scrip= t=20 > spend on the blockchain. > > I mean people can create invalid addresses today in plenty of ways. How i= s=20 > this unique? > > > 3. To be safe from long-exposure attacks P2TRD can't use the same publi= c=20 > key for the script spend as=20 > > the key spend. Since wallets will prefer the key spend to the script=20 > spend, a user might not realize=20 > > if they lost the keying material for their script spend until after=20 > activation. > > It would almost certainly just be a key derived from the seedphrase via= =20 > another hash function, so=20 > there's no real risk of this. > > 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= efa3dd60-84c2-48ea-9fc7-ae5057590cb9n%40googlegroups.com. ------=_Part_87943_807011673.1770910610016 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > For what its worth I do not see a scenario where a decision ultimately= made by the market will pick=20
the fork side with materially, say 5-10x higher, supply, over the sid= e with lower supply...supply=20
and demand is king, especially with the "confiscatory" nature is basi= cally nil as ~all wallets today=20
use seedphrases, which could still be spent with a ZK proof-of-s= eedphrase :).

This line of reasoning is wrong im= o.

If supply and demand is king, why not just de= lete supply as much as possible? No more mining? Arbitrary freezing of vari= ous actors' coins (but with warning! so it's only confiscation in quotes, r= ight?).

Hypothetical: someone proposes a fork wh= ich freezes all coins residing at utxos with addresses containing "234"=C2= =A0 (insert technical description as appropriate - you get the idea). It'll= be a bit like the rules about driving into town with various letters in yo= ur license plate, though, a bit more permanent :) The vast majority will be= nefit economically from the lazy few who don't notice, since if they pay at= tention, they can hop out of the frozen addresses with time to spare, so wh= y doesn't it happen?

Obviously, ridiculous examp= les, but .. point stands in general:

It's a curi= ous kind of self-referential. The "market" here is really the set of holder= s, their *short term* interest is to grab any they can, but their long term= interest is to have their stash keep its value. There is *nothing* that wi= ll destroy bitcoin's value more effectively (certainly not technical issues= like bugs, certainly not an unexpected unlock of a big amount of coins to = be moved in the market) than an event that questions the "private property = promise":

1/ coin inflation schedule is set in s= tone;
2/ if you can cryptographically validate a transfer, bitcoi= n will let you do it, i.e. you can always spend your own money;
3= / if you "locked" a utxo with a certain ruleset in the past, that ruleset w= ill still be active and let you spend in future, i.e. you can't be locked o= ut of your own money.

Bitcoin is the only digita= l asset in the world for which those assertions are credible; it has never = yet violated them, and imo it's the thing that keeps it unique and importan= t (PoW ties in; it's another aspect of the same rigid adherence to no contr= olling entities).

That's why both this idea and = Peter Todd's tail emission idea, both high quality engineering-safety think= ing, will not happen, in my opinion.

>=C2=A0Z= K proof-of-seedphrase :).

Oh cool, that's a good= point. Ethan's counterpoint is good too, that we would need a consensus ru= le and that's v. hard, but: my spidey sense is tingling a bit about whether= people might find tricks to avoid it: if you consider the very clever tric= ks recently discovered around Glock, ArgoMAC and so on, they enable gating = txs behind ZKP schemes w/o new consensus but what we're talking about here = is way more narrowly defined than the larger problem they're trying to solv= e, which might support being optimistic ...).

Ch= eers,
AdamISZ/waxwing

On Wednesday, February 11, 2026 at 12:55:= 19=E2=80=AFPM UTC-6 Matt Corallo wrote:


On 2/10/26 11:44 AM, Ethan Heilman wrote:
> > If Bitcoin disables Taproot key path spends before Q-day, th= en doing this via=C2=A0Taproot instead of=20
> BIP 360 would be preferable.
>=20
> I worry about making the transition to quantum-safe outputs depend= on a contentious debate over a=20
> confiscatory soft fork. Uncertainty over whether the soft fork wou= ld be released and if released=20
> would be activated means that wallets and custodians are unlikely = to have invested the resources=20
> into upgrading to support script only P2TR.

For what its worth I do not see a scenario where a decision ultimately = made by the market will pick=20
the fork side with materially, say 5-10x higher, supply, over the side = with lower supply...supply=20
and demand is king, especially with the "confiscatory" nature= is basically nil as ~all wallets today=20
use seedphrases, which could still be spent with a ZK proof-of-seedphra= se :).

> The benefit of BIP 360's P2MR (Pay-to-Merkle-Root)=C2=A0+ SLH_= DSA is that it avoids this controversy by=20
> being opt-in and non-confiscatory. This also means that BIP 360 + = SLH_DSA is likely to activated=20
> early, allowing wallets and custodians ample time to build support= after activation.

The drawback being that it will see zero relevant adoption until its wa= y too late.

The only entities that would reasonably adopt something like this are l= arge custodians, who aren't=20
worth worrying about as they'll easily migrate all their coins over= the course of a few days or=20
weeks in an emergency scenario, and highly specialty wallets. The point= of any PQ soft fork today is=20
if it can actually drive wallets to start making progress on PQ deploym= ent. A new address type that=20
is 10x more expensive to transact with is going to see ~zero adoption i= n "consumer wallets" until=20
its urgent, at which point its obviously way, way too late.

Hell, *any* PQ soft fork is going to see limited adoption in "cons= umer wallets" until its urgent,=20
hence why I think the community will be basically forced to disable ins= ecure spend paths and only=20
allow spends via ZK proof-of-seedphrase. But at least something that do= esn't also 10x transaction=20
costs might reasonably be adopted by default by wallets that don't = use seedphrases like Bitcoin Core.

> > We could define a new SegWit version that is a copy of Tapro= ot. The new version number simply=20
> signals that the owner=C2=A0consents to a future deactivation of k= ey path spends. Unlike BIP 360, this
> approach would still require actually disabling the key path befor= e Q-day, but=C2=A0it is not=20
> confiscatory and allows using Taproot's benefits until then (w= ith a=C2=A0privacy hit from having two=20
> versions of Taproot in parallel).
>=20
> Let's call this P2TRD (Pay-to-Tap-Root-Disablable). BIP 360 ev= olved from this P2TRD idea, to=20
> minimize the following hazards in P2TRD.
>=20
> 1.=C2=A0 P2TRD requires a=C2=A0soft fork that depends on accuratel= y predicting Q-day or when EC Schnorr is=20
> classically broken. We must not only predict Q-day but also convin= ce the community that the=20
> prediction is correct. If we mess up the timing, Bitcoin is signif= icantly harmed. This means that=20
> people will constantly be yelling that we are messing up the timin= g. It will make quantum FUD worse=20
> not better.

No it doesn't - it requires a soft fork when the risk is imminent, = but it happening somewhat before=20
that time is okay too.

> 2.=C2=A0 P2TRD (Pay-to-Tap-Root-Disablable) to be non-confiscatory= users must create a script spend that=20
> replicates their key spend, But users and wallets are likely to sc= rew this up and not create script=20
> spends. The is no way to see if a wallet is actually creating the = script spend on the blockchain.

I mean people can create invalid addresses today in plenty of ways. How= is this unique?

> 3. To be safe from long-exposure attacks P2TRD can't use the s= ame public key for the script spend as=20
> the key spend. Since wallets will prefer the key spend to the scri= pt spend, a user might not realize=20
> if they lost the keying material for their script spend until afte= r activation.

It would almost certainly just be a key derived from the seedphrase via= another hash function, so=20
there's no real risk of this.

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/efa3dd60-84c2-48ea-9fc7-ae5057590cb9n%40googlegroups.com.
------=_Part_87943_807011673.1770910610016-- ------=_Part_87942_308077765.1770910610016--