From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 13 Feb 2026 14:13:21 -0800 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vr1Pc-0004f5-GQ for bitcoindev@gnusha.org; Fri, 13 Feb 2026 14:13:21 -0800 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-409037c3f0bsf6313862fac.1 for ; Fri, 13 Feb 2026 14:13:20 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771020795; cv=pass; d=google.com; s=arc-20240605; b=a+2OiaTkMHs+WnAqNhszUtaQYj9UkBk2FfTEzqvX5S8xc4Sb5wnW0VRU3q+PgnsrEe +PwTuWX8+X+4wKBzVZnU1jS1YhNlavcNRU/cByGncvrLgLUEOTmb7c1axcpXsr4L61ot PPRJ8VFaslQsVA60Y19LJuZQY0WHXLkqWgJRsQHsljbtneW3ngsujnVnnECmZGk5L55R 5PAQGSB8DsFZKmiZvZWYZLp19vAxjpk3r7mhNXUabEeTdMmK7WRZuF4nLQgIUx+xLsWU QSxllNscU9aHG99FDAbozbMNurRzlS6w6kQr37tXc090ZTMRupUSVj9Z74fQsgkNzG0A cZwA== 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:content-transfer-encoding:subject :references:in-reply-to:message-id:to:from:date:mime-version :feedback-id:sender:dkim-signature; bh=CSB0dXWwZKkLQPbvGkxy+oMiblc32fzWVV1fIU3WYpk=; fh=y2HSiOX+DUbS+VYYhs7YJyGi+aXJmZkFPcQbwLyuLdI=; b=O6zyveD/Uo1OwRcc2z9ovbH6kPj2dIkWdSYt/XC0iKtkzxI54Mpqe9B0DU8+nj1omD wP6WHxKQ5qa3dROgO3uIZpdgKooa5M0omtcleZ9j0ePPNnWHazq6of1tYQbAYPJsh8aW jcsqHWB9WFoc1GQ/gchHr8cw/5GYDzKR78/T0bQN13YZPIcxRREVIwpZSvWh6D1Tw2pv fvxHAvhcu0qeYPnfo8h42GL7H/hMswWjahc9RNu/Sfe18+4icv6EU63lp2x6VuaSBCUC TGx3sVrbT+kApY+dlHky67UMhk+gSdzSwkLPCNva/UIfuf8Fffk1R1hUIpW7kCKf4yP1 1VLw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@lightco.in header.s=fm2 header.b=GPIDUcAt; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=IgcnOhEy; spf=pass (google.com: domain of bitcoin-dev@lightco.in designates 103.168.172.155 as permitted sender) smtp.mailfrom=bitcoin-dev@lightco.in DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1771020795; x=1771625595; 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:content-transfer-encoding:subject:references :in-reply-to:message-id:to:from:date:mime-version:feedback-id:sender :from:to:cc:subject:date:message-id:reply-to; bh=CSB0dXWwZKkLQPbvGkxy+oMiblc32fzWVV1fIU3WYpk=; b=P8vD4CcFSDrBBA+VugmWDmAYskKKbcOOkXqKyOWA9To5zP1GPlWGTefa7rTWUpzdIv FOekdD64Jrx5VpoXMx847Zphxrp/KXfl69RjG6tX4pdAbdaS7JMUWedCvmp4MxUklfEi RXS1WEMEyDeedxAG//n358iPjHDFUKdxFwmcjor8gZDyQgI+GyBhHtduAwAqLXKlOSRJ XYYmEIqM8RtL+aaQrfeapD7PupSuHbAxIqakRoMqNc8Gz9nImDqPAVke6WOlcJkWikf0 Dhv/zTzSvlj9VTIToGWfZCvoP5Op95CkZg8NOGoqNR+8cQiAazn3mU9ORNcdHftJe3D/ 5f0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771020795; x=1771625595; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:subject:references :in-reply-to:message-id:to:from:date:mime-version:feedback-id :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=CSB0dXWwZKkLQPbvGkxy+oMiblc32fzWVV1fIU3WYpk=; b=dYd7adPZmIhyFMco5gnQiHZuA872tORjMW9klHZu4SHdMaNXYxLmA6Z0tCmbxi/iPN BY6IP3cXz+A8xwg0WxBj4bE+iGi9MaPXkD68Vasvh8fexXrAOUEJUM8tIa1mUxOjQUSR qus4DelrW4R85BXFjWsI8jIHwYg2Rsk9wLj7aZw2lU+tUvBeGiI+kCTLNP6W0IJrfb1R 3Dg77BuzQtGi11p85V8STkbd0iyB3rHuSbn3GhInjgJbUYY3xL7+sBIAKpPDRSbyBv1S ZwpxUmNAPnIj1UmUFaAPPHbxXC7ZlEshmucSHXWMD42IIMIlfiaQbD0QCV8z3gwRq4NZ dhUw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUdRj9NAWju/DJprOU4LuizjuQfAGTSlVlx8+0aYqouMkCCznoPgpWTVfGR3H3fsv96hlDZb+nbu1ed@gnusha.org X-Gm-Message-State: AOJu0YxB+ehzMjl2BF/+XXMnzrTr9qvNXsdmRbozoVVGCc3UipBK62Qa lk47Gn488x9BjKiyqJ3P6WTTOtQYGzM1eOyzmQ+GRBSCc3Zt1h6G7OxK X-Received: by 2002:a05:6870:75c8:b0:404:590:59dc with SMTP id 586e51a60fabf-40ef3ece44dmr1662299fac.33.1771020794651; Fri, 13 Feb 2026 14:13:14 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HpZegx2lDaG73/gM8qVMdaKwzWaOrOdK46a+Vnxutk9A==" Received: by 2002:a05:6870:2114:b0:3d4:d703:74d7 with SMTP id 586e51a60fabf-40eca31b5f4ls984701fac.0.-pod-prod-02-us; Fri, 13 Feb 2026 14:13:10 -0800 (PST) X-Received: by 2002:a05:6808:f8f:b0:45e:c2a4:7d8f with SMTP id 5614622812f47-4639f27c361mr1983638b6e.55.1771020790519; Fri, 13 Feb 2026 14:13:10 -0800 (PST) Received: by 2002:a05:6808:2164:b0:463:a65d:b610 with SMTP id 5614622812f47-463a65db7b9msb6e; Fri, 13 Feb 2026 13:50:56 -0800 (PST) X-Received: by 2002:a17:90b:3c4c:b0:340:5c27:a096 with SMTP id 98e67ed59e1d1-356aab944fcmr3489054a91.6.1771019455812; Fri, 13 Feb 2026 13:50:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771019455; cv=none; d=google.com; s=arc-20240605; b=iE1qHwk0nR4JPKcVBUFmSn1SpRgvUuC1EUu3kmrL9o19gtnM8qfbLzJnX2UWIEpHgZ tNzGCnBaPFjO7zCqiaIsGRpNXqw7ly905frImWuswyV5gDkmVP1r69d9TvrAY4QiXdoV DLjxHG4VtVWan+s++lpYJXXzte1OZYLnbVjpU6XzD0zwzoP8kvEvyoSR83CpOV7cDs8F rspqFd1fWcmw+Bdz5jAtSXjptO78u1VzrdPQVvvdYDcEwjZlfswNJA6zzrH7vFHQdKA9 Qf/BJMiyQuCKz4Z+QPfqZG0ByyM8obJbiC+VR63A9K79+FMXBcg+dgS0TFuNO4DQFqvu s9Kg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:subject:references:in-reply-to:message-id :to:from:date:mime-version:feedback-id:dkim-signature:dkim-signature; bh=xXEkOrBEk/T2bAoO6ARWuEZcefy0ifnNt8DZH3+q9AU=; fh=VcGcg+Zjs9gw1uDcHbxsAILhBAcecnbJzZRdxgKVDIc=; b=XzoDM3a8HCO4LglzYOtsEGTdbBwnJExHTlj1TKbv5ydzyEIFIO/PXdvS7Fe4UvXxSC yR2x8bErFYpqSOQ5Kx4LB3VXPTR4BAePouENiJBXAVqLBKS0L3e6KC4+ji0oGiHjPIBe waVBNUn2AC39jtpcKsu1V76dPFfibvzRb0UfuEJd/If4O2snsfG+pGq3g45DOyG8bXZ0 UzecLowqtWUFj+iXdkzw6TKIGZ13ZSONfCBSMy6Itjk8g7VX/lk9KIKVMEpYIQmSMDzi MsBDQWUnFvRBxwSVqW4qQxJt/09pqFZXuqxlyun2ud2hPx41QWrcP+1VgLQ2QOo7b81Q icNg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@lightco.in header.s=fm2 header.b=GPIDUcAt; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=IgcnOhEy; spf=pass (google.com: domain of bitcoin-dev@lightco.in designates 103.168.172.155 as permitted sender) smtp.mailfrom=bitcoin-dev@lightco.in Received: from fhigh-a4-smtp.messagingengine.com (fhigh-a4-smtp.messagingengine.com. [103.168.172.155]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-c6e531c4f74si5932a12.6.2026.02.13.13.50.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Feb 2026 13:50:55 -0800 (PST) Received-SPF: pass (google.com: domain of bitcoin-dev@lightco.in designates 103.168.172.155 as permitted sender) client-ip=103.168.172.155; Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id F2E0C14000B2 for ; Fri, 13 Feb 2026 16:50:54 -0500 (EST) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-04.internal (MEProxy); Fri, 13 Feb 2026 16:50:54 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvtdelfeekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmnecujf gurhepofggfffhvffkjghfufgtgfesthhqredtredtjeenucfhrhhomhepnfhighhhthcu oegsihhttghoihhnqdguvghvsehlihhghhhttghordhinheqnecuggftrfgrthhtvghrnh epkeekleeitdduvedtveelvdefkeelvdegjefffffhudfgudfgieduhfdvjeehudeknecu ffhomhgrihhnpegtohhinhhglhgrshhsrdgtohhmpdgsihhttghoihhnthgrlhhkrdhorh hgpdifihhkihhpvgguihgrrdhorhhgpdhgihhthhhusgdrtghomhdphihouhhtuhdrsggv pdhgohhoghhlvgdrtghomhdpqhhurghnthgrmhgrghgriihinhgvrdhorhhgpdifuhhilh hlvgdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhr ohhmpegsihhttghoihhnqdguvghvsehlihhghhhttghordhinhdpnhgspghrtghpthhtoh epuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepsghithgtohhinhguvghvsehg ohhoghhlvghgrhhouhhpshdrtghomh X-ME-Proxy: Feedback-ID: ic4c14615:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id CCA3E780075; Fri, 13 Feb 2026 16:50:54 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 X-ThreadId: AMpRsVj2rCRZ Date: Fri, 13 Feb 2026 16:50:33 -0500 From: Light To: bitcoindev@googlegroups.com Message-Id: <088b5efd-7ba5-48f1-97f6-eb5881f5fd14@app.fastmail.com> In-Reply-To: References: Subject: Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: bitcoin-dev@lightco.in X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@lightco.in header.s=fm2 header.b=GPIDUcAt; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=IgcnOhEy; spf=pass (google.com: domain of bitcoin-dev@lightco.in designates 103.168.172.155 as permitted sender) smtp.mailfrom=bitcoin-dev@lightco.in 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.8 (/) Hi Pieter, > A small note aside: you can argue that it is possible for people to=20 > store coins insecurely, like in an OP_TRUE script output, or with=20 > private keys that are made public. I don't think this possibility=20 > affects the point above, because it is not about what possibilities=20 > exist, but which approaches people are likely to / asked to adopt.=20 > Nobody is incentivized or encouraged to store coins in an OP_TRUE. While it is true that "nobody is incentivized or encouraged to store coins = in an OP_TRUE", I believe your argument is incomplete because it is missing= a more realistic mass-theft vector, which is that as of today approximatel= y 2.5 million BTC is held by less than two dozen centralized custodians.[1]= These coins are at a real risk of theft, due to both private threat actors= e.g. thefts from MtGox, Bitfinex, and scores of others, as well as public = threat actors e.g. EO 6102.[2][3] Despite this very real and large-scale theft risk, nobody is proposing that= we freeze coins held on exchanges. And yet some people find this (freezing= coins) to be a reasonable response to the risk of cryptographic breaks (ap= proximately 6.5 millions coins at risk).[4][5] Curious! But I digress. > This brings us to the question then how at all Bitcoin users can=20 > migrate to new cryptography, because we cannot assume that secp256k1=20 > will last forever. And I think the answer is essentially that it=20 > requires the entire ecosystem to change their assumptions. This does=20 > not mean that adding a new opt-in cryptographic primitive is infeasible= =20 > or a bad idea; it just means that adding FancySig as an option is=20 > changing the collective security assumption from "secp256k1 is secure"=20 > to "secp256k1 AND FancySig are secure" once FancySig gets adopted at=20 > scale, and the discussion about adding new primitives should be treated= =20 > with the gravity that entails. And it means that disabling secp256k1 EC= =20 > operations (or near-everyone migrating to FancySig, but I think that is= =20 > unlikely) is the only way to change the collective security assumption=20 > from "secp256k1 AND FancySig are secure" to "FancySig is secure". > > Because of that, if CRQCs or other EC-breaks become reality, or just=20 > the fear about them becomes significant enough, I do believe that=20 > disabling EC opcodes will be necessary in any economically-relevant=20 > surviving chain, due to the millions of BTC that are unlikely to ever=20 > move. Note that I am *not* arguing that "Bitcoin" *will*, *should*, or=20 > even *can* do this, and I'm quite sure that the inherent confiscation=20 > required will make the result uninteresting to me personally. It may be= =20 > that such disabling only happens in a fork that doesn't end up being=20 > called Bitcoin, or it may be that this happens only after a CRQC has=20 > been demonstrated to exist. Still, given a severe enough threat I think= =20 > it is inevitable, and I think that this means we shouldn't worry too=20 > much about what happens in chains in which EC is not disabled while=20 > simultaneously EC is considered insecure: such chains will be worthless= =20 > anyway. I don't believe the predominant "collective security assumption" is that "s= ecp256k1 is secure". Everyone using bitcoin, going all the way back to the = genesis block, has known (or should know) that secp256k1 is vulnerable to a= CRQC, and therefore secp256k1 is not unconditionally secure. So I would re= phrase the assumption to be that "secp256k1 is currently secure, and if it = is ever at risk of being broken, there is a large incentive for a viable al= ternative to be discovered, implemented, and adopted by anyone who is conce= rned about this risk". Note that this assumption does not, and cannot, prec= lude the possibility that other users store their coins in insecure ways, e= ven en masse (as shown empirically by the above example of millions of coin= s held by centralized custodians). An alternative where "secp256k1 OR FancySig is secure" seems strictly prefe= rable to me (assuming we have some reasonable degree of confidence in the s= ecurity of FancySig at the time of activation) than relying only on "secp25= 6k1 is secure". As an aside, I note that because it has been known since before bitcoin eve= n launched that secp256k1 is vulnerable to a CRQC, we cannot rule out the p= ossibility that the people who leave their coins in CRQC-vulnerable address= es -- even after QR addresses are made available -- aren't doing so intenti= onally, as a kind of bounty for developing a CRQC. Freezing these coins wou= ld violate their intentions. This is just one example of the ethical proble= ms associated with such proposals. A perhaps even more fundamental "collective assumption" of bitcoin users is= that "a redeem script that was valid at the time that a UTXO was encumbere= d will always remain valid". This is fundamental to bitcoin's nature as p2p= electronic cash. If users woke up one day no longer able to assume that th= eir redeem scripts would remain valid, then they would not be able to rely = on bitcoin to store value over time and the system would quickly collapse. = Thus, any proposal to disable features in a way that freezes coins is a pro= posal to destroy bitcoin. Bitcoin can survive a temporary price dump, if that's what ends up happenin= g with vulnerable coins. Bitcoin cannot survive a violation of the fundamen= tal assumption that redeem scripts for existing UTXOs will always remain va= lid, and certainly not a violation at the scale that you describe. Regards, Light [1] https://www.coinglass.com/Balance [2] https://bitcointalk.org/index.php?topic=3D5090869.0 [3] https://en.wikipedia.org/wiki/Executive_Order_6102 [4] https://github.com/bitcoin/bips/pull/1895 [5] https://youtu.be/a_B8BnwagEU&t=3D150=20 On Fri, Feb 13, 2026, at 11:20 AM, Pieter Wuille wrote: > Hi all, > > A thread was=20 > recently started on this list about cryptographic agility in Bitcoin. I= =20 > believe there are important limitations around that idea, and wanted to= =20 > offer my own perspective. It's more a philosophical consideration, and=20 > is not intended as an argument against (or for) any particular proposal= =20 > today. > > The idea is giving users/wallets the ability to choose the=20 > cryptographic primitives used to protect their own coins, from a set of= =20 > available primitives that may change over time. I think this ignores=20 > how important it is what *others do with their coins*. If others' coins= =20 > lose value, for example due to fears about them becoming vulnerable to=20 > theft with cryptographic breakthroughs, so do your own due to=20 > fungibility, regardless of how well protected they are. > > As an extreme thought-experiment, imagine that tomorrow a new=20 > cryptographic signature scheme FancySig is published, with all the=20 > features that Bitcoin relies on today: small signatures, fast to=20 > verify, presumed post-quantum, BIP32-like derivation, taproot-like=20 > tweaking, multisignatures, thresholds, ... Further assume that within=20 > the next year or two, voices (A) start appearing arguing that such a=20 > scheme should be adopted, because it's the silver bullet the ecosystem=20 > has been waiting for. At the same time, another camp (B) may appear=20 > cautioning against this, because the scheme is new, hasn't stood the=20 > test of time, and isn't well-analyzed. These two camps may find=20 > themselves in a fundamental disagreement: > > =E2=80=A2 Camp (A), fearing an EC-break (CRQC or otherwise), wouldn't ju= st=20 > want FancySig as an option - they would want (feasible or not) that=20 > *near-everyone migrates to it*, because the prospect of millions of BTC= =20 > in EC-vulnerable coins threatens their own hodling. > =E2=80=A2 Camp (B), fearing the possibility that FancySig gets broken so= on,=20 > possibly even classically=20 > ,=20 > don't want to just not use FancySig; they would want *near-nobody to=20 > migrate to it*, because the prospect of a potential break of FancySig=20 > threatens their own hodling. > This is of course an extreme scenario, and in reality the divergence=20 > between camps may be much less incompatible, but I still think it's a=20 > good demonstration of the fact that *despite being a currency for=20 > enemies, Bitcoin essentially requires users to share trust assumptions=20 > in the cryptography, and its technology in general*. > > A small note aside: you can argue that it is possible for people to=20 > store coins insecurely, like in an OP_TRUE script output, or with=20 > private keys that are made public. I don't think this possibility=20 > affects the point above, because it is not about what possibilities=20 > exist, but which approaches people are likely to / asked to adopt.=20 > Nobody is incentivized or encouraged to store coins in an OP_TRUE. > > It is also good to ask what amounts are relevant here, to which I do=20 > not know the answer. Possibly, the prospect of 100k BTC becoming=20 > vulnerable to theft won't threaten the value of the other coins, while=20 > the prospect of 10M BTC becoming vulnerable may. Depending on where=20 > your belief about this lies, you may end up with very different=20 > conclusions. Still, to me it is clear that *some* threshold exists=20 > above which I would be uncomfortable with seeing that many coins move=20 > 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=20 > migrate to new cryptography, because we cannot assume that secp256k1=20 > will last forever. And I think the answer is essentially that it=20 > requires the entire ecosystem to change their assumptions. This does=20 > not mean that adding a new opt-in cryptographic primitive is infeasible= =20 > or a bad idea; it just means that adding FancySig as an option is=20 > changing the collective security assumption from "secp256k1 is secure"=20 > to "secp256k1 AND FancySig are secure" once FancySig gets adopted at=20 > scale, and the discussion about adding new primitives should be treated= =20 > with the gravity that entails. And it means that disabling secp256k1 EC= =20 > operations (or near-everyone migrating to FancySig, but I think that is= =20 > unlikely) is the only way to change the collective security assumption=20 > from "secp256k1 AND FancySig are secure" to "FancySig is secure". > > Because of that, if CRQCs or other EC-breaks become reality, or just=20 > the fear about them becomes significant enough, I do believe that=20 > disabling EC opcodes will be necessary in any economically-relevant=20 > surviving chain, due to the millions of BTC that are unlikely to ever=20 > move. Note that I am *not* arguing that "Bitcoin" *will*, *should*, or=20 > even *can* do this, and I'm quite sure that the inherent confiscation=20 > required will make the result uninteresting to me personally. It may be= =20 > that such disabling only happens in a fork that doesn't end up being=20 > called Bitcoin, or it may be that this happens only after a CRQC has=20 > been demonstrated to exist. Still, given a severe enough threat I think= =20 > it is inevitable, and I think that this means we shouldn't worry too=20 > much about what happens in chains in which EC is not disabled while=20 > simultaneously EC is considered insecure: such chains will be worthless= =20 > anyway. > > --=20 > Pieter > > > > --=20 > You received this message because you are subscribed to the Google=20 > Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send=20 > an email to bitcoindev+unsubscribe@googlegroups.com . > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/THqOJuI_s5C8B9jkklN73BB_Hzb9= SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh8NxxYbXwv4v6ikpStguW-QEvef4WgBZ7AQDz00P0st9= 1FMA%3D%40wuille.net=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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 088b5efd-7ba5-48f1-97f6-eb5881f5fd14%40app.fastmail.com.