From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 14 Feb 2026 04:07:30 -0800 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vrEQr-000079-Ii for bitcoindev@gnusha.org; Sat, 14 Feb 2026 04:07:30 -0800 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-40ee0b3aa93sf11298876fac.3 for ; Sat, 14 Feb 2026 04:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1771070843; x=1771675643; 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=5b7zatGj7GuNlRx8MjktBJOZuRKAE7XH4efcSEf8gmc=; b=C4R+uvIQljUWp3+q0iNQUApVPDzCNuwD/FyrBO9pWegFvwL44XPJX7Jwyx4wTWfhas 4fkm8RbcVGAn9sqGaRdsnrK0RnKTooYMkvVfTEDSkCNHWQLf+GLFzTmCI8k8D5yGDl/x zgx939YgptaYIZBCa3M3F9LbdmP114Colwwn1MFvQp6Pf4LJSYIRTcm8lEHcBPYmg/u3 6FBlpuEuco8Soi07B/i92w35ze+qHfBSVXC/sAPlrn1axl2iLevCEMw8IXuVY/bTXpa7 ziVVx27QrOvK4mXGg2FY8spUtc2oP+q1bp8tPqom1eGEHMV6us5aNLKSglrSzgFroE+d JEnQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771070843; x=1771675643; 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=5b7zatGj7GuNlRx8MjktBJOZuRKAE7XH4efcSEf8gmc=; b=avRHtrxb62lTZutl7X0L7dnxQiY2xZMYulVb01hpmpOJlrXZaqD6j39jgwW5r0PVSJ jZ4bCVRFVczpJCRJV2DE/SFZv9qi4rm9Chwb0PJ/zBKw+DPlYGn8MVoX3Kf/XGdGafFC oCeGr2SAVHo96Esp3u+9yXbXyIbDGACZcn7pr6bzwPRi+qaRLqhvVuctwQRRTy66ArHz E3srWpbp+Pvl0Yj+HEPJZ9Yv2w94EA+HxsisNlqmXff/bs/mqCqsF8kofIo52Z+O06IR xhpd75WBQ3QONd1ZlOZC5fLV/mv+MHIRqQTcE1Yyo6OJkHnsQP6M0JIxI5LB/A3vMFYo M1RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771070843; x=1771675643; 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=5b7zatGj7GuNlRx8MjktBJOZuRKAE7XH4efcSEf8gmc=; b=LuDKv05zkCgb9DZhYOYmooP9QlWGEgcYe+jKc059FR1fpXbyAgWnSEHm3PMqBiqLXi HuMjWCFBpz+NyjLrORVnHgzqbCe/pw8L2FXnX+LyrAnOVhJxl7M2tKZB1LoFc23c+F84 8+RihnY1g+WvvOf+6ZcV9lIjMOwZFPZhvCDhQBfDBEb1f02KIcZgy74T0r6S35rd2oxI lnjn+HeYW7Ll9KOEM6mIWnt4w4MqmqgUs+NNFwGSg8qoQHPYv6scd7yx8oTURIQiYgCZ X7TTxvnFmKkWC6V+66n/p5JwE7OsuyAdpD0/aLMyWVCjuoC7Tw34vRGkt4o+lIWDIN3o IKZg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXrw6JDm6GFExZCiSnCq5kRKGz4NxkUnSIaJfsk41Ziu/O/NiKrZCMIYRqwnu7rH85eMOr3fb3TepHN@gnusha.org X-Gm-Message-State: AOJu0YzAmxH12wNO+X3Fad6+ZoEKkXrdinFfsd/19yTNunFVo/q4sdyP rtyx4qs4CWmIHkAIlmwTAJTwPy6XIihv/Ak1wbZxB/6Yy+utUM8zttFZ X-Received: by 2002:a05:6870:1ec9:b0:3d2:c24:30fc with SMTP id 586e51a60fabf-40eeed4886fmr3238125fac.48.1771070842957; Sat, 14 Feb 2026 04:07:22 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+F7G/qVCiCFo8M6PEUDBUH8HRKSygSrfTLT/v1nb63Vgw==" Received: by 2002:a05:6870:420c:b0:40e:f703:9195 with SMTP id 586e51a60fabf-40ef703caf4ls1109100fac.0.-pod-prod-01-us; Sat, 14 Feb 2026 04:07:18 -0800 (PST) X-Received: by 2002:a05:6808:179a:b0:45e:bfd1:c332 with SMTP id 5614622812f47-4639f19165bmr2595280b6e.32.1771070838337; Sat, 14 Feb 2026 04:07:18 -0800 (PST) Received: by 2002:a05:690c:2891:b0:794:2788:2ae4 with SMTP id 00721157ae682-7979c669d0cms7b3; Sat, 14 Feb 2026 04:02:04 -0800 (PST) X-Received: by 2002:a05:690c:f8b:b0:794:84ee:9aa5 with SMTP id 00721157ae682-797a0cd4993mr37130767b3.47.1771070523164; Sat, 14 Feb 2026 04:02:03 -0800 (PST) Date: Sat, 14 Feb 2026 04:02:02 -0800 (PST) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <8fa10605-8b55-4777-9fb9-82b9c0fd1dbfn@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_21642_1592707165.1771070522675" 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_21642_1592707165.1771070522675 Content-Type: multipart/alternative; boundary="----=_Part_21643_1103339747.1771070522675" ------=_Part_21643_1103339747.1771070522675 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Pieter, list, > If others' coins lose value, for example due to fears about them=20 becoming vulnerable to theft with cryptographic breakthroughs, so do your= =20 own due to fungibility, regardless of how well protected they are. > Camp (A), fearing an EC-break (CRQC or otherwise), wouldn't just want=20 FancySig as an option - they would want (feasible or not) that *near-everyo= ne=20 migrates to it*, because the prospect of millions of BTC in EC-vulnerable= =20 coins threatens their own hodling. > the fact that *despite being a currency for enemies, Bitcoin essentially= =20 requires users to share trust assumptions in the cryptography, and its=20 technology in general*. > it just means that adding FancySig as an option is changing the=20 collective security assumption from "secp256k1 is secure" to "secp256k1 AND= =20 FancySig are secure" 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 will= =20 not *want* others to migrate (of course, they will), it's that they will=20 not *want* violation of property rights. See [1] The fact that other coins are held in an insecure way is in no way a threat= =20 to my security. As you point out with e.g. OP_TRUE there is zero ability to= =20 prevent people doing this. 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 thieves= =20 will either be negligent themselves or not; in any case, over time, the=20 coins will move to holders who are not negligent. The only thing that the system as a whole *has* to promise is that there=20 exists a safe, practical way to keep possession (and also users should not= =20 have to just "guess" which methods are secure!). The system is not=20 required, nor can it, to prevent people choosing insecure storage methods,= =20 against the technical advice. If value is held in large quantities in outputs which phase from secure to= =20 insecure then for sure there are cases (even when said technical advice is= =20 amply provided!) where this leads to turbulence in value (mostly due to=20 death or key loss), but value cannot be controlled or predicted anyway. As= =20 per my message here: [1] there are private property rights principles which= =20 cannot be violated, else the entire purpose of the project is lost. Good=20 safety-engineering reasoning is unfortunately not enough to trump such=20 principles. (I think the title of your thread is interesting though: is *agility*=20 desirable? We're borrowing the term from other areas of the IT industry=20 where it makes more sense perhaps; perhaps here "flexibility" is the more= =20 desirable part, at least if you take *my* side of this specific argument,= =20 which is that no, others' security failings do not change the promise made= =20 to users to protect their property. Flexibility helps exactly where there's= =20 a lot of uncertainty about the security of different schemes. If it costs= =20 $100 to move in quantum-secure way and $1 to move in a non-*, then it is=20 much better that flexibility exists.) [1] https://groups.google.com/g/bitcoindev/c/7jkVS1K9WLo/m/btgqa9t7AwAJ Cheers, AdamISZ/waxwing On Friday, February 13, 2026 at 1:23:16=E2=80=AFPM UTC-3 Pieter Wuille wrot= e: > 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/= 8fa10605-8b55-4777-9fb9-82b9c0fd1dbfn%40googlegroups.com. ------=_Part_21643_1103339747.1771070522675 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Pieter, list,

