From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 13 Feb 2026 08:23:23 -0800 Received: from mail-oi1-f188.google.com ([209.85.167.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vqvww-00081V-5o for bitcoindev@gnusha.org; Fri, 13 Feb 2026 08:23:22 -0800 Received: by mail-oi1-f188.google.com with SMTP id 5614622812f47-463a314b114sf3835605b6e.0 for ; Fri, 13 Feb 2026 08:23:21 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1770999796; cv=pass; d=google.com; s=arc-20240605; b=cWbycyconTizALn6oo/m7blwyTD1ebpI93U93Mgq9WBr+oPh4E6l25RudBDI8cc+OK EVlA8euXzGEWloKp/wuoKSJKqUV63bazB/Mfw7PgeyP8rjSpVaQVkRNb2lIcYeSVHfiz Wjr2nHmATfG1dH5Sx+TELWF0vaxrp2/BAG1plitDeQEulJ2HqTmdmfh1wMwCPnUpdRiL SOCNJVCDy3eMF+9YgKnjwYZERMGyQ8IUQVTiI5L0lS03eI16uL7HwFdQFvPwUikhN/S6 Bju5kmqt3YIzcAXtU4pWVTgLN4GQGIs64FzR0X4AqS98lGwc7RwmyyevecrpuOktegvG hPZQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:mime-version:feedback-id:message-id :subject:from:to:date:sender:dkim-signature; bh=Xf2HhmJykij/iZ0KlT2NOeCFnCo4ncsG0KtKIcCQG6w=; fh=BZUuW1NTyLi7TRy7n832xXwRk/mch47No/UYMoDj520=; b=SbAnB3p7rdQwR+virXMPNTaLkHsrvERMreNyJiQT1Zl5XBvZ/Um5raz4uIeyioXRuu eaQjZjk92Le0fd1zvl/og15jLq8NcHM9qx3L+5OFMtfnyRMULT93hMinhMZ/nAxJf4B/ Qj7G3sltMTfyg6ueHLY6MUTiT2MdebY4biWV9g1CTzCdVcbZtUNsU0BQ6b/aTcRb0hni /NF/mA9oAqKHS/NYr6jpdDpnp+L9ilZUL1dYidkfYtCMZ6IvJbOJZnc422G5rukRcNa6 BjqC3VRkI6gHLidDKvgfnw9LYn8ScRzrrCKiwPU6ExbgKcbkXeNiVCAM9QGhcw+uUjXE smMA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail3 header.b=unFBE2Si; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.119 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1770999796; x=1771604596; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:feedback-id:message-id:subject:from :to:date:sender:from:to:cc:subject:date:message-id:reply-to; bh=Xf2HhmJykij/iZ0KlT2NOeCFnCo4ncsG0KtKIcCQG6w=; b=VmQcMWG/W0T56+7/ervdjxDD+ZcMiksF6dfMGYzhyQ5vKWRjmF5Jo3dwz7bAoAUcnI //etIecRv8x+ETQyUN2/zlHwJEMchq6cCH+rJv2hdHNYNjMXTS4jsc/xcScqZYXUGDpz I3RShbwl/S6wIYSEwWF8xS2C/wtGQpIuR1+suOpEMl24lntON8/5YkShw/pYSclb+zq8 P2VFKEqeyTAJ6SZ8dUrmMpTjXly7496nEvA2XzMjWQf4a08n230P8YcJ9+Vomx1veOP6 yHO/VXfhbZ+LFUExFMBluFwEaYxY6C7Qq/D5QdLrJ3XBnKAdwudiToyFTfPciZRIYnfb 6+3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770999796; x=1771604596; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:mime-version:feedback-id:message-id:subject:from :to:date:x-beenthere:x-gm-message-state:sender:from:to:cc:subject :date:message-id:reply-to; bh=Xf2HhmJykij/iZ0KlT2NOeCFnCo4ncsG0KtKIcCQG6w=; b=MMtj3drutAkwh1uJ+qf8HYNaAY2u8+LriT4I++4j0ncYmBDC+akiTHR5dgopA37iuD oApx9dVmEy5GfjeT658m+mrs1E11RHxfpTMJaWg4ToqYH/3xTV19bzUeDyUOehIOHnT2 mlmh36St3w+DYOQrP6HHVf8wJbXSQ0No0xZxF7WB8cENsljLOLTOwzr9qQ1BKBIWn1/t 3SwpYY0+mCuveYkaGM/zPzdxV1NmvRBGKyjRChOyYTPcrQhyyA1X9sAYxpFpihTscCTk +qOy7KTpIjClS64x5z46nz6Yppj5s3p8nvTWwWZXcT3TcF6Cqam/M6GrVEyFfc83gf8I 6qfA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUv5RRbHFTTlMgeD+Vf6VcwanQ4EgxzLp2sG0ZE61yCSjqOLa/bZUV/czP9eEdg1Vvd9ZMcga2JUaJ2@gnusha.org X-Gm-Message-State: AOJu0YwBDXCtjdqu++hjW+wQa/FCoMOcwUqw60vzMeq3aDcnU0Fif9rM 3cJF7tVBr1x7MFxcZ34PeMvTyL9FOG9abpPFo3QSa2WQuGBW37PQbhtZ X-Received: by 2002:a05:6808:191e:b0:45e:c2a7:9151 with SMTP id 5614622812f47-4639f220e29mr1110923b6e.51.1770999795986; Fri, 13 Feb 2026 08:23:15 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+GMdwVap0OpNnghJQQyacP4ngje5/O08SFYwIsiN/6/8g==" Received: by 2002:a05:6870:f21e:b0:3e8:2785:9a19 with SMTP id 586e51a60fabf-40eca6341b8ls1486791fac.1.-pod-prod-08-us; Fri, 13 Feb 2026 08:23:11 -0800 (PST) X-Received: by 2002:a05:6808:c182:b0:45e:e1f1:4af0 with SMTP id 5614622812f47-4639f27d562mr1311026b6e.63.1770999791528; Fri, 13 Feb 2026 08:23:11 -0800 (PST) Received: by 2002:ae9:e101:0:b0:8b2:e5d4:9264 with SMTP id af79cd13be357-8cb33765a09ms85a; Fri, 13 Feb 2026 08:21:03 -0800 (PST) X-Received: by 2002:a05:6102:38d0:b0:5ef:a8cb:857b with SMTP id ada2fe7eead31-5fe1ae23e53mr772057137.23.1770999662528; Fri, 13 Feb 2026 08:21:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770999662; cv=none; d=google.com; s=arc-20240605; b=G0uJljSjgHKwGNUWYohcGK6FUIXkVVXHeNgC16NoyXPgAAMx6rv9uEdGX8foG/aJF4 XNTNTDyY4hCRcn7rj9eSZFWtxqrDlTtiqcSnfCXB/0PprN4tobFRH1P3QnhdDldTOgnt GkTfAtQyu8pe5O4O+kSoMzad8L8ZzT8nVzXu/9E35R7b3WCmlZH9qyv597QOGsVMvgo3 RlgFEd0K4tOFw34x4/8ulFhq8sHzeQ/mkt46IlYBwwDFrxHKHl/spE4Mnftmi6ibHHLT V7SyxPJkfwUCMs4IlfQdGmnpj8qo3iWnXtkL4mr3hphgJYLARbSvc449hpnwWGExAPsk UdOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:message-id:subject:from:to:date :dkim-signature; bh=4Nqf8Tt++Mm9OtDHGhOqvV8qZzXomJS7W8CzCHQRiss=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=VoEKI1UJMJfSw4Jrm+X7ZcXG/xCvJeerJXjoUIDlH4Bpg7OyYBsXDpnfWdpeMDFQFW uHXoo6RfGKy9FvWdIQGY/rMJmuhnX16waZAcHxRjr614zCABQN35xuywR6Po1XeQnm99 iDzelfIko7DRqBqwe5fTF3nPNSmo549/GjMVsvvR7uAsp1sB0CaguSy2JgyziDcLNioN G33aj/7mJfiMsV4uI4OYnL4+h35tbImwhYKaUmsqV2u1r6IUASFvUmzmRDD3aL/09DlG 7DOWeeRIjGJxLyzpDtF1GxzMImZbQIjaWZq37g68uD6HJL+Cu1ATdwwYeV/fA2yyUtiy fJCA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail3 header.b=unFBE2Si; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.119 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net Received: from mail-244119.protonmail.ch (mail-244119.protonmail.ch. [109.224.244.119]) by gmr-mx.google.com with ESMTPS id a1e0cc1a2514c-94afcd37769si274814241.0.2026.02.13.08.21.02 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Feb 2026 08:21:02 -0800 (PST) Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.119 as permitted sender) client-ip=109.224.244.119; Date: Fri, 13 Feb 2026 16:20:54 +0000 To: Bitcoin Development Mailing List From: Pieter Wuille Subject: [bitcoindev] The limitations of cryptographic agility in Bitcoin Message-ID: Feedback-ID: 19463299:user:proton X-Pm-Message-ID: d44a692fd061f01fb88dbc0b23963e5e33024a22 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_8NrESGohschF8yMPqLPJBJQOf5L8YYdUuX0iHpi8" X-Original-Sender: bitcoin-dev@wuille.net X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail3 header.b=unFBE2Si; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 109.224.244.119 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net 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.7 (/) --b1=_8NrESGohschF8yMPqLPJBJQOf5L8YYdUuX0iHpi8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, A [thread](https://groups.google.com/g/bitcoindev/c/7jkVS1K9WLo) was recent= ly started on this list about cryptographic agility in Bitcoin. I believe t= here 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 pr= imitives used to protect their own coins, from a set of available primitive= s 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 breakthro= ughs, so do your own due to fungibility, regardless of how well protected t= hey 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 appea= ring arguing that such a scheme should be adopted, because it's the silver = bullet the ecosystem has been waiting for. At the same time, another camp (= B) may appear cautioning against this, because the scheme is new, hasn't st= ood the test of time, and isn't well-analyzed. These two camps may find the= mselves in a fundamental disagreement: - Camp (A), fearing an EC-break (CRQC or otherwise), wouldn't just want Fan= cySig as an option - they would want (feasible or not) that near-everyone m= igrates to it, because the prospect of millions of BTC in EC-vulnerable coi= ns threatens their own hodling. - Camp (B), fearing the possibility that FancySig gets broken soon, possibl= y even [classically](https://www.quantamagazine.org/post-quantum-cryptograp= hy-scheme-is-cracked-on-a-laptop-20220824/), don't want to just not use Fan= cySig; they would want near-nobody to migrate to it, because the prospect o= f a potential break of FancySig threatens their own hodling. This is of course an extreme scenario, and in reality the divergence betwee= n camps may be much less incompatible, but I still think it's a good demons= tration of the fact that despite being a currency for enemies, Bitcoin esse= ntially 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 c= oins insecurely, like in an OP_TRUE script output, or with private keys tha= t are made public. I don't think this possibility affects the point above, = because it is not about what possibilities exist, but which approaches peop= le 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 kn= ow the answer. Possibly, the prospect of 100k BTC becoming vulnerable to th= eft 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 foreve= r. And I think the answer is essentially that it requires the entire ecosys= tem to change their assumptions. This does not mean that adding a new opt-i= n cryptographic primitive is infeasible or a bad idea; it just means that a= dding FancySig as an option is changing the collective security assumption = from "secp256k1 is secure" to "secp256k1 AND FancySig are secure" once Fanc= ySig gets adopted at scale, and the discussion about adding new primitives = should be treated with the gravity that entails. And it means that disablin= g secp256k1 EC operations (or near-everyone migrating to FancySig, but I th= ink that is unlikely) is the only way to change the collective security ass= umption from "secp256k1 AND FancySig are secure" to "FancySig is secure". Because of that, if CRQCs or other EC-breaks become reality, or just the fe= ar about them becomes significant enough, I do believe that disabling EC op= codes will be necessary in any economically-relevant surviving chain, due t= o the millions of BTC that are unlikely to ever move. Note that I am not ar= guing that "Bitcoin" will, should, or even can do 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 only a= fter a CRQC has been demonstrated to exist. Still, given a severe enough th= reat I think it is inevitable, and I think that this means we shouldn't wor= ry too much about what happens in chains in which EC is not disabled while = simultaneously EC is considered insecure: such chains will be worthless any= way. -- 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/= THqOJuI_s5C8B9jkklN73BB_Hzb9SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh8NxxYbXwv4v6ikp= StguW-QEvef4WgBZ7AQDz00P0st91FMA%3D%40wuille.net. --b1=_8NrESGohschF8yMPqLPJBJQOf5L8YYdUuX0iHpi8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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 been wa= iting=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:

  • Cam= p (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.
  • Camp (B), fearing the possibility = that FancySig gets broken soon, possibly even classically, don't want to just not use FancySig;= they would want near-nobody to migrate to it, because the prospec= t of a potential break of FancySig threatens their own hodling.
This is of course 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"=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".

Becau= se 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 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.

-- 
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/bitcoindev/THqOJ= uI_s5C8B9jkklN73BB_Hzb9SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh8NxxYbXwv4v6ikpStguW= -QEvef4WgBZ7AQDz00P0st91FMA%3D%40wuille.net.
--b1=_8NrESGohschF8yMPqLPJBJQOf5L8YYdUuX0iHpi8--