From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 25 Feb 2026 04:24:08 -0800 Received: from mail-oi1-f187.google.com ([209.85.167.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vvDvy-00007a-Ov for bitcoindev@gnusha.org; Wed, 25 Feb 2026 04:24:08 -0800 Received: by mail-oi1-f187.google.com with SMTP id 5614622812f47-4639f4233besf65240168b6e.3 for ; Wed, 25 Feb 2026 04:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1772022240; x=1772627040; 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=WjWXqOw01JxJCrmUfwlQeohV57RxpwkfeU8dp0NLSI8=; b=lH01txf8LU72nm+exluCBdVypUyRmd0j16khQ7bzNRS6zw4zLtv5OiY+MWajovii/k CvKcl1i0SV/3rD16vscFi+2M8666+JkQpJsGdBiON/NL28SnOLDeQdO91RbIjajE1uIL ebPvP5t1ge7TD20oakW1wkLE8Ix3gdU5+TwcXE0fIBdcddvESXLNbUzi+ZxA0moYHsP1 KUGA9t+df4I5zEpXQwEbAkD1ZmXPoLOYVz4H5k++jKBGGRmD7TqdDHrSB6j1eXOZuotw Y8j/UUm1deVA5Md8x8QUF+9OC4ZzhIWG/iIseaRJv11HtKQCL7hbeLcT/B8whie5HxM4 PBzw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772022240; x=1772627040; 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=WjWXqOw01JxJCrmUfwlQeohV57RxpwkfeU8dp0NLSI8=; b=ZwpjeMLB2rkQvYT3XFTalFYDfrRHUq58OG+DotzZqVhRm5/PTK8c7un7A12CU87Rqf WBGLNJAzHdRhLy9c3RetQpBHulcpr/rxGYTKvmhlgs/CCOjFqO4HcSzNkaf9yJtEW3Hp lKxw71JSFVzlFFbZDAnbzWLsr+usFmXK7L0PRsdw8Rc3psgT8HkcDUS/6KrvF1ut5eeu LNQjn6fnKZU9DL87oY2JkXuBo5LCWMS680KoAeFP6HxcBLyMrqeeEL47TgquNdojQvhw GzyKRlbU2LHb1Hy5uB7qOMuLYXnSEM1qUO6aK/EEJOsJwICWryuKRjVTKUiH/iOG0vxS hRMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772022240; x=1772627040; 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=WjWXqOw01JxJCrmUfwlQeohV57RxpwkfeU8dp0NLSI8=; b=b7IyfOsXGWtPo20ZnnOTLJwmhe0zkrAUs1rIWz6EEM/lIN3XjJCEQvs6i4Db30NY+Q 3ytqU2gYoKP2VOc5fboVQMvTTHH9Y5axopKen5h+9tb6yL0VALjYfKIjgWjvM8VUl5pL C1NoarPDX5asr89QJJRNtvyHdjeMxfRXwXJCat9CD4Q+ci0/2wfwySmwzh2sH3u7T4U7 npo206vmFh2+nqMHfNJo/kQicWt0jkTsogikNhX2TZfWyW21lY+y242pM3suVqrIeA6J k8IT8og1xgjJSavI19Hgsj6s2QXGjjPYvRbd+2x9tdGppnPr+MbimNprdtQmz3unaqyp kHew== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUihlqkBMtUvYCgWNkoNKiUGel32kMy1amfOebtTnp5X1lDr5ZGNP3W3nE8uBToFJ8fUfhN2U9J9AXg@gnusha.org X-Gm-Message-State: AOJu0YyLyGMcFQKCVRM+DcR4s8Qt4FEj1qq3dIKYXVZb3FEsCuZsZTD0 9cGasry/+eAUew43YLRRv0L1l9B2kOymT0OCylAVyQ1BlrnQvg+MDLZi X-Received: by 2002:a05:6808:30a8:b0:45e:e0d5:95ee with SMTP id 5614622812f47-464463b7e3fmr7080649b6e.52.1772022240222; Wed, 25 Feb 2026 04:24:00 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+E/BBoSIfGTX5yANrGS7RiZhlk9PhcDXy454qOH3f41tA==" Received: by 2002:a05:6870:164c:b0:415:f3ee:8366 with SMTP id 586e51a60fabf-415f3ee9bcfls211063fac.2.-pod-prod-06-us; Wed, 25 Feb 2026 04:23:56 -0800 (PST) X-Received: by 2002:a05:6808:c233:b0:450:44b9:68e0 with SMTP id 5614622812f47-4649ee628afmr97309b6e.11.1772022235971; Wed, 25 Feb 2026 04:23:55 -0800 (PST) Received: by 2002:a05:690c:930f:20b0:797:d142:b0fa with SMTP id 00721157ae682-79866a23fc6ms7b3; Wed, 25 Feb 2026 04:00:45 -0800 (PST) X-Received: by 2002:a05:690c:630f:b0:795:eb7:6681 with SMTP id 00721157ae682-7986ff4dbb6mr1249877b3.47.1772020844769; Wed, 25 Feb 2026 04:00:44 -0800 (PST) Date: Wed, 25 Feb 2026 04:00:44 -0800 (PST) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <823db0fa-08d3-4273-a428-04dc3d6da4d2n@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: The limitations of cryptographic agility in Bitcoin MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_167478_1417341609.1772020844287" 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_167478_1417341609.1772020844287 Content-Type: multipart/alternative; boundary="----=_Part_167479_777508425.1772020844287" ------=_Part_167479_777508425.1772020844287 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Ironically, I think that actual "theft" (scare quotes or not) in this=20 context is much less concerning than uncertainty and fear about the=20 possibility of theft... and I realize this is getting closer to being a=20 statement about human psychology than technical properties. Let's say a PQC= =20 scheme is added to Bitcoin in the next few years, and it sees some mild=20 adoption. Then we suddenly wake up one day, and the large majority of coins= =20 in known-pubkey addresses have moved to a PQC address. Nobody knows who or= =20 what did it, but it's widely assumed it was a CRQC. This might not affect= =20 Bitcoin's value that much - after all, most of the damage is already done.= =20 However, someone publishing a statement "I have a CRQC", signed by the same= =20 set of pubkeys that held those coins, would likely send the market tumbling= =20 down, and decimate Bitcoin's relevance for a long time. I'm in, I think, a group of people now, that have pointed this out, here=20 and elsewhere ... I like to call it the "epistemological problem" because,= =20 why use short words when a long one will do :) The scenario is all the=20 worse because (as, again, has been pointed out before): the "I have a CRQC"= =20 signed message you mention is (more likely), or can be, someone who has=20 just placed a short in the market, rather than an actual CRQC holder. The= =20 point is that during a period from "bitcoin doesn't have PQ algos" to=20 "bitcoin has PQ algos" the transition will always be essentially 100%=20 opaque; every honest action of moving to safety looks identical, onchain,= =20 to theft. This is a big mess, but my reason for framing as in the previous paragraph= =20 is to try to argue that that mess is 100% unavoidable even with the most=20 prudent behaviour and the most brilliant engineering. I am saying this to= =20 argue against the idea that engineering decisions should take this=20 psychological effect, as you put it, into account. I have an intuition that= =20 trying to address that will create bad outcomes. > Because of that, if CRQCs or other EC-breaks become reality, or just the= =20 fear about them becomes significant enough, I do believe that disabling EC= =20 opcodes will be necessary in any economically-relevant surviving chain, due= =20 to the millions of BTC that are unlikely to ever move. Note that I am *not*= =20 arguing that "Bitcoin" *will*, *should*, or even *can* do this, and I'm=20 quite sure that the inherent confiscation required will make the result=20 uninteresting to me personally. It may be that such disabling only happens= =20 in a fork that doesn't end up being called Bitcoin, or it may be that this= =20 happens only after a CRQC has been demonstrated to exist. Still, given a=20 severe enough threat I think it is inevitable, and I think that this means= =20 we shouldn't worry too much about what happens in chains in which EC is not= =20 disabled while simultaneously EC is considered insecure: such chains will= =20 be worthless anyway. Just quoting the last paragraph of your OP here because, thanks for=20 clarification that you're not proposing a freeze, but I find this paragraph= =20 ambiguous and I honestly don't understand it. First "disabling EC opcodes= =20 will be necessary" (else worthless). Then "I am not arguing that this=20 happens and moreover it will be uninteresting to me." Then "such chains=20 will be worthless" referring to chains in which EC is not disabled. Does=20 this imply that you're only interested in the worthless chains? :) Cheers, AdamISZ On Tuesday, February 17, 2026 at 5:09:59=E2=80=AFPM UTC-3 Pieter Wuille wro= te: > Hi, > > Thank you all for the interesting comments. I want to respond to some of= =20 > them, but feel like I need to clarify something first. > > *I am not proposing that coins are frozen in Bitcoin*, as I don't=20 > personally believe Bitcoin is interesting if it needs to give up that=20 > fundamental property. Rather, I am expressing the belief that levels of= =20 > threat/fear can exist which cause the chain(s) in which large amounts of= =20 > perceived-vulnerable coins remain to lose value to a devastating extent.= =20 > This can take many forms. Maybe none of us are around anymore, and the=20 > people then hold different values. Maybe some people create a freezing fo= rk=20 > before, or even after, a CRQC becomes reality, and that chain becomes mor= e=20 > economically relevant. Maybe it's not called Bitcoin. Maybe nearly all(*)= =20 > coins migrate to PQC addresses. Maybe CRQC fear fizzles out after some=20 > time. Maybe Bitcoin just doesn't survive CRQC fears. > > This is not a statement about what should or shouldn't be done about=20 > perceived-vulnerable coins. It is an observation that may however influen= ce=20 > design around the introduction of other schemes: > > - Giving users the option to migrate to schemes with a different=20 > security assumption is not enough to remove that security assumption f= rom=20 > the system. Bitcoin as a whole, and all its users including those who= =20 > migrate, are and remain dependent on secp256k1 security as long as man= y(*)=20 > secp256k1-secured coins remain. > - Users adopting schemes with a different security assumption at=20 > scale(*) is opting all users including those who do not migrate, into = that=20 > security assumption. > - We can design things for a future where no substantial(*) amount of= =20 > coins are perceived to be vulnerable. Not because we're planning to fr= eeze=20 > the coins that are, but because future chains in which such coins rema= in=20 > will lose value. I am not stating what the solution to get there is - = I=20 > don't know - I am stating that we can operate under the premise that a= =20 > solution will be found, because futures in which there isn't are=20 > uninteresting. > > > I fundamentally disagree with this thesis you outlined here. The error in= =20 > the second of the three quotes is subtle: it's not that rational users wi= ll=20 > not *want* others to migrate (of course, they will), it's that they will= =20 > not *want* violation of property rights. See [1] > > > Why not both? For Bitcoin to relevant, it needs to have value. One=20 > important component of that is differentiation with competing monetary=20 > systems, which includes properties like a fixed inflation schedule and=20 > inviolable property rights. But not having market fear wipe out your coin= s'=20 > value, even if you keep them, is a component too. > > I agree Bitcoin cannot promise anything about its exchange rate with=20 > real-world goods and services, or other currencies, but that doesn't mean= =20 > this isn't relevant to its users. And as developers we ought to design fo= r=20 > a system with properties we care about, but that doesn't mean we cannot= =20 > make observations about the reality the system exists in. > > > Suppose X% of the supply is held by negligent holders. Over time that X%= =20 > will move away from those negligent holders to "thieves" (scare quotes=20 > because if literally held in outputs for which the unlocking script is=20 > publically derivable, it's debatable whether it's theft, even). The thiev= es=20 > will either be negligent themselves or not; in any case, over time, the= =20 > coins will move to holders who are not negligent. > > > Ironically, I think that actual "theft" (scare quotes or not) in this=20 > context is much less concerning than uncertainty and fear about the=20 > possibility of theft... and I realize this is getting closer to being a= =20 > statement about human psychology than technical properties. Let's say a P= QC=20 > scheme is added to Bitcoin in the next few years, and it sees some mild= =20 > adoption. Then we suddenly wake up one day, and the large majority of coi= ns=20 > in known-pubkey addresses have moved to a PQC address. Nobody knows who o= r=20 > what did it, but it's widely assumed it was a CRQC. This might not affect= =20 > Bitcoin's value that much - after all, most of the damage is already done= .=20 > However, someone publishing a statement "I have a CRQC", signed by the sa= me=20 > set of pubkeys that held those coins, would likely send the market tumbli= ng=20 > down, and decimate Bitcoin's relevance for a long time. > > This is also my response to Light's analogy with the systemic risk impose= d=20 > by large amounts of coins held by exchanges. I think the ecosystem ought = to=20 > be more concerned about that risk, but the fact that it isn't does not me= an=20 > it also won't be concerned about the potential of large amounts of coins= =20 > becoming vulnerable. > > Anyone who wants quantum security but is also afraid of fully trusting=20 > untested new algorithms like FancySig could easily use a hybrid locking= =20 > script which requires both BIP340 AND FancySig signatures. > > > This misses the point I was trying to make. If someone were truly hesitan= t=20 > about FancySig's security, then having them moving their own coins into a= =20 > "BIP340 AND FancySig" outputs isn't a solution. They would would want=20 > *everyone*(*) who wants to use FancySig to stick to "BIP340 AND=20 > FancySig", i.e., this would be an argument against supporting FancySig-on= ly=20 > outputs. And that is indeed a solution to the "people don't trust FancySi= g"=20 > problem, but it comes at a significant cost too. > > However, I only included the possibility of people distrustful in the=20 > other direction (fear of a new scheme) in my example to show the extreme= =20 > incompatibility it may lead to. The point that (IMO) all Bitcoin users=20 > remain dependent on secp256k1 security as long as a substantial(*) amount= =20 > of coins protected (solely) by it remain, is far more important.=20 > > Disabling them like you propose? > > > To be clear, I am not proposing that, and I'm not interested in discussin= g=20 > what Bitcoin should do. > > (*) =3D All of these statements are about some sufficiently large number = of=20 > coins, which I don't know what it is. > > --=20 > Pieter > > On Friday, February 13th, 2026 at 11:20 AM, Pieter Wuille < > bitco...@wuille.net> wrote: > > Hi all, > > A thread was=20 > recently started on this list about cryptographic agility in Bitcoin. I= =20 > believe there are important limitations around that idea, and wanted to= =20 > offer my own perspective. It's more a philosophical consideration, and is= =20 > not intended as an argument against (or for) any particular proposal toda= y. > > The idea is giving users/wallets the ability to choose the cryptographic= =20 > primitives used to protect their own coins, from a set of available=20 > primitives that may change over time. I think this ignores how important = it=20 > is what *others do with their coins*. If others' coins lose value, for=20 > example due to fears about them becoming vulnerable to theft with=20 > cryptographic breakthroughs, so do your own due to fungibility, regardles= s=20 > of how well protected they are. > > As an extreme thought-experiment, imagine that tomorrow a new=20 > cryptographic signature scheme FancySig is published, with all the featur= es=20 > that Bitcoin relies on today: small signatures, fast to verify, presumed= =20 > post-quantum, BIP32-like derivation, taproot-like tweaking,=20 > multisignatures, thresholds, ... Further assume that within the next year= =20 > or two, voices (A) start appearing arguing that such a scheme should be= =20 > adopted, because it's the silver bullet the ecosystem has been waiting fo= r.=20 > At the same time, another camp (B) may appear cautioning against this,=20 > because the scheme is new, hasn't stood the test of time, and isn't=20 > well-analyzed. These two camps may find themselves in a fundamental=20 > disagreement: > > - Camp (A), fearing an EC-break (CRQC or otherwise), wouldn't just=20 > want FancySig as an option - they would want (feasible or not) that *n= ear-everyone=20 > migrates to it*, because the prospect of millions of BTC in=20 > EC-vulnerable coins threatens their own hodling. > =20 > > - Camp (B), fearing the possibility that FancySig gets broken soon,=20 > possibly even classically=20 > ,=20 > don't want to just not use FancySig; they would want *near-nobody to= =20 > migrate to it*, because the prospect of a potential break of FancySig= =20 > threatens their own hodling. > > This is of course an extreme scenario, and in reality the divergence=20 > between camps may be much less incompatible, but I still think it's a goo= d=20 > demonstration of the fact that *despite being a currency for enemies,=20 > Bitcoin essentially requires users to share trust assumptions in the=20 > cryptography, and its technology in general*. > > A small note aside: you can argue that it is possible for people to store= =20 > coins insecurely, like in an OP_TRUE script output, or with private keys= =20 > that are made public. I don't think this possibility affects the point=20 > above, because it is not about what possibilities exist, but which=20 > approaches people are likely to / asked to adopt. Nobody is incentivized = or=20 > encouraged to store coins in an OP_TRUE. > > It is also good to ask what amounts are relevant here, to which I do not= =20 > know the answer. Possibly, the prospect of 100k BTC becoming vulnerable t= o=20 > theft won't threaten the value of the other coins, while the prospect of= =20 > 10M BTC becoming vulnerable may. Depending on where your belief about thi= s=20 > lies, you may end up with very different conclusions. Still, to me it is= =20 > clear that *some* threshold exists above which I would be uncomfortable= =20 > with seeing that many coins move into an untrustworthy scheme, even if th= ey=20 > are not my own coins. > > This brings us to the question then how at all Bitcoin users can migrate= =20 > to new cryptography, because we cannot assume that secp256k1 will last=20 > forever. And I think the answer is essentially that it requires the entir= e=20 > ecosystem to change their assumptions. This does not mean that adding a n= ew=20 > opt-in cryptographic primitive is infeasible or a bad idea; it just means= =20 > that adding FancySig as an option is changing the collective security=20 > assumption from "secp256k1 is secure" to "secp256k1 AND FancySig are=20 > secure" once FancySig gets adopted at scale, and the discussion about=20 > adding new primitives should be treated with the gravity that entails. An= d=20 > it means that disabling secp256k1 EC operations (or near-everyone migrati= ng=20 > to FancySig, but I think that is unlikely) is the only way to change the= =20 > collective security assumption from "secp256k1 AND FancySig are secure" t= o=20 > "FancySig is secure". > > Because of that, if CRQCs or other EC-breaks become reality, or just the= =20 > fear about them becomes significant enough, I do believe that disabling E= C=20 > opcodes will be necessary in any economically-relevant surviving chain, d= ue=20 > to the millions of BTC that are unlikely to ever move. Note that I am=20 > *not* arguing that "Bitcoin" *will*, *should*, or even *can* do this, and= =20 > I'm quite sure that the inherent confiscation required will make the resu= lt=20 > uninteresting to me personally. It may be that such disabling only happen= s=20 > in a fork that doesn't end up being called Bitcoin, or it may be that thi= s=20 > happens only after a CRQC has been demonstrated to exist. Still, given a= =20 > severe enough threat I think it is inevitable, and I think that this mean= s=20 > we shouldn't worry too much about what happens in chains in which EC is n= ot=20 > disabled while simultaneously EC is considered insecure: such chains will= =20 > be worthless anyway. > --=20 > Pieter > > > > --=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/= 823db0fa-08d3-4273-a428-04dc3d6da4d2n%40googlegroups.com. ------=_Part_167479_777508425.1772020844287 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Ironically, I think that actual "theft" (scare quotes or not) in = this=20 context is much less concerning than uncertainty and fear about the=20 possibility of theft... and I realize this is getting closer to being a=20 statement about human psychology than technical properties. Let's say a=20 PQC scheme is added to Bitcoin in the next few years, and it sees some=20 mild adoption. Then we suddenly wake up one day, and the large majority=20 of coins in known-pubkey addresses have moved to a PQC address. Nobody=20 knows who or what did it, but it's widely assumed it was a CRQC. This=20 might not affect Bitcoin's value that much - after all, most of the=20 damage is already done. However, someone publishing a statement "I have a CRQC", signed by the same set of pubkeys that held those coins, would=20 likely send the market tumbling down, and decimate Bitcoin's relevance=20 for a long time.

I'm in, I think, a group of peo= ple now, that have pointed this out, here and elsewhere ... I like to call = it the "epistemological problem" because, why use short words when a long o= ne will do :) The scenario is all the worse because (as, again, has been po= inted out before): the "I have a CRQC" signed message you mention is (more = likely), or can be, someone who has just placed a short in the market, rath= er than an actual CRQC holder. The point is that during a period from "bitc= oin doesn't have PQ algos" to "bitcoin has PQ algos" the transition will al= ways be essentially 100% opaque; every honest action of moving to safety lo= oks identical, onchain, to theft.

This is a big = mess, but my reason for framing as in the previous paragraph is to try to a= rgue that that mess is 100% unavoidable even with the most prudent behaviou= r and the most brilliant engineering. I am saying this to argue against the= idea that engineering decisions should take this psychological effect, as = you put it, into account. I have an intuition that trying to address that w= ill create bad outcomes.

>=C2=A0Because of th= at, if CRQCs or other EC-breaks become=20 reality, or just the fear about them becomes significant enough, I do=20 believe that disabling EC opcodes will be necessary in any=20 economically-relevant surviving chain, due to the millions of BTC that=20 are unlikely to ever move. Note that I am not arguing that= "Bitcoin" will, should, or even can do this, an= d I'm quite sure that the inherent=20 confiscation required will make the result uninteresting to me=20 personally. It may be that such disabling only happens in a fork that=20 doesn't end up being called Bitcoin, or it may be that this happens only after a CRQC has been demonstrated to exist. Still, given a severe=20 enough threat I think it is inevitable, and I think that this means we shou= ldn't worry too much about what happens in chains in=20 which EC is not disabled while simultaneously EC is considered insecure: such chains will be worthless anyway.

Just quot= ing the last paragraph of your OP here because, thanks for clarification th= at you're not proposing a freeze, but I find this paragraph ambiguous and I= honestly don't understand it. First "disabling EC opcodes will be necessar= y" (else worthless). Then "I am not arguing that this happens and moreover = it will be uninteresting to me." Then "such chains will be worthless" refer= ring to chains in which EC is not disabled. Does this imply that you're onl= y interested in the worthless chains? :)

Cheers,=
AdamISZ


On Tuesday, February 17, 2026 at 5:09:59= =E2=80=AFPM UTC-3 Pieter Wuille wrote:
Hi,

Thank you all for the interesti= ng comments. I want to respond to some of them, but feel like I need to cla= rify something first.

I am not propo= sing that coins are frozen in Bitcoin, as I don't personally believ= e Bitcoin is interesting if it needs to give up that fundamental property. = Rather, I am expressing the belief that levels of threat/fear can exist whi= ch cause the chain(s) in which large amounts of perceived-vulnerable coins = remain to lose value to a devastating extent. This can take many forms. May= be none of us are around anymore, and the people then hold different values= . Maybe some people create a freezing fork before, or even after, a CRQC be= comes reality, and that chain becomes more economically relevant. Maybe it&= #39;s not called Bitcoin. Maybe nearly all(*) coins migrate to PQC addresse= s. Maybe CRQC fear fizzles out after some time. Maybe Bitcoin just doesn= 9;t survive CRQC fears.

= This is not a statement about what should or shouldn't be done about pe= rceived-vulnerable coins. It is an observation that may however influence d= esign around the introduction of other schemes:
  • Gi= ving users the option to migrate to schemes with a different security assum= ption is not enough to remove that security assumption from the system. Bit= coin as a whole, and all its users including those who migrate, are and rem= ain dependent on secp256k1 security as long as many(*) secp256k1-secured co= ins remain.
  • Users adopting schemes w= ith a different security assumption at scale(*) is opting all users includi= ng those who do not migrate, into that security assumption.
  • We can design things for a future where no substa= ntial(*) amount of coins are perceived to be vulnerable. Not because we'= ;re planning to freeze the coins that are, but because future chains in whi= ch such coins remain will lose value. I am not stating what the solution to= get there is - I don't know - I am stating that we can operate under t= he premise that a solution will be found, because futures in which there is= n't are uninteresting.

I fundamentally disagree = with this thesis you outlined here. The error in the second of the three qu= otes is subtle: it's not that rational users will not *want* others to = migrate (of course, they will), it's that they will not *want* violatio= n of property rights. See [1]

<= div>
Why not both? For Bitcoin to relevant, it needs to have value. One= important component of that is differentiation with competing monetary sys= tems, which includes properties like a fixed inflation schedule and inviola= ble property rights. But not having market fear wipe out your coins' va= lue, even if you keep them, is a component too.

I = agree Bitcoin cannot promise anything about its exchange rate with real-wor= ld goods and services, or other currencies, but that doesn't mean this = isn't relevant to its users. And as developers we ought to design for a= system with properties we care about, but that doesn't mean we cannot = make observations about the reality the system exists in.
=
=


Suppose X% of the supply is held by negligent holders. Over tim= e that X% will move away from those negligent holders to "thieves"= ; (scare quotes because if literally held in outputs for which the unlockin= g script is publically derivable, it's debatable whether it's theft= , even). The thieves will either be negligent themselves or not; in any cas= e, over time, the coins will move to holders who are not negligent.

Ironically, I think that actual &q= uot;theft" (scare quotes or not) in this context is much less concerni= ng than uncertainty and fear about the possibility of theft... and I realiz= e this is getting closer to being a statement about human psychology than t= echnical properties. Let's say a PQC scheme is added to Bitcoin in the = next few years, and it sees some mild adoption. Then we suddenly wake up on= e day, and the large majority of coins in known-pubkey addresses have moved= to a PQC address. Nobody knows who or what did it, but it's widely ass= umed it was a CRQC. This might not affect Bitcoin's value that much - a= fter all, most of the damage is already done. However, someone publishing a= statement "I have a CRQC", signed by the same set of pubkeys tha= t held those coins, would likely send the market tumbling down, and decimat= e Bitcoin's relevance for a long time.

This is= also my response to Light's analogy with the systemic risk imposed by = large amounts of coins held by exchanges. I think the ecosystem ought to be= more concerned about that risk, but the fact that it isn't does not me= an it also won't be concerned about the potential of large amounts of c= oins becoming vulnerable.

Anyone who wants quantum secur= ity but is also afraid of fully trusting untested new algorithms like Fancy= Sig could easily use a hybrid locking script which requires both BIP340 AND= FancySig signatures.

This misses the point I wa= s trying to make. If someone were truly hesitant about FancySig's secur= ity, then having them moving their own coins into a "BIP340 AND FancyS= ig" outputs isn't a solution. They would would want everyone(*) who wants to use FancySig to stick to "BIP340 AND FancySig",= i.e., this would be an argument against supporting FancySig-only outputs. = And that is indeed a solution to the "people don't trust FancySig&= quot; problem, but it comes at a significant cost too.

However, I only included th= e possibility of people distrustful in the other direction (fear of a new s= cheme) in my example to show the extreme incompatibility it may lead to. Th= e point that (IMO) all Bitcoin users remain dependent on secp256k1 security= as long as a substantial(*) amount of coins protected (solely) by it remai= n, is far more important.=C2=A0

Disabling them like you propose?

= To be clear, I am not proposing that, and I'm not interested in discuss= ing what Bitcoin should do.

(*) =3D All of these statements are ab= out some sufficiently large number of coins, which I don't know what it= is.

--=C2=A0
Pieter

On F= riday, February 13th, 2026 at 11:20 AM, Pieter Wuille <bitco...@wuille.net> wrote:

Hi all,

A thread was recently started on this list about cryptographic agility in Bitcoin. I believe there are important limitations around that idea, and= wanted to offer my own perspective. It's more a philosophical consideration, and is not intended as an argument against (or for) any particular proposal today.

=

The idea is giving users/wallets the ability to choose the cryptographic primitives used to protect their own coins, from a set of av= ailable primitives that may change over time. I think this ignores how important it is what others do with their coins. If others' coins lose value, for example due to fears about them becoming vulnerable to theft with cryptographic breakthroughs, so do your own due to fungibility, regardless of how well protected they are.

=

As an extreme thought-experiment, imagine that tomorrow a new cryptographic signature scheme FancySig is published, with all the features that Bitcoin relies on today: small signatures, fast to verify, presumed post-quantum, BIP32-like derivation, taproot-like tweaking, multisignatures, thresholds, ... Further assume that within the next year or two, voices (A) start appearing arguing that such a scheme should be adopted, because it's the silver bullet the ecosystem has bee= n waiting for. At the same time, another camp (B) may appear cautioning against this, because the scheme is new, hasn't stood the test of time, and isn't well-analyzed. These two camps may find themselves in a fundamental disagreement:

  • Camp (A), fearing an E= C-break (CRQC or otherwise), wouldn't just want FancySig as an option - they would want (feasible or not) that = near-everyone migrates to it, because the prospect of millio= ns of BTC in EC-vulnerable coins threatens their own hodling.
  • Camp (B), fearing the possibility = that FancySig gets broken soon, possibly even classically, don't want to just not use FancySig; they wo= uld want near-nobody to migrate to it, because the prospect of a p= otential break of FancySig threatens their own hodling.

This is of course an extreme scenario, and in reality the divergence between camps may be much less incompatible, but I still think it's a good demonstration of the fact that despite being = a currency for enemies, Bitcoin essentially requires users to share trust assumptions in the cryptography, and its technology in general.

A small note aside: you can argue that it is possible for people to store coins insecurely, like in an OP_TRUE script output, or with private keys that are made public. I don't think this possibility affects the point above, because it is not about what possibilities exist, but which approaches people are likely to / asked to adopt. Nobody is incentivized or encouraged to store coins in an OP_TRUE.

It is also good to ask what amounts are relevant here, to which I do not know the answer. Possibly, the prospect of 100k BTC becoming vulnerable to theft won't threaten the value of the other coins, while the prospect of 10M BTC becoming vulnerable may. Depending on where your belief about this lies, you may end up with very different conclusions. Still, to me it is clear that some threshold exists above which I would be uncomfortable with seeing that many coins move into an untrustworthy scheme, even if they are not my own coins.

This brings us to the question then how at all Bitcoin users can migrate to new cryptography, because we cannot assume that secp256k1 will last forever. And I think the answer is essentially that it requires the entire ecosystem to change their assumptions. This does not mean that adding a new opt-in cryptographic primitive is infeasible or a bad idea; it just means that adding FancySig as an option is changing the collective security assumption from "secp256k1 is secure&= quot; to "secp256k1 AND FancySig are secure" once FancySig gets adopted= at scale, and the discussion about adding new primitives should be treated with the gravity that entails. And it means that disabling secp256k1 EC operations (or near-everyone migrating to FancySig, but I think that is unlikely) is the only way to change the collective security assumption from= "secp256k1 AND FancySig are secure" to "FancySig is secure".

Because of that, if CRQCs or other EC-breaks become reality, or just the fear about them becomes significant enough, I do believe that disabling EC opcodes will be necessary in any economically-relevant surviving chain, due to the millions of BTC that are unlikely to ever move. Note that I am not arguing that= "Bitcoin" will, should, or even can d= o this, and I'm quite sure that the inherent confiscation required will make the result uninteresting to me personally. It may be that such disabling only happens in a fork that doesn't end up being called Bitcoin, or it may be that this happens onl= y after a CRQC has been demonstrated to exist. Still, given a severe enough threat I think it is inevitable, and I think that this means we shou= ldn't worry too much about what happens in chains in which EC is not disabled while simultaneously EC is considered insecure: such chains will be worthless anyway.

--=C2=A0
Piet= er



--
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/823db0fa-08d3-4273-a428-04dc3d6da4d2n%40googlegroups.com.
------=_Part_167479_777508425.1772020844287-- ------=_Part_167478_1417341609.1772020844287--