>=C2=A0 If others' coins lose value, for example due to fears about them=20 becoming vulnerable to theft with cryptographic breakthroughs, so do=20 your own due to fungibility, regardless of how well protected they are.

>=C2=A0Camp (A), fearing an EC-break= (CRQC or otherwise), wouldn't just=20 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.=

>=C2=A0the fact th= at despite being a currency for enemies, Bitcoin essentially requires users to share trust assumptions in the cryptography, and its technology in general.

>=C2=A0 it just means that adding FancySig as = an option is=20 changing the collective security assumption from "secp256k1 is secure"=20 to "secp256k1 AND FancySig are secure"

I fundame= ntally disagree with this thesis you outlined here. The error in the second= of the three quotes 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* = violation of property rights. See [1]

The fact t= hat other coins are held in an insecure way is in no way a threat to my sec= urity. As you point out with e.g. OP_TRUE there is zero ability to prevent = people doing this.

Suppose X% of the supply is h= eld by negligent holders. Over time that X% will move away from those negli= gent holders to "thieves" (scare quotes because if literally held in output= s for which the unlocking script is publically derivable, it's debatable wh= ether it's theft, even). The thieves will either be negligent themselves or= not; in any case, over time, the coins will move to holders who are not ne= gligent.

The only thing that the system as a who= le *has* to promise is that there exists a safe, practical way to keep poss= ession (and also users should not have to just "guess" which methods are se= cure!). The system is not required, nor can it, to prevent people choosing = insecure storage methods, against the technical advice.

