From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 16 Feb 2026 14:11:47 -0800 Received: from mail-oa1-f59.google.com ([209.85.160.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vs6oj-0000TP-K7 for bitcoindev@gnusha.org; Mon, 16 Feb 2026 14:11:47 -0800 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-409682c1693sf30973345fac.1 for ; Mon, 16 Feb 2026 14:11:45 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1771279899; cv=pass; d=google.com; s=arc-20240605; b=Dg12/P3fN8LTO6WfktiyrSD5VnCLfKT0mMe9ciN9jcHI/U9EYjJ8wi6CqW4y05lusU bdwmlpAW7lezXqHn0n9SdErKf20IPf/0bOXggxm3dPYfzoRA/QK7w2xVisLYrdcNw9bM f0q1KztRl6Rs117X6t/s8sAXDy7ykq/HGCZXKmDI7l81LBqHr1AUn5cixQIHjpnitsO5 HvFuTQHd/8R5CJAnsZjodszyX+jCy9iJn49YV7BjEwt97W2eZp1jyPEBB6YYL5StS5q8 558i31/2tALxAqQ/pzbymXXFEJH89n2O1cia1HsfVPkKjC4ljfjWrfAeAJes4qjsdigr YABQ== ARC-Message-Signature: i=3; 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:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=6Hr8cRMRA3fo7NrqhI3KrXzUBaWshACgrYxDZ4RMHsA=; fh=IeIqmdRdR+qbSO1hpoRa4p1cjrqWZv9TVMryeZ+Z0uQ=; b=Xls/n1fjh2T9N9tMxJsRTTAjpQFlcO9k0OZNir2Nhny6oN6P/JIMUBKiVvZFY6wTbj 1sTkoQN62oqBOuio4OIAf0S9iYktggZWg9gQwQp8C5zCKnl39f3bKSLMxItywEg+B77L 10YN+thHmVwN6XLOasLbpnWaAyPYSa6FYAqnuwaRsvem34bjCby3tZ1EA3Kxs4RORKxP TBtTQsTtZqnMxTaG4MXhjlVuqS6rHB1jJXzQI9DKBs5RkCu3S5TAbBR0kzf+AEO4ZlIv res6MOBn79DdPn1DBVidGWtVMxapgN8g+prlqiuo+OPO/aTRJmGptwHWIImQUbUSVIzs O8CQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=kNuOglRi; arc=pass (i=1); spf=pass (google.com: domain of ask4ismailsadiq@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) smtp.mailfrom=ask4ismailsadiq@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1771279899; x=1771884699; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=6Hr8cRMRA3fo7NrqhI3KrXzUBaWshACgrYxDZ4RMHsA=; b=hP/nrY9NPDdDpia2thV6CYnE7ctVqQ83C/KsAcsuWeZzbhtAujguLgs0fEURqDgvlE dhmkd6Cbw5tQgOZlDuBe38XjdvuDxYF2P9FR1Z/sPaPOPAfAfV5uQzk27jHx31N7SN/D rr/E5jDWU4vlUuSzsSPUGVCP+lcqO2/fSvhPP82S80CzS8ZpAUg1SD42SL6ZMO0Tx6X9 9QIL2EixAkvCAo5bK0n6O5GPhEB6kCJGIHH6eaEMJHTEniOe4J68mAld+jL00VS4btFi RTYN6x2uQL+uHEHVBQDWeKfBgx7oe4NaXuAdXXctQSiG8sPLLHqJoU/2kh7EGeQX5BRq ZOBA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771279899; x=1771884699; 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:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6Hr8cRMRA3fo7NrqhI3KrXzUBaWshACgrYxDZ4RMHsA=; b=SDNmBF1zNDB56QXPSBDXVk1ZP8g4g3sfXIIkLbQANdyio52FoR/IyRTVDGyGEHx/BI tlQ5JM97V4kRbSYs22ghDThAxhPEVWPPz+eYWlGQq4l0mf9RReOZdqdM1hKsViEBGfsU Ux3p7mJ7PQqFiWyYYQ2n7IPvYgk3ZBHQzz6QPKsATHIc7+KNIDsQXrpK0OdA8sGiDdaA V6yp9U5XLR/tOm62dTmczs2MZ57V+NQnmhO3l4PpXhGVef5wAzJ2GaYngcXavtAvrpG2 2CgQcFEyLN22X9PEjQCx+Nf092izTEm9raYlEg/V8JL5ZStteIqVCNrB2JIO95qoITvN 79Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771279899; x=1771884699; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=6Hr8cRMRA3fo7NrqhI3KrXzUBaWshACgrYxDZ4RMHsA=; b=BwQY4gCg6W1L+vvZunrndkusyy2yRvcMDxZvor29FvoLGJdqv00BwGv8pssG0LMGHo Z0grqi3T9ec0uECP4gnOiHQrzzDlk7HtTpTao2u1uS9SzMkSFF91eNP94lZ020sJiInK 8IcwqNFF4A/i6C06/YgpPeUICkwXIyRA4395o5hCXpMtCQK+HGHvyStAZVKCKfV5ttQx 0nFOUdoeAGHJ+b4Duxi00QjOmPlYbRNVGR2jlDrXWq/caQ7XzwsvvkS2fiGgzJBGMeT5 l4t8U/+ETaxsbPezIg5bgcXcGi+s/3zx5hzzavOs2NQg+yu6iSVaQuRT6/prCvVa0UVf QPUg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCVRLER4sVAw+XvRYKlcINd/NU8e0OXsNrM/1Bnjcwl3XbX5mTYeXOMgPCrdspvDi+J5t6ksbabNiIfU@gnusha.org X-Gm-Message-State: AOJu0YxUREaXtSWjZYdtnkm3kyYLWsi1+iPYrW75ER0gkT/w51Okw6Tq an1yA8k1veiDV054zlzFmcfGW9kQuk+e8XxmDxiaMO1chYWNtSfqvZJw X-Received: by 2002:a05:6870:440d:b0:40e:e3f6:bc9a with SMTP id 586e51a60fabf-40f08779a21mr5769442fac.9.1771279899351; Mon, 16 Feb 2026 14:11:39 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+HnE1ITFCSKToPU4zbc0vCNgOkYXi/kJ39jMYpkW1RVHA==" Received: by 2002:a05:6871:7a12:b0:3fa:9f2:b79b with SMTP id 586e51a60fabf-40eca330800ls1694691fac.0.-pod-prod-00-us; Mon, 16 Feb 2026 14:11:34 -0800 (PST) X-Received: by 2002:a05:6808:2445:b0:45e:fcf2:b693 with SMTP id 5614622812f47-463b0607ee6mr4914679b6e.29.1771279894458; Mon, 16 Feb 2026 14:11:34 -0800 (PST) Received: by 2002:a05:600c:5908:b0:483:6a76:922 with SMTP id 5b1f17b1804b1-483702f5e0ems5e9; Mon, 16 Feb 2026 01:59:43 -0800 (PST) X-Received: by 2002:a05:600c:4e92:b0:480:1c53:208b with SMTP id 5b1f17b1804b1-48373a7bbf2mr164058195e9.36.1771235981943; Mon, 16 Feb 2026 01:59:41 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771235981; cv=pass; d=google.com; s=arc-20240605; b=hIDgJCB14CnVF/iDfMnKGqG0B17K9V19j+k5cpqtlFwq99qx7QAAYpP/uzNaBTvIiM NbIKnIxNVhiPw6T9VoVIqddw2xJTOwDlOj8s/pAUbklg2/fat+WAMJ9Ah2WHPk5it2uj Evmr2go1a6bsg+CpWEpnp6XiYDxPDmAyUjnJKWot5CfMLyEl33i9kDmMEva5qT3+ARM7 4VX0q04gtGm15UHs0P+wBau1haOVohi+Ih8TDPRVxtI6Np8vi3pnGIaYWDrc33jcQPup NVNEavKcRigYy8dpLM5XwyAzYD4H/G5dn2cokGl0yqzBSR1Oe9o9leCaRrOyB0mwVrJv 4P6g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=xVl2zY9lHDdqJZYtyerF4SkPkC/l7NRyWv9M/LiD/50=; fh=yqPa6DsFGpb4Mbwe0juFQ7VGAQVHWOmLFCyjtGfccmg=; b=Pncz/XycPi8z8VuRYml9LDGFapMiDnHBK2OKayhgdqKjPa46I2X+/g7LkYu2NhcYoX wuzpG0dc0btWGuFGlNc7fLV3urmIeh2BOEDHVF2gIJIV2ktsyvub8EiXuFiw4fq9Vy5P aDKiEd2bdBiyx/PbrAEPzXFkSjBky4YhywYqSnygMSmCn0M0DWnCbR19p9T5H87ULIk/ e/bg34z9btK48NnOwY6R/lslv0fBK8e0Tpa4oQbc439HW7/bBUIt+ZGa677y4eTXWgw7 aYsKULQi4IrHaI5I2s+YWNN+lJi8TD4yv1mr4YKwkaVA7ItAAdRajjNpvjF2EHyH/Y/w d5Mg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=kNuOglRi; arc=pass (i=1); spf=pass (google.com: domain of ask4ismailsadiq@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) smtp.mailfrom=ask4ismailsadiq@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com. [2a00:1450:4864:20::42b]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-483719e8990si615565e9.3.2026.02.16.01.59.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Feb 2026 01:59:41 -0800 (PST) Received-SPF: pass (google.com: domain of ask4ismailsadiq@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) client-ip=2a00:1450:4864:20::42b; Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-4359c54b682so268605f8f.3 for ; Mon, 16 Feb 2026 01:59:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771235981; cv=none; d=google.com; s=arc-20240605; b=BXQnKCDnxmn/5cH4p9VACWUYJ4HE2cDHEbmmjUiweEOUrwSd3ua1Z7ZJjqgWiTmI+J rCZ38379QKt4yGNjNOOzDHRVmH32etrQt6lhUsEQ3aDTS3gsHv83GTBseXVtHmrppNgW +Dc/vCiEibDYTZGw4YhzxIPf6Tfx/TS/5WxMAraRxvl3it6RGUToX7JqNFVmBUtov12U UxHU9nQkh0ykJmCDVAR7GiWbcwecrY30tnM+ZMvShSSu/4u/pgs8F1t3lfhGoeLkExW0 aN0fjIgkJIINs+0gIJfN9ivZs8EsVdgm9Aa5rKgdJEywPWEXOz4ho5L4IRuH+i2WjBgR Wm9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=xVl2zY9lHDdqJZYtyerF4SkPkC/l7NRyWv9M/LiD/50=; fh=yqPa6DsFGpb4Mbwe0juFQ7VGAQVHWOmLFCyjtGfccmg=; b=Bf7c7gBkymwQyIXEUMJvnAw6eLIwUED9GdN3YhPWLEiQzz+no9gxlKQe1wD/waPy6g Y/uoyF7tnFVmkNkYJY2EVfrPQDeoQ6L8IYrQuVTr2gCWKdcugjs7z8QrJlbS2AJRkC1g EBxpAsVPH7r4I43crOOJLV2f+/F4/0TTVJ4943jAGFSkSb38gEc6bJANgJriVo+OwAU5 ujMuPUMBfrMRr+BkEX29iU10p7TsPq0XlZmRfI3hxjITnXQlOd1PhD6E5VGvsfY/eN2O m6fZK8JgPynqBMZi4P9VVZxPFoWUCkNoFk4w4iK8rA5ImiMEtaCLLf2u/P6S5KBTpCye KoKA==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AZuq6aLyRJpRKV98B1xLN5kdlWjneGfbiOugk786nFeNLgNY5x3XJNrqf68SSSDzvbV ph3gMuMFmeSAcckRlgd8ATZ1/xjy+LNcKKr6TLDEzbsOAN68r+3YN2CyIr0mAAXBpQq9Ugji2RK ML6PCWW+OFlij4gQd1z1igtu9flB2Eg9Npkd/R5JFrqOoZ5AzoQcMOJE2PKSG2St9LcvHvYs/MT r36ee4Eac2HacsUmN5HSDImgTIOb1UjRe9vKHvyFi9YyDF4MArOkDngAcKyR53J1Fi8m/DRgwrA QIpmd7jA X-Received: by 2002:a05:6000:144a:b0:431:66a:cbdc with SMTP id ffacd0b85a97d-43796aec01dmr11267588f8f.4.1771235980604; Mon, 16 Feb 2026 01:59:40 -0800 (PST) MIME-Version: 1.0 References: <088b5efd-7ba5-48f1-97f6-eb5881f5fd14@app.fastmail.com> In-Reply-To: <088b5efd-7ba5-48f1-97f6-eb5881f5fd14@app.fastmail.com> From: sadiq Ismail Date: Mon, 16 Feb 2026 10:59:29 +0100 X-Gm-Features: AaiRm53MWF1i9E4FPLf_B8YQbALs9AvMs2xcAdVTmqEB-hcru4ew_meSjWX2ksw Message-ID: Subject: Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin To: Light Cc: bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="0000000000006ff6c5064aee03b0" X-Original-Sender: ask4ismailsadiq@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=kNuOglRi; arc=pass (i=1); spf=pass (google.com: domain of ask4ismailsadiq@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) smtp.mailfrom=ask4ismailsadiq@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com 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.5 (/) --0000000000006ff6c5064aee03b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi list, light I want to clarify a point in your argument. > I don't believe the predominant "collective security assumption" is that "secp256k1 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 rephrase 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 alternative to be discovered, implemented, and adopted by anyone who is concerned about this risk". Note that this assumption does not, and cannot, preclude the possibility that other users store their coins in insecure ways, even en masse (as shown empirically by the above example of millions of coins held by centralized custodians). When we say a cryptographic scheme is "secure", that has a precise meaning: there is no known "efficient" algorithm in the sense of probabilistic and polynomial time PPT that breaks it. By that standard, secp256k1 is still secure today. A CRQC would break it, but a CRQC is not an "efficient" algorithm in this sense, and the same premise underlies the security arguments for any post-quantum scheme as well. So until we see an efficient PPT algorithm that breaks secp256k1, saying it is "secure" is still technically correct, and the proposed rephrasing isn't necessary. Best, Sadiq On Fri, Feb 13, 2026 at 11:13=E2=80=AFPM Light wro= te: > Hi Pieter, > > > 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. > > While it is true that "nobody is incentivized or encouraged to store coin= s > in an OP_TRUE", I believe your argument is incomplete because it is missi= ng > a more realistic mass-theft vector, which is that as of today approximate= ly > 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 actor= s > 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 (approximately 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 > > 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". > > > > 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 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 shouldn'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. > > I don't believe the predominant "collective security assumption" is that > "secp256k1 is secure". Everyone using bitcoin, going all the way back to > the genesis block, has known (or should know) that secp256k1 is vulnerabl= e > to a CRQC, and therefore secp256k1 is not unconditionally secure. So I > would rephrase 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 alternative to be discovered, implemented, and adopted by anyone w= ho > is concerned about this risk". Note that this assumption does not, and > cannot, preclude the possibility that other users store their coins in > insecure ways, even en masse (as shown empirically by the above example o= f > millions of coins held by centralized custodians). > > An alternative where "secp256k1 OR FancySig is secure" seems strictly > preferable to me (assuming we have some reasonable degree of confidence i= n > the security of FancySig at the time of activation) than relying only on > "secp256k1 is secure". > > As an aside, I note that because it has been known since before bitcoin > even launched that secp256k1 is vulnerable to a CRQC, we cannot rule out > the possibility that the people who leave their coins in CRQC-vulnerable > addresses -- even after QR addresses are made available -- aren't doing s= o > intentionally, as a kind of bounty for developing a CRQC. Freezing these > coins would violate their intentions. This is just one example of the > ethical problems 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 > encumbered 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 their 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 proposal to destroy bitcoin. > > Bitcoin can survive a temporary price dump, if that's what ends up > happening with vulnerable coins. Bitcoin cannot survive a violation of th= e > fundamental assumption that redeem scripts for existing UTXOs will always > remain valid, and certainly not a violation at the scale that you describ= e. > > 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 > > On Fri, Feb 13, 2026, at 11:20 AM, Pieter Wuille 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 > > available 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 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 > > themselves in a fundamental disagreement: > > > > =E2=80=A2 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-everyone migrates to it*, because the prospect of millions of BTC > > in EC-vulnerable coins threatens their own hodling. > > =E2=80=A2 Camp (B), fearing the possibility that FancySig gets broken = soon, > > possibly even classically > > < > https://www.quantamagazine.org/post-quantum-cryptography-scheme-is-cracke= d-on-a-laptop-20220824/>, > > > don't want to just not use FancySig; 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 > > 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". > > > > 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 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 shouldn'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. > > > > -- > > Pieter > > > > > > > > -- > > 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 bitcoindev%2Bunsubscribe@googlegroups.com>. > > To view this discussion visit > > > https://groups.google.com/d/msgid/bitcoindev/THqOJuI_s5C8B9jkklN73BB_Hzb9= SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh8NxxYbXwv4v6ikpStguW-QEvef4WgBZ7AQDz00P0st9= 1FMA%3D%40wuille.net > > < > https://groups.google.com/d/msgid/bitcoindev/THqOJuI_s5C8B9jkklN73BB_Hzb9= SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh8NxxYbXwv4v6ikpStguW-QEvef4WgBZ7AQDz00P0st9= 1FMA%3D%40wuille.net?utm_medium=3Demail&utm_source=3Dfooter > >. > > -- > 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/bitcoindev/088b5efd-7ba5-48f1-97f6-eb58= 81f5fd14%40app.fastmail.com > . > --=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/= CAHR1cdX_hFGvOqFg-HwLJ%3DE06z2SFz_3r-XJzBe4%2BcmR8Ue3ng%40mail.gmail.com. --0000000000006ff6c5064aee03b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi list, light

I want to clarify a poin= t in your argument.

> I don't believe the p= redominant "collective security assumption" is that "secp256= k1 is secure". Everyone using bitcoin, going all the way back to the g= enesis block, has known (or should know) that secp256k1 is vulnerable to a = CRQC, and therefore secp256k1 is not unconditionally secure. So I would rep= hrase 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 viabl= e alternative to be discovered, implemented, and adopted by anyone who is c= oncerned about this risk". Note that this assumption does not, and can= not, preclude the possibility that other users store their coins in insecur= e ways, even en masse (as shown empirically by the above example of million= s of coins held by centralized custodians).

When w= e say a cryptographic scheme is "secure", that has a precise mean= ing: there is no known "efficient" algorithm in the sense of prob= abilistic and polynomial time PPT that breaks it. By that standard, secp256= k1 is still secure today.
=C2=A0A CRQC would break it, but a CRQC is not= an "efficient" algorithm in this sense, and the same premise und= erlies the security arguments for any post-quantum scheme as well. So until= we see an efficient PPT algorithm that breaks secp256k1, saying it is &quo= t;secure" is still technically correct, and the proposed rephrasing is= n't necessary.

Best,=C2=A0
Sadiq

On Fri, Feb 13, 2026 at 11:13=E2=80=AFPM Light <= bitcoin-dev@lightco.in> wr= ote:
Hi Pieter,<= br>
> 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.

While it is true that "nobody is incentivized or encouraged to store c= oins 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 ap= proximately 2.5 million BTC is held by less than two dozen centralized cust= odians.[1] These coins are at a real risk of theft, due to both private thr= eat 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
> migrate to new cryptography, because we cannot assume that secp256k1 <= br> > will last forever. And I think the answer is essentially that it
> requires the entire ecosystem to change their assumptions. This does <= br> > not mean that adding a new opt-in cryptographic primitive is infeasibl= e
> or a bad idea; it just means that adding FancySig as an option is
> changing the collective security assumption from "secp256k1 is se= cure"
> to "secp256k1 AND FancySig are secure" once FancySig gets ad= opted at
> scale, and the discussion about adding new primitives should be treate= d
> with the gravity that entails. And it means that disabling secp256k1 E= C
> operations (or near-everyone migrating to FancySig, but I think that i= s
> unlikely) is the only way to change the collective security assumption=
> from "secp256k1 AND FancySig are secure" to "FancySig i= s secure".
>
> Because of that, if CRQCs or other EC-breaks become reality, or just <= br> > 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*, *s= hould*, or
> even *can* do this, and I'm quite sure that the inherent confiscat= ion
> required will make the result uninteresting to me personally. It may b= e
> that such disabling only happens in a fork that doesn't end up bei= ng
> called Bitcoin, or it may be that this happens only after a CRQC has <= br> > been demonstrated to exist. Still, given a severe enough threat I thin= k
> it is inevitable, and I think that this means we shouldn't worry t= oo
> much about what happens in chains in which EC is not disabled while > simultaneously EC is considered insecure: such chains will be worthles= s
> anyway.

I don't believe the predominant "collective security assumption&qu= ot; is that "secp256k1 is secure". Everyone using bitcoin, going = all the way back to the genesis block, has known (or should know) that secp= 256k1 is vulnerable to a CRQC, and therefore secp256k1 is not unconditional= ly secure. So I would rephrase the assumption to be that "secp256k1 is= currently secure, and if it is ever at risk of being broken, there is a la= rge incentive for a viable alternative to be discovered, implemented, and a= dopted by anyone who is concerned about this risk". Note that this ass= umption does not, and cannot, preclude the possibility that other users sto= re their coins in insecure ways, even en masse (as shown empirically by the= above example of millions of coins held by centralized custodians).

An alternative where "secp256k1 OR FancySig is secure" seems stri= ctly preferable to me (assuming we have some reasonable degree of confidenc= e in the security of FancySig at the time of activation) than relying only = on "secp256k1 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 int= entionally, as a kind of bounty for developing a CRQC. Freezing these coins= would violate their intentions. This is just one example of the ethical pr= oblems associated with such proposals.

A perhaps even more fundamental "collective assumption" of bitcoi= n users is that "a redeem script that was valid at the time that a UTX= O was encumbered will always remain valid". This is fundamental to bit= coin's nature as p2p electronic cash. If users woke up one day no longe= r able to assume that their redeem scripts would remain valid, then they wo= uld 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 tha= t freezes coins is a proposal to destroy bitcoin.

Bitcoin can survive a temporary price dump, if that's what ends up happ= ening with vulnerable coins. Bitcoin cannot survive a violation of the fund= amental assumption that redeem scripts for existing UTXOs will always remai= n valid, 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=3D509= 0869.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

On Fri, Feb 13, 2026, at 11:20 AM, Pieter Wuille wrote:
> Hi all,
>
> A thread <https://groups.google.com/g/bi= tcoindev/c/7jkVS1K9WLo> was
> recently started on this list about cryptographic agility in Bitcoin. = I
> believe there are important limitations around that idea, and wanted t= o
> 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.
>
> The idea is giving users/wallets the ability to choose the
> cryptographic primitives used to protect their own coins, from a set o= f
> available primitives that may change over time. I think this ignores <= br> > 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 <= br> > scheme should be adopted, because it's the silver bullet the ecosy= stem
> has been waiting for. At the same time, another camp (B) may appear > cautioning against this, because the scheme is new, hasn't stood t= he
> test of time, and isn't well-analyzed. These two camps may find > themselves in a fundamental disagreement:
>
>=C2=A0 =E2=80=A2 Camp (A), fearing an EC-break (CRQC or otherwise), wou= ldn't just
> want FancySig as an option - they would want (feasible or not) that > *near-everyone migrates to it*, because the prospect of millions of BT= C
> in EC-vulnerable coins threatens their own hodling.
>=C2=A0 =E2=80=A2 Camp (B), fearing the possibility that FancySig gets b= roken soon,
> possibly even classically
> <https://www.quantamagazine.org/post-quantum-cryptography-scheme-is-cra= cked-on-a-laptop-20220824/>,
> don't want to just not use FancySig; 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 <= br> > 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 <= br> > not know the answer. Possibly, the prospect of 100k BTC becoming
> vulnerable to theft won't threaten the value of the other coins, w= hile
> 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 <= br> > will last forever. And I think the answer is essentially that it
> requires the entire ecosystem to change their assumptions. This does <= br> > not mean that adding a new opt-in cryptographic primitive is infeasibl= e
> or a bad idea; it just means that adding FancySig as an option is
> changing the collective security assumption from "secp256k1 is se= cure"
> to "secp256k1 AND FancySig are secure" once FancySig gets ad= opted at
> scale, and the discussion about adding new primitives should be treate= d
> with the gravity that entails. And it means that disabling secp256k1 E= C
> operations (or near-everyone migrating to FancySig, but I think that i= s
> unlikely) is the only way to change the collective security assumption=
> from "secp256k1 AND FancySig are secure" to "FancySig i= s secure".
>
> Because of that, if CRQCs or other EC-breaks become reality, or just <= br> > 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*, *s= hould*, or
> even *can* do this, and I'm quite sure that the inherent confiscat= ion
> required will make the result uninteresting to me personally. It may b= e
> that such disabling only happens in a fork that doesn't end up bei= ng
> called Bitcoin, or it may be that this happens only after a CRQC has <= br> > been demonstrated to exist. Still, given a severe enough threat I thin= k
> it is inevitable, and I think that this means we shouldn't worry t= oo
> much about what happens in chains in which EC is not disabled while > simultaneously EC is considered insecure: such chains will be worthles= s
> anyway.
>
> --
> Pieter
>
>
>
> --
> 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 <mailto= :bitcoindev%2Bunsubscribe@googlegroups.com>.
> To view this discussion visit
> ht= tps://groups.google.com/d/msgid/bitcoindev/THqOJuI_s5C8B9jkklN73BB_Hzb9SsiL= M6BFp4zFP3zWQoRevKoLVspdwjwh8NxxYbXwv4v6ikpStguW-QEvef4WgBZ7AQDz00P0st91FMA= %3D%40wuille.net
> <https://groups.google.com/d/ms= gid/bitcoindev/THqOJuI_s5C8B9jkklN73BB_Hzb9SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh= 8NxxYbXwv4v6ikpStguW-QEvef4WgBZ7AQDz00P0st91FMA%3D%40wuille.net?utm_medium= =3Demail&utm_source=3Dfooter>.

--
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 088b5efd-7ba5-48f1-97f6-eb5881f5fd14%40app.fastmail.com.

--
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/CAHR1cdX_hFGvOqFg-HwLJ%3DE06z2SFz_3r-XJzBe4%2BcmR8Ue3ng%= 40mail.gmail.com.
--0000000000006ff6c5064aee03b0--