From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 16 Feb 2026 20:23:02 -0800 Received: from mail-oi1-f189.google.com ([209.85.167.189]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vsCc1-0006XJ-08 for bitcoindev@gnusha.org; Mon, 16 Feb 2026 20:23:02 -0800 Received: by mail-oi1-f189.google.com with SMTP id 5614622812f47-463c632f9a3sf21064938b6e.1 for ; Mon, 16 Feb 2026 20:23:00 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771302174; cv=pass; d=google.com; s=arc-20240605; b=FgC7ys+9YqAvEwprjhC1SP6oT7ODaAfL2BBUZYs/mcMf4bLGr5rnTvuj9sT5AuW482 sib6iqM+1FrtpBjunnPPYgtAR1cy86FTZhnSOjllbu8jiX8u5WDw4fupwdMIYY+fRDGM 7+9LdTQXNAWV7J4TMRv7SegfCi2ZFCJ0UfvKlmV7czghmN42gEifjAbXTGvblpzB+P0T SFuG4MldtLlzzsO1Xn7FzCX1xU79+l3mPl8Ve9h6/8tp01dtMCjguXKVgoLbcrhcWYm1 M3law9+TksZ/pXOpQQZMT+dKCn68r2/70e2ficVB7vwl1zCK8KYUzZpXJANlilGLtnfi oR/w== 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=H2dXkduYXia/Efni/dGyTFdGsk7RxKmnl6Iprfyn7ko=; fh=OyXZoabE2cOYiapN4iYWf8LYCZZ+izuB2mtpOjL1TH4=; b=ZbMmXsZGP96YFe+0qfxO41NlseHyftIDbqWCMpD8sM+N+sAlKjiEpjeFwCdyGOHmhH hm9IgOo+nu+pfCxzSonAUD0wpSfWBQtaE9VnUUH76tC4Nh5VH8m1bcVqKx6VuXw0m5qo bW+UrjDcBj6XIBwefiohKd4HT+6HzZtT1oKuzFo0rzEZXqy6k95imUCvV/Rxax8yA0BD qzfHWUl9i45nMbYeuGwJY/uKpaJp70um9VvqcaVS4GfOp2qqfVTrKIPx9iIFTNcoVmMk B7B4H1RrXybmHvKEdFfB0YlGnvl3MG9dkNfO6thS7u6QorlN5u1gU0CfVT1vKFVSo+uM WXSw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=on3bi5hlnregji4hbbg6vzn66a.protonmail header.b=c4sITQs6; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.29 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=1771302174; x=1771906974; 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=H2dXkduYXia/Efni/dGyTFdGsk7RxKmnl6Iprfyn7ko=; b=QTi9TpCQXohLePqk4mbnwvlOZ8DoTg0Y5Yp8fUGXxiGTJkw5BtPiFmoPaKxdH4HgiL s2qgFsFbGc1mWA4Ra5LzrFZdMhpeiUPTw1l+l31tQ/pkMwiee9mIIGeO4zlS1hBLefmy P2HLfMZpMupBZB840mUVZlIydm4Ub3Hhc4lEYJQxG+35UNnCcNYcQqy63xn/wnRDMUU8 hruHfSzIqc18OZDtQ2wg9k0NcHFzweIeqGvAvo+Fo4IK7y1MEYMs00q/xLKCJ2a+ESoC kvHaPpMDmXcZKHgH1ZqRIPiXSwWtL0+JaeQPGYRg3wMGkRkUMbGwW3Zp1TdDcNs4u4J0 kWvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771302174; x=1771906974; 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=H2dXkduYXia/Efni/dGyTFdGsk7RxKmnl6Iprfyn7ko=; b=k+Xj6mSTYaPkRj/FUwVneLTLbwdY94w0BI5wtcNMfGilUBbJw8nfn0UUZyrRRa0Unl Jf9s8g97KU3cRiKsMku4oo/5O8NN+FIXSo6/jqh6Hg10oP+Vy5pUFQ5c5ER9URFSukzD 3QGpcdiAwIyr3R1Rtwp9qY+1DazUcfIkQ7uMVwl9JFuqj592izF5TJNcLeB2pSEeCAPX bnU+NQY1nkBStRidbe2qnqwEP92yMw0DSX46PGnB+/fnFk2JZ9psMiMuE1esshfWYWyt K2igCViJumwPjF3Oq0539m0r2uSecMq+WqdMs7bFRtwYuOanBVjtsJP32BB2bQROCJLz UgBA== X-Forwarded-Encrypted: i=2; AJvYcCV38ALozzPN9xc9rZcNpX4weRiII09W68mgL9C+VDunMaQz2sVgspjfeSHMLgZ796Ie//CvI5BmZzns@gnusha.org X-Gm-Message-State: AOJu0Yx+o20/i3nbZS75FysUJulwwzyu1FUIb4c+QXzMMiYWK8Dcy1F9 aE7niuzwREsPp6QstXFgG9oLTxNHaZLlUYfpMcQhFs09XAwzAoFn6tyo X-Received: by 2002:a05:6808:1b13:b0:455:d5d1:8ac0 with SMTP id 5614622812f47-4639f25d294mr6450652b6e.53.1771302174368; Mon, 16 Feb 2026 20:22:54 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+GZojwZ3wLAg4pwqs5Yvsu1RzRRjdgGQ1mRgAn83qgGcQ==" Received: by 2002:a05:6870:174d:b0:3d5:92b8:657b with SMTP id 586e51a60fabf-40eca3344d2ls3385499fac.0.-pod-prod-09-us; Mon, 16 Feb 2026 20:22:49 -0800 (PST) X-Received: by 2002:a05:6808:1693:b0:45f:42d6:3014 with SMTP id 5614622812f47-4639f09cce5mr7522243b6e.26.1771302169681; Mon, 16 Feb 2026 20:22:49 -0800 (PST) Received: by 2002:a05:6808:b2b:b0:44f:fe66:38a2 with SMTP id 5614622812f47-46395e57794msb6e; Mon, 16 Feb 2026 19:49:20 -0800 (PST) X-Received: by 2002:a05:7300:d50e:b0:2b6:fa0c:6c44 with SMTP id 5a478bee46e88-2babc3bc999mr4125288eec.12.1771300158956; Mon, 16 Feb 2026 19:49:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771300158; cv=none; d=google.com; s=arc-20240605; b=Ddc1W6xckBqRysxd3z27wqou+kF/YMZ0kMpAmcD/5vz+LQ3V4a6Ag2ChXW+Yt9Y3yL kAWAO/CPtSp1IVVBjIHvT0hsENeepY8YrLWgjU2uGX69XViybuVhI4AggVfUi0z6r2wm yuCdKUF+HYUetl8DkQXsXukxmUkG76ElTAhes3IC1slKlqtQhFqEwJY0UAllIsLJSg6w GUKqloD33J9DFVRk+L9sat8N/vvkK4cMMUG0ExV2S1ZH9han87K2OTBCYUzGdIx71dhB BX3kAelHIoJJ8Bpf690pdmXKBlRmeKzr81Qg7X+7LaJ0oqwEv2Tgnf8gsztLGxXMsvGN kk8A== 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=6FX95pzRla3XToful/YUTg3mqZD38anO+H0MEsntb04=; fh=dRl5MJeON1RwI+/xO4/cP/Y3U38+pgB9/4rd/p1o9tg=; b=DzfkWoA0INTF2J1TDpUer6Mygr5kRvfnxXWA6XYJn79S8MHv7rWcMgl8Ibawv1vEh1 TohlvoJbut3Nzqwx6S19zKdn3HL1w+JGwBKW7FxcqaxK3h+c33TLqy4sGZuShEmjCrwH jaed1+2L4D1+MudBU3G9V41eOg6LapkL3vYv4xOiRzwwUHu010DtTXZ08hAwrugk4/VQ 24Vh/0DjAwIQZOV9ta9PLhNs05pDfaMqQPEBDmH6zFwkbx23I7Qe0kctTnzYhed6+FEq ZJhs/5z07n+aLbgpD4E8l3F2Jg67UV/GDgQMQEmswwLUuv54DuBCQQWdzQzJY8Huqea0 at3Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@proton.me header.s=on3bi5hlnregji4hbbg6vzn66a.protonmail header.b=c4sITQs6; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.29 as permitted sender) smtp.mailfrom=conduition@proton.me; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=proton.me Received: from mail-24429.protonmail.ch (mail-24429.protonmail.ch. [109.224.244.29]) by gmr-mx.google.com with ESMTPS id 5a478bee46e88-2bacb5d199dsi306361eec.2.2026.02.16.19.49.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Feb 2026 19:49:18 -0800 (PST) Received-SPF: pass (google.com: domain of conduition@proton.me designates 109.224.244.29 as permitted sender) client-ip=109.224.244.29; Date: Tue, 17 Feb 2026 03:49:11 +0000 To: Pieter Wuille From: "'conduition' via Bitcoin Development Mailing List" Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin Message-ID: In-Reply-To: References: Feedback-ID: 72003692:user:proton X-Pm-Message-ID: d04dc3f2c1019290c6aa7973ce7af443cc92f8d1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------5ca9663096962d7e03d9b407647d079cf881244a45d737398f08eafa495c1e14"; 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=on3bi5hlnregji4hbbg6vzn66a.protonmail header.b=c4sITQs6; spf=pass (google.com: domain of conduition@proton.me designates 109.224.244.29 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) --------5ca9663096962d7e03d9b407647d079cf881244a45d737398f08eafa495c1e14 Content-Type: multipart/mixed;boundary=---------------------fae9258d2803fabdd9e9e7916a61854b -----------------------fae9258d2803fabdd9e9e7916a61854b Content-Type: multipart/alternative;boundary=---------------------8294999100fbbe2fc5545be64d2145ba -----------------------8294999100fbbe2fc5545be64d2145ba Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Hi Pieter, and thanks for bringing this up. I think your concern is valid. I'd agree with your thought experiment in th= e sense that there would definitely be competing movements for and against = two such well-matched algorithms. However i don't see this debate affecting= much in the real world, outside of twitter meme showdowns and reddit debat= es. Anyone who wants quantum security but is also afraid of fully trusting unte= sted new algorithms like FancySig could easily use a hybrid locking script = which requires both BIP340 AND FancySig signatures. Or more efficiently the= y could commit their BIP340/FancySig pubkeys in separate tapscript leaves a= nd use only BIP340 until quantum security is needed. This is even more secu= re than a hybrid locking script if we assume no address reuse. Users don't = have to pick between algorithms until spending time, and even then they cou= ld reveal only a hybrid leaf for extra safety if they are unsure. So no, i don't think we need to change our assumptions, even if an ideal PQ= signature candidate appears tomorrow. We just need to design smart and sec= ure standards for wallets to implement so that users get a (speculatively) = quantum secure fallback without exposing themselves to risk of novel attack= s on young cryptosystems. regards, conduition On Friday, February 13th, 2026 at 4:23 PM, Pieter Wuille wrote: > 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 w= anted to offer my own perspective. It's more a philosophical consideration,= and is not intended as an argument against (or for) any particular proposa= l today. >=20 > 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. >=20 > 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: >=20 > - Camp (A), fearing an EC-break (CRQC or otherwise), wouldn't just want= FancySig as an option - they would want (feasible or not) that near-everyo= ne migrates to it, because the prospect of millions of BTC in EC-vulnerable= coins threatens their own hodling. > =20 >=20 > - Camp (B), fearing the possibility that FancySig gets broken soon, pos= sibly even classically, don't want to just not use FancySig; they would wan= t near-nobody to migrate to it, because the prospect of a potential break o= f FancySig threatens their own hodling. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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". >=20 > 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. >=20 > --=C2=A0 > Pieter >=20 >=20 >=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/THqOJuI_s5C8B9jkklN73BB_Hzb9SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh8NxxYbXwv4v6i= kpStguW-QEvef4WgBZ7AQDz00P0st91FMA%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/= ZA5N5pZmrZFiYFDqhSYz9gR6q2tqf68MHxGuEUI0iyQAu3GKDcNpw9XTamXahrpUFK4zwT6BV3s= 3SmoKCMdNBL_KqyozByLlX6SwwAKYuLE%3D%40proton.me. -----------------------8294999100fbbe2fc5545be64d2145ba Content-Type: multipart/related;boundary=---------------------c1617a30558e8f05c96c3dcb7fc38375 -----------------------c1617a30558e8f05c96c3dcb7fc38375 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Pieter, and thanks for bringing this up.

I think your concern is= valid. I'd agree with your thought experiment in the sense that there woul= d definitely be competing movements for and against two such well-matched a= lgorithms. However i don't see this debate affecting much in the real world= , outside of twitter meme showdowns and reddit debates.

Anyone= who wants quantum security but is also afraid of fully trusting untested n= ew algorithms like FancySig could easily use a hybrid locking script which = requires both BIP340 AND FancySig signatures. Or more efficiently they coul= d commit their BIP340/FancySig pubkeys in separate tapscript leaves and use= only BIP340 until quantum security is needed. This is even more secure tha= n a hybrid locking script if we assume no address reuse. Users don't have t= o pick between algorithms until spending time, and even then they could rev= eal only a hybrid leaf for extra safety if they are unsure.

So= no, i don't think we need to change our assumptions, even if an ideal PQ s= ignature candidate appears tomorrow. We just need to design smart and secur= e standards for wallets to implement so that users get a (speculatively) qu= antum secure fallback without exposing themselves to risk of novel attacks = on young cryptosystems.

regards,
conduition
On Friday, February 13th, 2026 at 4:23 PM, Pieter Wuille <bitcoi= n-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/THqOJuI_s5C8B9jkklN73BB_Hzb9SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh8Nxx= YbXwv4v6ikpStguW-QEvef4WgBZ7AQDz00P0st91FMA%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/ZA5N5p= ZmrZFiYFDqhSYz9gR6q2tqf68MHxGuEUI0iyQAu3GKDcNpw9XTamXahrpUFK4zwT6BV3s3SmoKC= MdNBL_KqyozByLlX6SwwAKYuLE%3D%40proton.me.
-----------------------c1617a30558e8f05c96c3dcb7fc38375-- -----------------------8294999100fbbe2fc5545be64d2145ba-- -----------------------fae9258d2803fabdd9e9e7916a61854b 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== -----------------------fae9258d2803fabdd9e9e7916a61854b-- --------5ca9663096962d7e03d9b407647d079cf881244a45d737398f08eafa495c1e14 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wrsEARYKAG0FgmmT5SgJEHgpbO2E9rPFRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmdPol+g7VR0IKPk6fe00q36Gjwd1l+xiTyum5ed u11cBBYhBEdIka0CMtrLdg13a3gpbO2E9rPFAAA55QD+L9/cu7p2sWmQhVv7 AMi8UwfcGby4lo0ui17vkk6nRcMA/02AMIFM1tvzhL9T9GwfocuP+xmqCeuK jALtxC/yOZQI =kZYS -----END PGP SIGNATURE----- --------5ca9663096962d7e03d9b407647d079cf881244a45d737398f08eafa495c1e14--