If value is held in large quantities in outputs which phase from se= cure to insecure then for sure there are cases (even when said technical ad= vice is amply provided!) where this leads to turbulence in value (mostly du= e to death or key loss), but value cannot be controlled or predicted anyway= . As per my message here: [1] there are private property rights principles = which cannot be violated, else the entire purpose of the project is lost. G= ood safety-engineering reasoning is unfortunately not enough to trump such = principles.

(I think the title of your thread is= interesting though: is *agility* desirable? We're borrowing the term from = other areas of the IT industry where it makes more sense perhaps; perhaps h= ere "flexibility" is the more desirable part, at least if you take *my* sid= e of this specific argument, which is that no, others' security failings do= not change the promise made to users to protect their property. Flexibilit= y helps exactly where there's a lot of uncertainty about the security of di= fferent schemes. If it costs $100 to move in quantum-secure way and $1 to m= ove in a non-*, then it is much better that flexibility exists.)
=
[1]=C2=A0https://groups.google.com/g/bitcoindev/c/7jkVS1K9= WLo/m/btgqa9t7AwAJ

Cheers,
AdamISZ/waxwing<= /div>
On Friday, February 13, 2026 at 1:23:16=E2=80=AFPM UTC-3 Pieter Wuille wr= ote:

Hi all,

A = thread was recently started on this list about cryptographic agility=20 in Bitcoin. I believe there are important limitations around that idea, and= wanted to offer my own=20 perspective. It's more a philosophical consideration, and is not=20 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=20 becoming vulnerable to theft with cryptographic breakthroughs, so do=20 your own due to fungibility, regardless of how well protected they are.

=

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

  • Camp (A), fearing an E= C-break (CRQC or otherwise), wouldn't just=20 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 classicall= y, don't want to just not use FancySig; they would want near-no= body to migrate to it, because the prospect of a potential break of Fa= ncySig threatens their own hodling.

This is of cou= rse an extreme scenario, and in reality the=20 divergence between camps may be much less incompatible, but I still=20 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= =20 people to store coins insecurely, like in an OP_TRUE script output, or=20 with private keys that are made public. I don't think this possibility= =20 affects the point above, because it is not about what possibilities=20 exist, but which approaches people are likely to / asked to adopt.=20 Nobody is incentivized or encouraged to store coins in an OP_TRUE.

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

This brings us to the question then how at all Bitcoin=20 users can migrate to new cryptography, because we cannot assume that=20 secp256k1 will last forever. And I think the answer is essentially that=20 it requires the entire ecosystem to change their assumptions. This does=20 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=20 changing the collective security assumption from "secp256k1 is secure&= quot;=20 to "secp256k1 AND FancySig are secure" once FancySig gets adopted= at=20 scale, and the discussion about adding new primitives should be treated=20 with the gravity that entails. And it means that disabling secp256k1 EC=20 operations (or near-everyone migrating to FancySig, but I think that is=20 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=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 d= o this, and 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 onl= y 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.

--=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/8fa10605-8b55-4777-9fb9-82b9c0fd1dbfn%40googlegroups.com.
------=_Part_21643_1103339747.1771070522675-- ------=_Part_21642_1592707165.1771070522675--