From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 17 Feb 2026 12:10:07 -0800 Received: from mail-oo1-f57.google.com ([209.85.161.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vsROX-00009y-Ts for bitcoindev@gnusha.org; Tue, 17 Feb 2026 12:10:07 -0800 Received: by mail-oo1-f57.google.com with SMTP id 006d021491bc7-6795b03ffdbsf41284057eaf.0 for ; Tue, 17 Feb 2026 12:10:05 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771359000; cv=pass; d=google.com; s=arc-20240605; b=l3UmBIqCyCYD6hRs/uWFrb7KkiUOXZwP3vxgUKxitoLMpgIMt05jir0CealNFwiJGF TGdPqF1+vUq692Qz7B1PQNPjyQfwwktVd94FAKpKle19U9kE+QmFtMUl2csE9OsXO4qo +ltx1tZHg3IHk7yDv8GukhMFoNY/zCwvwpXg9NV5g0mRrhyOQycMDCCZ89Waj3+plsGd d9ZgxySVC+gZip1ourfgIXvVPIleATHzKZz8XBQLM86tkdi7zu0ZIJWnfAvQ98p6HfNh NeguENZIFCJqPOUDbqcBt9JflFaae0yE+tmD73QcdkqTn5C3ymiJoj+6vb/iJAGyTCOA mcVQ== 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:references :in-reply-to:message-id:subject:from:to:date:sender:dkim-signature; bh=K8Xnxe81P1AXepqj51F4OyRVku0yJLR+5G0Y0SPEqaw=; fh=+cA4AlKkbm5iuqOzXR58x8rLgmUxCpM6VJ/+lFGD5fY=; b=BuWcnn1Txc97/K6NGkEYyqoKR9vak9lsWZ6QY64V/QomFp8ZP2MBxS+QRc6OLm5CIu h3iYxgpbmMJAifMi4D+ZrMJWVnmqVjoXh8hBYzCex9AwVgbGALsElToSWwLOY7ZkIreS djhbDmppr6bhTyNX1HsR2zXgYr+DjF8TjiAyTuEMjq5QJmvFhlzbBwbWEjtygvX2EAkO 3z93sp84d3aceoFjqcbN+4Dmvi44JGe+xYZRXYusox5ZC24t6SCNGSHucq6D9x/iXxKU wDBkt+3TURJKotso8dX0AU/59AyFUyOJPte53coNTY88bHwmXBdclGoVCYAZ5rR3WEbt IyfA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail3 header.b=V8GKLYYO; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.23 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=1771359000; x=1771963800; 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:references:in-reply-to :message-id:subject:from:to:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=K8Xnxe81P1AXepqj51F4OyRVku0yJLR+5G0Y0SPEqaw=; b=nH8DBNu2oz+Kjj5/Lpw2o8wyScGjNLr1cEG5QDs0lQonL09fI5Ly/mB8hxGQikFMD7 5DQxrg2gnxL+LyWcX8XcBZyTRI4JYPN4sGy4lpgzaRgegk6NEmaT3ycX7ZdpAVn1rryG Tygq36GmszIhv3ud4KRM3O1zo/o20UfJhmOPfNflq7zSDcQFn7W4oAcYJWGpVrlmsAd2 eAiRh8jm52iKYhRhaczKAM9jeYBpuGaiDARPE32fYZvCVIjdrXB4Ag37vxj1vuXfmM6n pYfbIuxj/XY+gyg+ZPznwskZn5lBolUvepukaFaO0bvg1d1pBAJbuCEokDvbGDIrrtzN bZvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771359000; x=1771963800; 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:references:in-reply-to :message-id:subject:from:to:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=K8Xnxe81P1AXepqj51F4OyRVku0yJLR+5G0Y0SPEqaw=; b=kq4xVe7tqGqlCtlANTE4iphKSSnU8z/JCQARW2Ii7P95nTT4+eGT8tz6ZyASIqBlIy D4AiguStXmsjtJXXxPHUwRFQZL2JYnAWxHTkestPz8jqfkHr79CampSIJsiYb4vXD9kG XGnkDFgk6M2NcSI5p9smAYeP082arASwvdCAhX8xc+mhTB9i1RmuA5tG+ldX3tNFCF4R moNU5J8S6VtyAQ37nurpIr0rqtxax8dxqH5BtvO+iGMIlZ3f9kQUYsLHiueVEhkC0FNx JcqTJGqtYInk7k1qFR4ZZokV8BjD0+ekxbsm4wTu9+EyMjuQMjYYOjg4XNAa31KkC2Ez ilvg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUMyQiXpJdZEXQJ5a3XSqob8JocIeKS1ZPml07+P/w04frNl8tp1JL4y3H9pHiJMyf2KzHNNHVf/z5U@gnusha.org X-Gm-Message-State: AOJu0YzYA1XgcCqb4qEHQ3eK5FnBFRUmo5qI4cIn5H5ijdGSHwRBd8fX 4hyzBQPm0d8skqsAKeWEzbR+TNmrN4EY1IsK4VZuGGj+YZdp3SArJnY7 X-Received: by 2002:a05:6820:440c:b0:679:97d5:dd25 with SMTP id 006d021491bc7-67997d5e00amr2016568eaf.56.1771358999570; Tue, 17 Feb 2026 12:09:59 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HZe8JCnUUesc7trtQRk+qYzSb9Y9J1Dmbqus1eYCrorg==" Received: by 2002:a05:6820:f002:b0:66a:c0c3:3f26 with SMTP id 006d021491bc7-6784b0d5aa6ls2837329eaf.0.-pod-prod-08-us; Tue, 17 Feb 2026 12:09:54 -0800 (PST) X-Received: by 2002:a05:6808:428e:b0:463:ab56:9ed2 with SMTP id 5614622812f47-463ab56ab1dmr5581935b6e.17.1771358994469; Tue, 17 Feb 2026 12:09:54 -0800 (PST) Received: by 2002:a05:600c:158c:b0:483:6d47:ea7 with SMTP id 5b1f17b1804b1-483702ee159ms5e9; Tue, 17 Feb 2026 12:04:45 -0800 (PST) X-Received: by 2002:a05:600c:8b2f:b0:46f:c55a:5a8d with SMTP id 5b1f17b1804b1-483739ff865mr216595365e9.4.1771358683413; Tue, 17 Feb 2026 12:04:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771358683; cv=none; d=google.com; s=arc-20240605; b=T58pbopPd2A4Qf56r+SHN/gdCmOZhte81IJ2zCsbvvzWxIex/1/3HijTXG4OnNAjDB 4szXS+jcDvgd5UUxWo11WoJFupJXQnZ/m9BI7WJBNooNUh4R+gXUHhLbzuGq8xWaHtbD I4s+PGj1n12MtmceNJ9QNrUQyIl6C40sy/fOGixC3wRhP0EAIh0k0oSNpS9upEop8VtQ Ylt21xezyQQznRRSf+ZgwNDSS4PxLc/vpKaptsJptzT7Gi+9ZSS7cwMOsPvffuq0Am3s AMWMrvtW2Ox/N44vqQ63fui66nBLFGItEf46RrcHQoIHdsJ5p/mTyim+F7Cd2d57YDnn 1mRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :from:to:date:dkim-signature; bh=5Eepei16J/nrfnJ7b11s7lIfYPBlX9Te0ExPz3+WBlk=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=RmR+W5WpakduYiV90Na3jPNKfBCBvq8WkZxvWiNKUxsBYw7MmoFGgDraTib4lkXxvH qJSMbKR1aoqAfua7mGc8FaF7mEWfjgfYln1iQDqp67hYsHso7GiTRLonzxo6PWAMFnKm l4qatyTo+UGgNGNNuGPw4tJFw23iZSILJbN+sATQcLViGHqB+MRuLORPFaSf4qDKZd/A WzI/X+BF/PqC9jBY2KAWs3s7aLYRJz35f7rCmEb5cF+g95wEGW4WeOCQpgrVw0hjljwT vX1WW+vdY8Zu6HEtBhwUkWXN3B5If3FJWJTQrHyKOQVlFB22XY4vCMFBWnUtv4/psneL vmag==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@wuille.net header.s=protonmail3 header.b=V8GKLYYO; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.23 as permitted sender) smtp.mailfrom=bitcoin-dev@wuille.net; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=wuille.net Received: from mail-4323.protonmail.ch (mail-4323.protonmail.ch. [185.70.43.23]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-43796ac340dsi412327f8f.4.2026.02.17.12.04.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Feb 2026 12:04:42 -0800 (PST) Received-SPF: pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.23 as permitted sender) client-ip=185.70.43.23; Date: Tue, 17 Feb 2026 20:04:39 +0000 To: Bitcoin Development Mailing List From: Pieter Wuille Subject: [bitcoindev] Re: The limitations of cryptographic agility in Bitcoin Message-ID: In-Reply-To: References: Feedback-ID: 19463299:user:proton X-Pm-Message-ID: ff2cefb8af2b294051915ab27091651f7f8cea1b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_Xn8Ik8psEFLasoruVCVjNIOvUunmg5iLFYw7SY4P38c" 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=V8GKLYYO; spf=pass (google.com: domain of bitcoin-dev@wuille.net designates 185.70.43.23 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=_Xn8Ik8psEFLasoruVCVjNIOvUunmg5iLFYw7SY4P38c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thank you all for the interesting comments. I want to respond to some of th= em, but feel like I need to clarify something first. I am not proposing that coins are frozen in Bitcoin, as I don't personally = believe Bitcoin is interesting if it needs to give up that fundamental prop= erty. Rather, I am expressing the belief that levels of threat/fear can exi= st which cause the chain(s) in which large amounts of perceived-vulnerable = coins remain to lose value to a devastating extent. This can take many form= s. Maybe 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 C= RQC becomes reality, and that chain becomes more economically relevant. May= be it's not called Bitcoin. Maybe nearly all(*) coins migrate to PQC addres= ses. Maybe CRQC fear fizzles out after some time. Maybe Bitcoin just doesn'= t survive CRQC fears. This is not a statement about what should or shouldn't be done about percei= ved-vulnerable coins. It is an observation that may however influence desig= n around the introduction of other schemes: - Giving users the option to migrate to schemes with a different security a= ssumption is not enough to remove that security assumption from the system.= Bitcoin as a whole, and all its users including those who migrate, are and= remain dependent on secp256k1 security as long as many(*) secp256k1-secure= d coins remain. - Users adopting schemes with a different security assumption at scale(*) i= s opting all users including those who do not migrate, into that security a= ssumption. - We can design things for a future where no substantial(*) amount of coins= are perceived to be vulnerable. Not because we're planning to freeze the c= oins that are, but because future chains in which such coins remain will lo= se value. I am not stating what the solution to get there is - I don't know= - I am stating that we can operate under the premise that a solution will = be found, because futures in which there isn't are uninteresting. > I fundamentally disagree with this thesis you outlined here. The error in= the second of the three quotes is subtle: it's not that rational users wil= l not *want* others to migrate (of course, they will), it's that they will = not *want* violation of property rights. See [1] Why not both? For Bitcoin to relevant, it needs to have value. One importan= t component of that is differentiation with competing monetary systems, whi= ch includes properties like a fixed inflation schedule and inviolable prope= rty rights. But not having market fear wipe out your coins' value, even if = you keep them, is a component too. I agree Bitcoin cannot promise anything about its exchange rate with real-w= orld goods and services, or other currencies, but that doesn't mean this is= n't relevant to its users. And as developers we ought to design for a syste= m with properties we care about, but that doesn't mean we cannot make obser= vations about the reality the system exists in. > Suppose X% of the supply is held by negligent holders. Over time that X% = will move away from those negligent holders to "thieves" (scare quotes beca= use if literally held in outputs for which the unlocking script is publical= ly derivable, it's debatable whether it's theft, even). The thieves will ei= ther be negligent themselves or not; in any case, over time, the coins will= move to holders who are not negligent. Ironically, I think that actual "theft" (scare quotes or not) in this conte= xt is much less concerning than uncertainty and fear about the possibility = of theft... and I realize this is getting closer to being a statement about= human psychology than technical properties. Let's say a PQC scheme is adde= d to Bitcoin in the next few years, and it sees some mild adoption. Then we= suddenly wake up one 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 assumed it was a CRQC. This might not affect Bitcoin's value t= hat much - after all, most of the damage is already done. However, someone = publishing a statement "I have a CRQC", signed by the same set of pubkeys t= hat held those coins, would likely send the market tumbling down, and decim= ate 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 mea= n it also won't be concerned about the potential of large amounts of coins = becoming vulnerable. > Anyone who wants quantum security but is also afraid of fully trusting un= tested new algorithms like FancySig could easily use a hybrid locking scrip= t which requires both BIP340 AND FancySig signatures. This misses the point I was trying to make. If someone were truly hesitant = about FancySig's security, then having them moving their own coins into a "= BIP340 AND FancySig" outputs isn't a solution. They would would want everyo= ne(*) who wants to use FancySig to stick to "BIP340 AND FancySig", i.e., th= is would be an argument against supporting FancySig-only outputs. And that = is indeed a solution to the "people don't trust FancySig" problem, but it c= omes at a significant cost too. However, I only included the possibility of people distrustful in the other= direction (fear of a new scheme) in my example to show the extreme incompa= tibility it may lead to. The point that (IMO) all Bitcoin users remain depe= ndent on secp256k1 security as long as a substantial(*) amount of coins pro= tected (solely) by it remain, is far more important. > Disabling them like you propose? To be clear, I am not proposing that, and I'm not interested in discussing = what Bitcoin should do. (*) =3D All of these statements are about some sufficiently large number of= coins, which I don't know what it is. -- Pieter On Friday, February 13th, 2026 at 11:20 AM, Pieter Wuille wrote: > Hi all, > > A [thread](https://groups.google.com/g/bitcoindev/c/7jkVS1K9WLo) was rece= ntly started on this list about cryptographic agility in Bitcoin. I believe= there are important limitations around that idea, and wanted to offer my o= wn perspective. It's more a philosophical consideration, and is not intende= d 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 available primiti= ves that may change over time. I think this ignores how important it is wha= t others do with their coins. If others' coins lose value, for example due = to fears about them becoming vulnerable to theft with cryptographic breakth= roughs, so do your own due to fungibility, regardless of how well protected= they are. > > As an extreme thought-experiment, imagine that tomorrow a new cryptograph= ic signature scheme FancySig is published, with all the features that Bitco= in 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 app= earing arguing that such a scheme should be adopted, because it's the silve= r 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 = stood the test of time, and isn't well-analyzed. These two camps may find t= hemselves in a fundamental disagreement: > > - Camp (A), fearing an EC-break (CRQC or otherwise), wouldn't just want F= ancySig as an option - they would want (feasible or not) that near-everyone= migrates to it, because the prospect of millions of BTC in EC-vulnerable c= oins threatens their own hodling. > > - Camp (B), fearing the possibility that FancySig gets broken soon, possi= bly even [classically](https://www.quantamagazine.org/post-quantum-cryptogr= aphy-scheme-is-cracked-on-a-laptop-20220824/), don't want to just not use F= ancySig; they would want near-nobody to migrate to it, because the prospect= of a potential break of FancySig threatens their own hodling. > > This is of course an extreme scenario, and in reality the divergence betw= een camps may be much less incompatible, but I still think it's a good demo= nstration of the fact that despite being a currency for enemies, Bitcoin es= sentially requires users to share trust assumptions in the cryptography, an= d 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 t= hat are made public. I don't think this possibility affects the point above= , because it is not about what possibilities exist, but which approaches pe= ople are likely to / asked to adopt. Nobody is incentivized or encouraged t= o 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 10= M BTC becoming vulnerable may. Depending on where your belief about this li= es, you may end up with very different conclusions. Still, to me it is clea= r that some threshold exists above which I would be uncomfortable with seei= ng 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 fore= ver. And I think the answer is essentially that it requires the entire ecos= ystem 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 assumptio= n from "secp256k1 is secure" to "secp256k1 AND FancySig are secure" once Fa= ncySig gets adopted at scale, and the discussion about adding new primitive= s should be treated with the gravity that entails. And it means that disabl= ing secp256k1 EC operations (or near-everyone migrating to FancySig, but I = think that is unlikely) is the only way to change the collective security a= ssumption 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 do this, and I'm quite sur= e that the inherent confiscation required will make the result uninterestin= g to me personally. It may be that such disabling only happens in a fork th= at 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 enough = threat I think it is inevitable, and I think that this means we shouldn't w= orry too much about what happens in chains in which EC is not disabled whil= e simultaneously EC is considered insecure: such chains will be worthless a= nyway. > > -- > 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/= fpr54OwSyhxOLkSM0ThB2HQN97XFCTL0c3oHbb9A-jmN0TiO6m38a-MqHYpHK9g4tokROwjJGFf= FLjYtGluNRBg70PA4YThX9cMAiyw1B1k%3D%40wuille.net. --b1=_Xn8Ik8psEFLasoruVCVjNIOvUunmg5iLFYw7SY4P38c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thank you all for the interesting comments. I= want to respond to some of them, but feel like I need to clarify something= first.

I= am not proposing that coins are frozen in Bitcoin, as I don't personal= ly believe Bitcoin is interesting if it needs to give up that fundamental p= roperty. Rather, I am expressing the belief that levels of threat/fear can = exist which cause the chain(s) in which large amounts of perceived-vulnerab= le coins remain to lose value to a devastating extent. This can take many f= orms. Maybe none of us are around anymore, and the people then hold differe= nt values. Maybe some people create a freezing fork before, or even after, = a CRQC becomes reality, and that chain becomes more economically relevant. = Maybe it's not called Bitcoin. Maybe nearly all(*) coins migrate to PQC add= resses. Maybe CRQC fear fizzles out after some time. Maybe Bitcoin just doe= sn't survive CRQC fears.

This is not a statement about what should or shouldn't be done about perce= ived-vulnerable coins. It is an observation that may however influence desi= gn around the introduction of other schemes:
  • Giving users the option to migrate to schemes with a different= security assumption is not enough to remove that security assumption from = the system. Bitcoin as a whole, and all its users including those who migra= te, are and remain dependent on secp256k1 security as long as many(*) secp2= 56k1-secured coins remain.
  • Users a= dopting schemes with a different security assumption at scale(*) is opting = all users including those who do not migrate, into that security assumption= .
  • We can design things for a futur= e where no substantial(*) amount of coins are perceived to be vulnerable. N= ot because we're planning to freeze the coins that are, but because future = chains in which such coins remain will lose value. I am not stating what th= e solution to get there is - I don't know - I am stating that we can operat= e under the premise that a solution will be found, because futures in which= there isn't are uninteresting.

I fundamentally = 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* other= s to migrate (of course, they will), it's that they will not *want* violati= on of property rights. See [1]

Wh= y not both? For Bitcoin to relevant, it needs to have value. One important = component of that is differentiation with competing monetary systems, which= includes properties like a fixed inflation schedule and inviolable propert= y rights. But not having market fear wipe out your coins' value, even if yo= u keep them, is a component too.

I agree Bitcoin c= annot promise anything about its exchange rate with real-world goods and se= rvices, or other currencies, but that doesn't mean this isn't relevant to i= ts 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 time that X% will move away = from those negligent holders to "thieves" (scare quotes because if literall= y held in outputs for which the unlocking script is publically derivable, i= t's debatable whether it's theft, even). The thieves will either be neglige= nt themselves or not; in any case, over time, the coins will move to holder= s who are not negligent.

Ironically, I = think that actual "theft" (scare quotes or not) in this context is much les= s concerning than uncertainty and fear about the possibility of theft... an= d I realize this is getting closer to being a statement about human psychol= ogy than technical properties. Let's say a PQC scheme is added to Bitcoin i= n the next few years, and it sees some mild adoption. Then we suddenly wake= up one 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 a= ssumed it was a CRQC. This might not affect Bitcoin's value that much - aft= er all, most of the damage is already done. However, someone publishing a s= tatement "I have a CRQC", signed by the same set of pubkeys that held those= coins, would likely send the market tumbling down, and decimate Bitcoin's = relevance for a long time.

This is also my respons= e to Light's analogy with the systemic risk imposed by large amounts of coi= ns held by exchanges. I think the ecosystem ought to be more concerned abou= t that risk, but the fact that it isn't does not mean it also won't be conc= erned about the potential of large amounts of coins becoming vulnerable.

Anyone who wants quantum security but is also afraid of = fully trusting untested new algorithms like FancySig could easily use a hyb= rid locking script which requires both BIP340 AND FancySig signatures.

This misses the point I was trying to make. If so= meone were truly hesitant about FancySig's security, then having them movin= g their own coins into a "BIP340 AND FancySig" outputs isn't a solution. Th= ey would would want everyone(*) who wants to use FancySig to stick t= o "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" problem, but it comes at a significant cost too.
<= br>
However, I only included the possibility of people distrustful= in the other direction (fear of a new scheme) in my example to show the ex= treme incompatibility it may lead to. The point that (IMO) all Bitcoin user= s remain dependent on secp256k1 security as long as a substantial(*) amount= of coins protected (solely) by it remain, is far more important. 

Disabling them like you propose?

=
To be clear= , I am not proposing that, and I'm not interested in discussing what Bitcoi= n should do.

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

-- 
Pieter

On Friday, February 13th, 2026 at 11:20 AM= , Pieter Wuille <bitcoin-dev@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 been wa= iting 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:

  • Cam= p (A), fearing an EC-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 would want near-nobody to m= igrate to it, because the prospect of a potential break of FancySig th= reatens their own hodling.

This is of course an ex= treme 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" 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".

Becau= se 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 do this, an= d 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 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.

-- 
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/fpr54= OwSyhxOLkSM0ThB2HQN97XFCTL0c3oHbb9A-jmN0TiO6m38a-MqHYpHK9g4tokROwjJGFfFLjYt= GluNRBg70PA4YThX9cMAiyw1B1k%3D%40wuille.net.
--b1=_Xn8Ik8psEFLasoruVCVjNIOvUunmg5iLFYw7SY4P38c--