From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 18 Feb 2026 23:23:52 -0800 Received: from mail-oo1-f58.google.com ([209.85.161.58]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vsyO6-0006tv-Rk for bitcoindev@gnusha.org; Wed, 18 Feb 2026 23:23:52 -0800 Received: by mail-oo1-f58.google.com with SMTP id 006d021491bc7-679943693c0sf10199987eaf.3 for ; Wed, 18 Feb 2026 23:23:50 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771485825; cv=pass; d=google.com; s=arc-20240605; b=lhzyEUbtrMYgyfOOEyY6kZZZK60Mk51kOhKIsVRvQOe7EAZOmDOXYTP0bTdvv+DZ8Q h7g98XgN49f4UnJ0D9r6iDXYSns0/PwEAotd1r0BDVt9SPsOSv3bj3vv9+vw1QUNlOxl zSMzs0tvuaKomXSVp0qAa/q+qducWw+3XSxtVWLhqYB7oW2X+KF0sO3I9w0qKM2KPdtU PK+r+UObITaOHNhtl3JTYYfguXWNOiQFudqqdEkWdrD7t7FE3Ool4WBntekxwgUEkSpj D9W/N76KuSYTOiCohD1F35okcuatLVCADn2ZbQr2Rnsg6HiX9kqSAqRnPAe9dA6ySYi2 pmrg== 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:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:cc:from:to:date :dkim-signature; bh=+CyBl8j631BDbxEhe/UCthZc8EzVE2ezXtRQTPL1mC4=; fh=aUnZHVZJ7dZxveC+hylu6uY0juuZT7iOYxvUKlWxPEg=; b=gigmoLqB2NVvStLQza5lvNrodrnmYIx4oWyJUoJq+9vpwnmJ8fO4mMVZEmJpttyuEz TggFkouTfHXRmc1udPc4DZr3ZDYiKa7HaeLrAB1yWDCCYCgGXo3H+nUGmwlGhZjEdVwq 8EXnJhpnXXyW41JRoWaQpnWFbLzChFDBQALe9AnUhffCJutgsq3IBpjW+92SPb15E4wl U0v33rE+RLXcngvCLRWdp6zvLfPEDrmtQpiOKlfrVF2iF8IR7DlOay8/pRjHiyEU/OPn wAHB+R9662X4TnSEHllno+WW0R83l8r09EhgRBkrcz7tRXK2herOz7sOvuqtRUQUGNGy ZQaQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=77slmwvlqnfx5obkwiiq5hyc3u.protonmail header.b=EMvb9mi0; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.99 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1771485825; x=1772090625; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:from:to:cc:subject:date:message-id:reply-to; bh=+CyBl8j631BDbxEhe/UCthZc8EzVE2ezXtRQTPL1mC4=; b=XlSIx0DFZbgGF6Ot8hAkVRHTdDJzEkaHe8sp7p/vStOcBcjRPhCoUzR20UioCk+fPK N0SYkuhORGsI7BgxH4dbKcyKX27ugeTmWUc5imOeSvOSDJLqedqFImoGiPubl0qvoGcn hmp+xXPzgO7K9Fx7FvUxgnLVeQkR1dSIgzXU9Q1JzU7kIdCep593v4KaRRA67AN+4KSy X4Y5WC8OF50GQzftyyxl4r7rXBCJUbWohm7MJn6BOJhKmZpmwTxaMMg97xPz7R/UXQpT 6quKnHCfUzFIH/hD+hTFOk5dUuZlp59jAHHNazZmKYir9oBxASVSx9bZeoVVJBo5vIyL lN1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771485825; x=1772090625; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:cc:from:to :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=+CyBl8j631BDbxEhe/UCthZc8EzVE2ezXtRQTPL1mC4=; b=JovvLVVMgAWJYnXdERRZDtH89usyZx0t9doHJMhRncThedcscHFA+1uFrswDf3+j5v oAW6uF7DQz/0Inui+1gedcOFA1BFuERkP+v7+2y2PJv1Rxxr91zOoRU2pmmmbMZqdQZ1 QsVckZ4B2xyiiJvoFCWDoxhtDdGOx7EaIRLDfFOLNtdlVPbbQl16TqvSrr1mhz9Q07sQ oIYgsujc5956mtO6R/yO1kjGYED3gufPHl7W4ibAY67mRM8vmL3mrejz3OlHMeVRm1x1 qnjX5OLsNc8ckJ7TGIYbFB7RtK3x77AFI4l0g6OUq2n0NeekYoLkfnEGn5v3RA6810h2 3/Kg== X-Forwarded-Encrypted: i=2; AJvYcCX2qoMSZF69Dys9BODc6P36/fGirBs0RvLu51TBUvSZ9pfD4nFnczeWZ0XbVV/WOSmRHrif1fKZVi7N@gnusha.org X-Gm-Message-State: AOJu0Yy/WL/9UqnMclc1YdKh8Yio9AvwdSTNj3nG4Z6eikA4Y+fOjToZ rN1yVaUf7KKkjyZQkLY7bvdh0enOwGmpDXGGqrR9lZ0ZvndlYuwgPeDi X-Received: by 2002:a05:6820:4a0d:b0:679:92a8:5aad with SMTP id 006d021491bc7-679a71b9ad2mr1807769eaf.8.1771485824796; Wed, 18 Feb 2026 23:23:44 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+EbbUAbR93P6f96yNc40pQx/UxXMmBNcqOydL6hR0kXyg==" Received: by 2002:a05:6820:61b:b0:66a:9dfd:bbff with SMTP id 006d021491bc7-679927dc9f8ls2986465eaf.2.-pod-prod-09-us; Wed, 18 Feb 2026 23:23:40 -0800 (PST) X-Received: by 2002:a05:6808:67c5:b0:463:93a5:a5bf with SMTP id 5614622812f47-46410b44d53mr2546554b6e.8.1771485820544; Wed, 18 Feb 2026 23:23:40 -0800 (PST) Received: by 2002:aa7:de8e:0:b0:65c:5abe:4e6c with SMTP id 4fb4d7f45d1cf-65c5abe518bmsa12; Wed, 18 Feb 2026 23:22:09 -0800 (PST) X-Received: by 2002:a05:6402:34ca:b0:65c:354e:94f0 with SMTP id 4fb4d7f45d1cf-65c354e9ac3mr5608847a12.8.1771485726963; Wed, 18 Feb 2026 23:22:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771485726; cv=none; d=google.com; s=arc-20240605; b=CBgE1/vgzYfV95V8JDmzgWhC251H5sugNzwpHKX37ZEMKUiC7T99U4of1JYi19NRRV y4O4UB7QNIfW6B8GStpWL7p52c+iV/VMr+nOkS3EWpkoyeWDq/QR539j7vbJkIZ89AUS rv/BeX9R5WFRgbduF4elPFZqQl6QTvuswTdOvdknGka/fjakFlLCkCorv9qfgjWPx+ZP Ip5GTb8o+6y4VO9ZjPpaN2VkkpfI+5TlfWCZKXzLthkQkgDVxqTmI3iBe9Fpxi1RM2Os pxfSvMbW1Vf5A9OtzH/u5eflDpt1syVLybX2XoM+oV1h8WmzveUEmiLuPoHsEaXJR4t8 DNcw== 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 :cc:from:to:date:dkim-signature; bh=HMMhWu/R3xDqohKzGmtnpR7QugObJynoF04sQwPTLhU=; fh=dRl5MJeON1RwI+/xO4/cP/Y3U38+pgB9/4rd/p1o9tg=; b=JOteK58SeDgs8AYMp3W7kpEFc8s0dDgvRA2EX9qKJVbZ6pVKlSa6r79Dowb33awK86 38zQlX0FIwiwKy2eXlgahIRYdTF5PYtBU90QrALvTM+kB9Y4qRpIAwDepSruTZwUhgQe ziC9avyScx/8bj/zHg6yE/rpMb1IGTy3Xsd3zm+QkAY6IZ3wrq0dozazIhB4dLceXH3v K6NRChARb1BV5f2+L5T72aKfxZffgjC4Z196ziRDm+57ReZkWyCMtYmlB93dB4ZVKnOT ZD819rqkGCkI15+ubHK32JxQg9dAr+gYy6kO0A1umA+/V6ZRNWqlSFHR2z4CClG6upqk fVjQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=77slmwvlqnfx5obkwiiq5hyc3u.protonmail header.b=EMvb9mi0; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.99 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-10699.protonmail.ch (mail-10699.protonmail.ch. [79.135.106.99]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-65bad4fdc46si391163a12.3.2026.02.18.23.22.06 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Feb 2026 23:22:06 -0800 (PST) Received-SPF: pass (google.com: domain of conduition@proton.me designates 79.135.106.99 as permitted sender) client-ip=79.135.106.99; Date: Thu, 19 Feb 2026 07:22:00 +0000 To: Pieter Wuille From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: The limitations of cryptographic agility in Bitcoin Message-ID: In-Reply-To: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: bd559fa8fb171d4973f46f0ee435eeba0c53b4fe MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------81d255cec3ea454b7ab6f150b1a533565811833a3076faaaba85573f2f136935"; charset=utf-8 X-Original-Sender: conduition@proton.me X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=77slmwvlqnfx5obkwiiq5hyc3u.protonmail header.b=EMvb9mi0; spf=pass (google.com: domain of conduition@proton.me designates 79.135.106.99 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me X-Original-From: conduition Reply-To: conduition 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: -1.0 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------81d255cec3ea454b7ab6f150b1a533565811833a3076faaaba85573f2f136935 Content-Type: multipart/mixed;boundary=---------------------270f7fd61afc66e6ea4529f56550e7e9 -----------------------270f7fd61afc66e6ea4529f56550e7e9 Content-Type: multipart/alternative;boundary=---------------------65c8dd9872c65af46910dc7d4baa7a7e -----------------------65c8dd9872c65af46910dc7d4baa7a7e Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Thanks for elaborating, Pieter. I think i understand the point you're getti= ng at a bit better now. You are saying that I as a self-interested Bitcoin = user care about the cryptographic assumptions made by other Bitcoin users, = insofar as other users' choices affect the market value of my own coins. You're very right that this concern is highly relevant for holders worried = about quantum procrastinators, who by failing to make a choice at all will = be making a de-facto choice to protect their coins with a cryptosystem that= may soon be broken. However, i disagree on your point here: > 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. I disagree for the same reasons I outlined earlier: we have many options to= design wallet standards which minimize users' exposure to novel attacks on= young cryptosystems. Provided most wallets do not intentionally stray from= best-practices in PQ wallet security, this risk - and any FUD borne from i= t - should be entirely manageable, especially considering the number one ca= ndidate everyone seems to agree on is hash-based signatures, which are even= more conservative than BIP340. But as you say, these fears are far less relevant than fears from the other= camp (FUD around legacy coins protected only by ECDLP). So let's focus on = that problem. > This is not a statement about what should or shouldn't be done about perc= eived-vulnerable coins. > > 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'm a bit confused by this statement. You're saying we shouldn't worry abou= t PQ-vulnerable coins because any chain in which they are exploitable would= be worthless anyway? But you're NOT advocating for a freeze which would pr= event coins from being stolen. I think these aren't compatible views. If we do not freeze EC spending and = replace it with PQ-safe rescue protocols, then those coins will be vulnerab= le, and as per your comment, the chain will become worthless. Thus, the onl= y "interesting" chains are the ones which implement a freeze of some kind -= at least under your assumptions. Personally I am not entirely convinced of this claim that "future chains in= which [PQ-Vulnerable] coins remain will lose value" and will therefore be = "uninteresting" to work on. But I'll leave that discussion for another day.= =C2=A0 FWIW i think a freeze (with rescue protocols) is indeed a good idea and we = should work on it, maybe not today but eventually. regards, conduitionOn Tuesday, February 17th, 2026 at 8:10 PM, Pieter Wuille wrote: > Hi, >=20 > Thank you all for the interesting comments. I want to respond to some of = them, but feel like I need to clarify something first. >=20 > I am not proposing that coins are frozen in Bitcoin, as I don't personall= y believe Bitcoin is interesting if it needs to give up that fundamental pr= operty. Rather, I am expressing the belief that levels of threat/fear can e= xist which cause the chain(s) in which large amounts of perceived-vulnerabl= e coins remain to lose value to a devastating extent. This can take many fo= rms. Maybe none of us are around anymore, and the people then hold differen= t values. Maybe some people create a freezing fork before, or even after, a= CRQC becomes reality, and that chain becomes more economically relevant. M= aybe it's not called Bitcoin. Maybe nearly all(*) coins migrate to PQC addr= esses. Maybe CRQC fear fizzles out after some time. Maybe Bitcoin just does= n't survive CRQC fears. >=20 >=20 > This is not a statement about what should or shouldn't be done about perc= eived-vulnerable coins. It is an observation that may however influence des= ign around the introduction of other schemes: >=20 > - Giving users the option to migrate to schemes with a different securi= ty assumption is not enough to remove that security assumption from the sys= tem. Bitcoin as a whole, and all its users including those who migrate, are= and remain dependent on secp256k1 security as long as many(*) secp256k1-se= cured coins remain. > - Users adopting schemes with a different security assumption at scale(= *) is opting all users including those who do not migrate, into that securi= ty assumption. > - We can design things for a future where no substantial(*) amount of c= oins are perceived to be vulnerable. Not because we're planning to freeze t= he coins that are, but because future chains in which such coins remain wil= l 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 the premise that a solution w= ill be found, because futures in which there isn't are uninteresting. >=20 >=20 >=20 > > 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 w= ill not *want* others to migrate (of course, they will), it's that they wil= l not *want* violation of property rights. See [1] >=20 >=20 > Why not both? For Bitcoin to relevant, it needs to have value. One import= ant component of that is differentiation with competing monetary systems, w= hich includes properties like a fixed inflation schedule and inviolable pro= perty rights. But not having market fear wipe out your coins' value, even i= f you keep them, is a component too. >=20 > I agree Bitcoin cannot promise anything about its exchange rate with real= -world 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 sys= tem with properties we care about, but that doesn't mean we cannot make obs= ervations about the reality the system exists in. >=20 >=20 >=20 > > 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 be= cause if literally held in outputs for which the unlocking script is public= ally derivable, it's debatable whether it's theft, even). The thieves will = either be negligent themselves or not; in any case, over time, the coins wi= ll move to holders who are not negligent. >=20 >=20 > Ironically, I think that actual "theft" (scare quotes or not) in this con= text is much less concerning than uncertainty and fear about the possibilit= y of theft... and I realize this is getting closer to being a statement abo= ut human psychology than technical properties. Let's say a PQC scheme is ad= ded 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-pubke= y addresses have moved to a PQC address. Nobody knows who or what did it, b= ut it's widely assumed it was a CRQC. This might not affect Bitcoin's value= that much - after all, most of the damage is already done. However, someon= e publishing a statement "I have a CRQC", signed by the same set of pubkeys= that held those coins, would likely send the market tumbling down, and dec= imate Bitcoin's relevance for a long time. >=20 > This is also my response to Light's analogy with the systemic risk impose= d 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 m= ean it also won't be concerned about the potential of large amounts of coin= s becoming vulnerable. >=20 >=20 > > Anyone who wants quantum security but is also afraid of fully trusting = untested new algorithms like FancySig could easily use a hybrid locking scr= ipt which requires both BIP340 AND FancySig signatures. >=20 >=20 > This misses the point I was trying to make. If someone were truly hesitan= t 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 ever= yone(*) who wants to use FancySig to stick to "BIP340 AND FancySig", i.e., = this would be an argument against supporting FancySig-only outputs. And tha= t is indeed a solution to the "people don't trust FancySig" problem, but it= comes at a significant cost too. >=20 >=20 > However, I only included the possibility of people distrustful in the oth= er direction (fear of a new scheme) in my example to show the extreme incom= patibility it may lead to. The point that (IMO) all Bitcoin users remain de= pendent on secp256k1 security as long as a substantial(*) amount of coins p= rotected (solely) by it remain, is far more important.=C2=A0 >=20 > > Disabling them like you propose? >=20 > To be clear, I am not proposing that, and I'm not interested in discussin= g what Bitcoin should do. >=20 > (*) =3D All of these statements are about some sufficiently large number = of coins, which I don't know what it is. >=20 > --=C2=A0 > Pieter >=20 > On Friday, February 13th, 2026 at 11:20 AM, Pieter Wuille wrote: >=20 > > Hi all, > >=20 > > 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 consideratio= n, and is not intended as an argument against (or for) any particular propo= sal today. > >=20 > > The idea is giving users/wallets the ability to choose the cryptographi= c primitives used to protect their own coins, from a set of available primi= tives that may change over time. I think this ignores how important it is w= hat others do with their coins. If others' coins lose value, for example du= e to fears about them becoming vulnerable to theft with cryptographic break= throughs, so do your own due to fungibility, regardless of how well protect= ed they are. > >=20 > > As an extreme thought-experiment, imagine that tomorrow a new cryptogra= phic signature scheme FancySig is published, with all the features that Bit= coin relies on today: small signatures, fast to verify, presumed post-quant= um, BIP32-like derivation, taproot-like tweaking, multisignatures, threshol= ds, ... Further assume that within the next year or two, voices (A) start a= ppearing arguing that such a scheme should be adopted, because it's the sil= ver bullet the ecosystem has been waiting for. At the same time, another ca= mp (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: > >=20 > > - Camp (A), fearing an EC-break (CRQC or otherwise), wouldn't just wa= nt FancySig as an option - they would want (feasible or not) that near-ever= yone migrates to it, because the prospect of millions of BTC in EC-vulnerab= le coins threatens their own hodling. > > =20 > >=20 > > - Camp (B), fearing the possibility that FancySig gets broken soon, p= ossibly even classically, don't want to just not use FancySig; they would w= ant near-nobody to migrate to it, because the prospect of a potential break= of FancySig threatens their own hodling. > >=20 > > This is of course an extreme scenario, and in reality the divergence be= tween camps may be much less incompatible, but I still think it's a good de= monstration 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. > >=20 > > A small note aside: you can argue that it is possible for people to sto= re 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 abo= ve, 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. > >=20 > > It is also good to ask what amounts are relevant here, to which I do no= t know the answer. Possibly, the prospect of 100k BTC becoming vulnerable t= o 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 cl= ear that some threshold exists above which I would be uncomfortable with se= eing that many coins move into an untrustworthy scheme, even if they are no= t my own coins. > >=20 > > This brings us to the question then how at all Bitcoin users can migrat= e to new cryptography, because we cannot assume that secp256k1 will last fo= rever. And I think the answer is essentially that it requires the entire ec= osystem to change their assumptions. This does not mean that adding a new o= pt-in cryptographic primitive is infeasible or a bad idea; it just means th= at adding FancySig as an option is changing the collective security assumpt= ion from "secp256k1 is secure" to "secp256k1 AND FancySig are secure" once = FancySig gets adopted at scale, and the discussion about adding new primiti= ves should be treated with the gravity that entails. And it means that disa= bling 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= ". > >=20 > > Because of that, if CRQCs or other EC-breaks become reality, or just th= e fear about them becomes significant enough, I do believe that disabling E= C opcodes will be necessary in any economically-relevant surviving chain, d= ue to the millions of BTC that are unlikely to ever move. Note that I am no= t arguing that "Bitcoin" will, should, or even can do this, and I'm quite s= ure that the inherent confiscation required will make the result uninterest= ing 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 on= ly after a CRQC has been demonstrated to exist. Still, given a severe enoug= h threat I think it is inevitable, and I think that this means we shouldn't= worry too much about what happens in chains in which EC is not disabled wh= ile simultaneously EC is considered insecure: such chains will be worthless= anyway. > >=20 > > --=C2=A0 > > Pieter > >=20 >=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= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/fpr54OwSyhxOLkSM0ThB2HQN97XFCTL0c3oHbb9A-jmN0TiO6m38a-MqHYpHK9g4tokROwjJG= FfFLjYtGluNRBg70PA4YThX9cMAiyw1B1k%3D%40wuille.net. --=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/= gaAWxrXhxaj_y-siuqGvE2G-CKPtE9GgNKtYbw54H1HSLfpecRCpbrqrYDeF2lgE0C3S1qWLSCS= ntBQxizGLp0fdZq99ChKJZy2r6G_OXyg%3D%40proton.me. -----------------------65c8dd9872c65af46910dc7d4baa7a7e Content-Type: multipart/related;boundary=---------------------64870e20bae5bd2e8a7044cc6f256427 -----------------------64870e20bae5bd2e8a7044cc6f256427 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for elaborating, Pieter. I think i understand the point you're= getting at a bit better now. You are saying that I as a self-interested Bi= tcoin user care about the cryptographic assumptions made by other Bitcoin u= sers, insofar as other users' choices affect the market value of my own coi= ns.

You're very right that this concern is= highly relevant for holders worried about quantum procrastinators, who by = failing to make a choice at all will be making a de-facto choice to protect= their coins with a cryptosystem that may soon be broken. However, i disagr= ee on your point here:

> Users ado= pting schemes with a different security assumption at scale(*) is opting al= l users including those who do not migrate, into that security assumption.<= /span>

I disagree for the same reasons I out= lined earlier: we have many options to design wallet standards which minimi= ze users' exposure to novel attacks on young cryptosystems. Provided most w= allets do not intentionally stray from best-practices in PQ wallet security= , this risk - and any FUD borne from it - should be entirely manageable, es= pecially considering the number one candidate everyone seems to agree on is= hash-based signatures, which are even more conservative than BIP340.

But as you say, these fears are far less r= elevant than fears from the other camp (FUD around legacy coins protected o= nly by ECDLP). So let's focus on that problem.

=
> This is not a statement about what should or shouldn't be d= one about perceived-vulnerable coins.
>
> We can design things for a future where no substantial(*= ) amount of coins are perceived to be vulnerable. Not because we're plannin= g to freeze the coins that are, but because future chains in which such coi= ns 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 the premise that= a solution will be found, because futures in which there isn't are uninter= esting.

I'm a bit confused by this st= atement. You're saying we shouldn't worry about PQ-vulnerable coins because= any chain in which they are exploitable would be worthless anyway? But you= 're NOT advocating for a freeze which would prevent coins from being stolen= .

I think these aren't compatible vi= ews. If we do not freeze EC spending and replace it with PQ-safe rescue pro= tocols, then those coins will be vulnerable, and as per your comment, the c= hain will become worthless. Thus, the only "interesting" chains are the one= s which implement a freeze of some kind - at least under your assumptions. =

Personally I am not entirely con= vinced of this claim that "future chains in which [PQ-Vulnerable] coins rem= ain will lose value" and will therefore be "uninteresting" to work on. But = I'll leave that discussion for another day. 
FWIW i think a freeze (with rescue protocols) is = indeed a good idea and we should work on it, maybe not today but eventually= .

regards,
con= duition
On Tuesday, February 17th, 2026 at 8:10 PM, Pieter Wuille <bitco= in-dev@wuille.net> wrote:
Hi,
<= br>
Thank you all for the interesting = comments. I want to respond to some of them, but feel like I need to clarif= y 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 fu= ndamental property. Rather, I am expressing the belief that levels of threa= t/fear can exist which cause the chain(s) in which large amounts of perceiv= ed-vulnerable coins remain to lose value to a devastating extent. This can = take many forms. Maybe none of us are around anymore, and the people then h= old different values. Maybe some people create a freezing fork before, or e= ven 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 addresses. Maybe CRQC fear fizzles out after some time. Maybe Bitco= in just doesn't survive CRQC fears.

This is not a statement about what should or shouldn't be done = about perceived-vulnerable coins. It is an observation that may however inf= luence design 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 assum= ption from the system. Bitcoin as a whole, and all its users including thos= e who migrate, are and remain dependent on secp256k1 security as long as ma= ny(*) secp256k1-secured coins remain.
  • Users adopting 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 future where no substantial(*) amount of coins are perceived to be vu= lnerable. Not because we're planning to freeze the coins that are, but beca= use future chains in which such coins remain will lose value. I am not stat= ing 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 futur= es in which there isn't are uninteresting.

    • I funda= mentally disagree with this thesis you outlined here. The error in the seco= nd of the three quotes is subtle: it's not that rational users will not *wa= nt* 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 i= mportant component of that is differentiation with competing monetary syste= ms, which includes properties like a fixed inflation schedule and inviolabl= e property rights. But not having market fear wipe out your coins' value, e= ven if you keep them, is a component too.

    I agree = Bitcoin cannot promise anything about its exchange rate with real-world goo= ds and services, or other currencies, but that doesn't mean this isn't rele= vant to its users. And as developers we ought to design for a system with p= roperties we care about, but that doesn't mean we cannot make observations = about the reality the system exists in.


    =
    Supp= ose X% of the supply is held by negligent holders. Over time that X% will m= ove away from those negligent holders to "thieves" (scare quotes because if= literally held in outputs for which the unlocking script is publically der= ivable, it's debatable whether it's theft, even). The thieves will either b= e negligent themselves or not; in any case, over time, the coins will move = to holders who are not negligent.

    Ironi= cally, I think that actual "theft" (scare quotes or not) in this context is= much less concerning than uncertainty and fear about the possibility of th= eft... and I realize this is getting closer to being a statement about huma= n psychology than technical properties. Let's say a PQC scheme is added to = Bitcoin in the next few years, and it sees some mild adoption. Then we sudd= enly wake up one day, and the large majority of coins in known-pubkey addre= sses 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 that m= uch - after all, most of the damage is already done. However, someone publi= shing a statement "I have a CRQC", signed by the same set of pubkeys that h= eld those coins, would likely send the market tumbling down, and decimate B= itcoin's relevance for a long time.

    This is also m= y response to Light's analogy with the systemic risk imposed by large amoun= ts of coins held by exchanges. I think the ecosystem ought to be more conce= rned about that risk, but the fact that it isn't does not mean it also won'= t be concerned about the potential of large amounts of coins becoming vulne= rable.

    Anyone who wants quantum security but is also a= fraid of fully trusting untested new algorithms like FancySig could easily = use a hybrid locking script which requires both BIP340 AND FancySig signatu= res.

    This misses the point I was trying to ma= ke. If someone were truly hesitant about FancySig's security, then having t= hem moving their own coins into a "BIP340 AND FancySig" outputs isn't a sol= ution. They would would want everyone(*) who wants to use FancySig t= o stick to "BIP340 AND FancySig", i.e., this would be an argument against s= upporting FancySig-only outputs. And that is indeed a solution to the "peop= le don't trust FancySig" problem, but it comes at a significant cost too.

    However, I only included the possibility of people di= strustful in the other direction (fear of a new scheme) in my example to sh= ow the extreme incompatibility it may lead to. The point that (IMO) all Bit= coin users remain dependent on secp256k1 security as long as a substantial(= *) amount of coins protected (solely) by it remain, is far more important.&= nbsp;

    Disabling them like you propose?
    <= br>
    To= be clear, I am not proposing that, and I'm not interested in discussing wh= at 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 1= 1: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 "= 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-MqHYpHK9g4= tokROwjJGFfFLjYtGluNRBg70PA4YThX9cMAiyw1B1k%3D%40wuille.net.

    --
    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/gaAWxr= Xhxaj_y-siuqGvE2G-CKPtE9GgNKtYbw54H1HSLfpecRCpbrqrYDeF2lgE0C3S1qWLSCSntBQxi= zGLp0fdZq99ChKJZy2r6G_OXyg%3D%40proton.me.
    -----------------------64870e20bae5bd2e8a7044cc6f256427-- -----------------------65c8dd9872c65af46910dc7d4baa7a7e-- -----------------------270f7fd61afc66e6ea4529f56550e7e9 Content-Type: application/pgp-keys; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - conduition@proton.me - 0x474891AD.asc"; name="publickey - conduition@proton.me - 0x474891AD.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWkRub0tSWUpLd1lCQkFI YVJ3OEJBUWRBcnBZYWFjZDgwcXdocmNaQW9VbW9NSHNWS21iZWlPZUEKcFhXbk1ybFdPZkxOSzJO dmJtUjFhWFJwYjI1QWNISnZkRzl1TG0xbElEeGpiMjVrZFdsMGFXOXVRSEJ5CmIzUnZiaTV0WlQ3 Q2pBUVFGZ29BUGdXQ1pEbm9LUVFMQ1FjSUNaQjRLV3p0aFBhenhRTVZDQW9FRmdBQwpBUUlaQVFL YkF3SWVBUlloQkVkSWthMENNdHJMZGcxM2EzZ3BiTzJFOXJQRkFBQTZhQUVBM1RmNHdqSVoKYnox K0diS0h4K09WQytNUXlVdi84RStoWUpjTE5QZnA0NEFBLzNiak5OTXN4WHdJTGZEM0xManNVVWFo CitBV2JyblVjVUFqQ2R1d3hUT01LempnRVpEbm9LUklLS3dZQkJBR1hWUUVGQVFFSFFDSXYxZW5J MU5MbAo3Zm55RzlVWk1wQ3ZsdG5vc0JrTmhQUVZxT3BXL3RKSkF3RUlCOEo0QkJnV0NBQXFCWUpr T2VncENaQjQKS1d6dGhQYXp4UUtiREJZaEJFZElrYTBDTXRyTGRnMTNhM2dwYk8yRTlyUEZBQUFR TFFEL2NCR2kwUDdwCkZTTkl2N1B6OVpkeUNVQjhzTy90dWZkV3NjQkNZK2ZMYTV3QkFNK0hTL3Jp S014RGt0TkhLakRGc2EvUgpEVDFxUGNBYXZCaXc2dDZ4Ti9jRgo9Y3d5eAotLS0tLUVORCBQR1Ag UFVCTElDIEtFWSBCTE9DSy0tLS0tCg== -----------------------270f7fd61afc66e6ea4529f56550e7e9-- --------81d255cec3ea454b7ab6f150b1a533565811833a3076faaaba85573f2f136935 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmmWugcJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmeu49laBI73hzedTckonzeGzYKg4fxKJXW2drT2 6GGljxYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAAHcAD+OCqKh8IPXfFqj6Gp Pq10nF1CbjUFNden+JkSTT8ShjwA/08G2iG3riAh85s/SJeobE35L0ruv1Wt W8NLnfTn7dwB =fYmf -----END PGP SIGNATURE----- --------81d255cec3ea454b7ab6f150b1a533565811833a3076faaaba85573f2f136935--