From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 13 Feb 2026 14:13:14 -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 1vr1PV-0004ei-Eg for bitcoindev@gnusha.org; Fri, 13 Feb 2026 14:13:14 -0800 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-40eeb6c6ce4sf8194494fac.0 for ; Fri, 13 Feb 2026 14:13:13 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1771020787; cv=pass; d=google.com; s=arc-20240605; b=U7OOYxo9daSbiFOhDiVpc0WcmjXBYna4hzIDbBufUyPWUYcFtrUN5LVIuvQNJPBS82 eQH8QL+gw+O0KjAydsredCd7GjBI7rUUqkAJPgkcS51B/oI2p3Z6vnJnRCPZ5Lcb3Auu uSfNqs/DNZtPHXinlNQZyt0+Ih7Htgxbo4eaWdi9nhbnilzZDsCKMfIJZZHtXlklLklc YAAxNREtO47Q+phHoPNkrV9ey1bdjFvitBlPwM/GMBoAVFCTU+U5X5DpNBKWM+h5wfZw fFleH3TasZ8rAbjUnVq61jJXRhQ8HhxrmAh8ARbKRm/k3HwLFdmvFltgJqW4hnqB3luy zfIw== 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=NS2y1yo/UuXTYlHYUoI/ZyL0UZvJxSwijM0o9giz1jk=; fh=XBLYBjvMOZmMUL1HR4ZM1/r736ShL15swJbnw7F+RDI=; b=KZrhFlDSpzj8UutS9UkUgb5e0qWkj+iyPOEv2vnnfdTx5aleZ0FG8SUTMbqIp9SUBa JUU6TRmwWsP3wKvByQspLJcpxa2mS4PMeeOMbRkvPLlypL1lIqf7uDJtabFnuNbW4/fH b9jZhJPYOGThUwCJrG/fSoAZTPtcYqOur+06h8+64wLjhNN9QjVSGlXJtqbBl234jUvN X7VO4/mq4Te0uaI4KAaZ18hzRhN793ST/iNYB/0TRLw0XBnURGHGbrgIb0HpSqDkk+Kr FRvDl/LpCXpYxg9DiVP0Ek5wn5gk+0fz90CGRqvRNGSxE9I5Yej2NHmujnWzXpYYx8jW 3uxg==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Lv25KFiF; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::532 as permitted sender) smtp.mailfrom=eth3rs@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=1771020787; x=1771625587; 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=NS2y1yo/UuXTYlHYUoI/ZyL0UZvJxSwijM0o9giz1jk=; b=W6aBM1PnSnfuDg/FJMi5EblgWC9YAoOP945Dr8mLNTC5dCWU9UlU6rBHOGxiPMHiAb N5FMegW3w9scgZ8M2ql4AazJOxDVU7lZW97WWd/QM8kuhylLbUn6GuSr23UJvF1Bas6u 0ze++yZHMEg2x9e5yhwqgkrLMAYWTFkxOBUtMuYrnlsdakCcpFFU8BkqbJjLbFWJp/sv wxPIzEFyFM7daBL12LvpgJrBAnpC8Sypv73PD5yfGrgY89gtbk2G6mBUpLQDusP1zF8Q 8B3SLquV8rljY19avhamgKKIOJSD8kr+e+cDX1Hf3FWXvvvcOBSXLdYd46T9qamuWEif FchA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771020787; x=1771625587; 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=NS2y1yo/UuXTYlHYUoI/ZyL0UZvJxSwijM0o9giz1jk=; b=bB+iY8ClnQ9YbO64UtkMzoOztCddLp/tcWzcIEhmtdtmQY5wBlmxFOH52pSZUbwAt3 fi3XA508uG5cirVzl0IXZGo9dtch9QIfZQWVS0Wuce+umiXLXHEX9eFJXR6P8LM95J46 y8rf+cT6VYPrAJay5tYlASBZ+vNYLbeiQ0G+Jn8dLKDZeg1TQOA7wwEL7gzVMejSe5YW /duFBfmArZQOoCAw/gCkq+tM/UBFvBr/shOiNNQ3M6Vy94Zn5GMgCDdhXuxYytmtIaG0 Fg1/bM6I+9jE8lq2lowr4xFYD0BRsJvlMdNsqo+G2zK5j9WvWNB4S0CFsphhkkbGJFUG ySog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771020787; x=1771625587; 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=NS2y1yo/UuXTYlHYUoI/ZyL0UZvJxSwijM0o9giz1jk=; b=MLdmYi+oHLfKTCju5rE0AUVfXqiYQ0uXoDsrdcbE9YULoUN/zQXDfu2YCSmo4SOq+D ypn7OOvRrJOHhLJ8CaOZTW7mQWOm9+N/k6c7ohqNZhubDEyaYq7tsPo5VKHipYTXD0rM h1EyrjdpNjqmpZXjWeIV5dN1NHlbdpOQjUFbWMN0D2y8PYJNtiXDbnnlr41RqtA8Mf6y HE/9LtfCWFK9cb02AcoTNY4ToztXEliUtoFSKPsgFe8ZMx1o+G/N+3OBoOww1Hj+5CC2 53tZyeokauU/3JneaD11sS0BvUm29Qe+AePcXv5jsyHCz3t6WYQeJcBDZTlC7WPu3Jt7 QJZg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCWIHRUmNLbM/JQVvCnDAR1WWPrb5h4hpV7dFP4KVUQ76CWJRQjNmmaoB8RxQm2vzZSBj7VP4CUPx5Zb@gnusha.org X-Gm-Message-State: AOJu0YxcnO94kAuSnuhdsUE44XwuLol+OLWHG50+hS1fMW7c/sqBpk8D tgpKcCrPoryKc4W4t8zHNQm6JUJyTdSArfVmoCccsOwVXZHOTyTfHK1U X-Received: by 2002:a05:6870:9345:b0:36c:abe0:83d3 with SMTP id 586e51a60fabf-40ef3ee5d01mr1787571fac.39.1771020787294; Fri, 13 Feb 2026 14:13:07 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+F1YlGCdawePCHwOslP1tkNMI2OzDMxxqAXwWwNZz0dgQ==" Received: by 2002:a05:6871:d10e:b0:404:2f39:e1c0 with SMTP id 586e51a60fabf-40eca697e32ls1483949fac.2.-pod-prod-08-us; Fri, 13 Feb 2026 14:13:03 -0800 (PST) X-Received: by 2002:a05:6808:6785:b0:43f:76b4:816e with SMTP id 5614622812f47-4639eec3ed0mr1802412b6e.4.1771020783273; Fri, 13 Feb 2026 14:13:03 -0800 (PST) Received: by 2002:a05:6808:b2b:b0:44f:fe66:38a2 with SMTP id 5614622812f47-46395e57794msb6e; Fri, 13 Feb 2026 13:55:04 -0800 (PST) X-Received: by 2002:a05:6a00:b904:b0:824:374a:140d with SMTP id d2e1a72fcca58-824c944908emr3323091b3a.4.1771019703168; Fri, 13 Feb 2026 13:55:03 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771019703; cv=pass; d=google.com; s=arc-20240605; b=iyEdIPIHPqVWZlbv8kF1ge/nvkzgmu74iGAmoClRxwSHRL0CLjLsqbQ8Lo/NdiHAFL +Qt76rTunltN8LPJY+7qXRC5UUVxmkTFKLtKZChJoglNyA9bZs3B5nPGCm6bMu6IqWFK 1T/OfrhZhATp108UqYTpgl9OfDRfWVNls+5bykExxTyp+aMKvHGwIZ6XNWvgLHJle2vV KhypR8CwG6+P3y3u7KIWqedg608qp4pRHa6D0nGul18HNdXAEfjYiJkqSKuyZIP5h/5s BPDOObZo5H3nQQl86qRtCsW1LSnZ1rD7cNxPdQaI8FAbOtHta5jef4+t1hq0k+5tl/YM 7hZQ== 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=dylG6PdX/ebYarsqnU1JLg3alCvyyBL8X/+bpq/mZ48=; fh=dRl5MJeON1RwI+/xO4/cP/Y3U38+pgB9/4rd/p1o9tg=; b=A6gHhMdMXmFlK5BpklwbLG0CgVpdxe9W/0f5Z0xXg0JlmMAgZn6Dhno2l03QSz/458 sLRs5i1hN2Sa24bQP2vcsRScJS6REPsOwTdwOvc7akWcMsDdcF8eGZxaiSAmWiqKaphb yoE1h/VhM15Hi1Lhhk+H8rXiqRNCRjMXm6k4mrCK90rTbemdw6mmv7v8ROYABAVXaopd n687aJFvBvQEtrwifG3g3q+oeGhlFMZLYSh1LHapTgZDtgIvu2PwKRZRgzfCGbI1rXAQ 5JBBNe0/hQEK/BJMMkS/pzILNDZI9aF9RXZHcXIuxJej7QWUQcZwn6b5b5j4igXw7zdL wS8A==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Lv25KFiF; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::532 as permitted sender) smtp.mailfrom=eth3rs@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com. [2607:f8b0:4864:20::532]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-824c6b810easi116370b3a.7.2026.02.13.13.55.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Feb 2026 13:55:03 -0800 (PST) Received-SPF: pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::532 as permitted sender) client-ip=2607:f8b0:4864:20::532; Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-c6541e35fc0so813649a12.3 for ; Fri, 13 Feb 2026 13:55:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771019703; cv=none; d=google.com; s=arc-20240605; b=fvzMwV9Tobvop8DP4XKgCs0psgCRiw2/14GwwBMrCxgbfS/+LjMTGqc7BFmLM9O3VB 0VdzvJnad/ucn33OJG1UuKBlZsA1LUH435qo1O3wRpzVevYkbmSvmynO2OClZHKo5VSR 8LaDzTRsc3s3Ata7BSDHLkza8Oh9Abe3oDL8zIuYVXj37ualqSmQShNYXIq6m2wRix+o H9nVmK1hN7Iiz6fLhjRK6miGFKziEZ8UUbtwW29JSrRmNML8+A/h5xQllFz/bLbOKTuM yAgJhTDXm1VYW/rU7yT3lbsZ3CDWfuiud13ctjXawBuP13My1z/dwLQdPgqqqcBfPigi V6RA== 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=dylG6PdX/ebYarsqnU1JLg3alCvyyBL8X/+bpq/mZ48=; fh=dRl5MJeON1RwI+/xO4/cP/Y3U38+pgB9/4rd/p1o9tg=; b=eRNW5yMSjhVq4o/Ix967nw/KAdh8czo58VC+oc5dpiGkWOUz/ndTRy3hcdblNCX+UM v+9jjfPQtg/8InbMCIlYcwWYEpwiZu8T6Jq60GenfGHCurHgBgEICI/cDx04oF4HQ1Io iqYptgSoFUjMORWdzQxdtQ96qvrVu1OGXuza/uVncvgGacd0TcAZvTj4XPdcjCSbXCpL NgVyVmEmqmGwz6AjIh0mmJ5U2wId0c7JnQMfFxW/tYscs3hbGRhEOSPmstfRSJfQy0xz bfmTwQnHf+PmnEJmFohYL8Wu4fWN/N4EaalTch394MneJzKfO0RhyffaA1L7FjisnHy+ JUaw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AZuq6aJoUi8evqwKpwME+mpPL3HT7TYCkVfG0AN8DJa5XajkOFUzj6dGZeqOFe8K2bO pub1dCRAY5eGaiqVSEgTRMtvuL5c3+xsfJM3egJ1AgoWWdJSLbUPuagE3lkEYvAflos3bgcE0sG 5mIQzXQZACqI1pXWXEm9YhDWVGjTctBWkAyXeQPgpfqEDJIOujrmYXZ52rFcrMtdPxQL9kXnZDj fT4pD3R7SoB1XNTXOXZK6T1ptXIlZaCrnDduA8pGJ7oSUtx5yo7SmFA0So1IOo09FQ9WQ0pXVo8 QWDurobvnxCugoBa6lc2qRKdZDwF2XaVDhfQfPd38c3qrKv/ENK6OR+fY0m8SU4CyiiUyruKjLP kybiu+74+DbeURG7/jjmtE2c1a8JmaLQvckXhmteE6DoZtyOFIXWhUwvozDHBzbRaq8NHpXheWU 4HWtObGJVCIiau3+JFo+kk/TpV+Q== X-Received: by 2002:a17:90a:e18b:b0:354:a1b8:24a6 with SMTP id 98e67ed59e1d1-356aad7a8f0mr2802880a91.31.1771019702589; Fri, 13 Feb 2026 13:55:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ethan Heilman Date: Fri, 13 Feb 2026 16:54:26 -0500 X-Gm-Features: AZwV_QhaT3c9-BhF-OX11dxJlYb77llVT3KBHZX83YckG80BHQb49D_nRmTFdY0 Message-ID: Subject: Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin To: Pieter Wuille Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000435cbd064abba833" X-Original-Sender: eth3rs@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Lv25KFiF; arc=pass (i=1); spf=pass (google.com: domain of eth3rs@gmail.com designates 2607:f8b0:4864:20::532 as permitted sender) smtp.mailfrom=eth3rs@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 (/) --000000000000435cbd064abba833 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with your overall claim that we should be cautious about which digital signature algorithms are added as op codes. The danger of a break in ECC is real, but so is the danger of adopting a newer signature algorithm with less vetting. These risks must both be taken seriously. > 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. Agreed that allowing users to choose their cryptographic primitives from a menu of many options would be problematic: - Skub and fragmentation over which algorithm is best (Camp A vs Camp B) - Greater resource costs on wallets if they have to support many algorithms= , - Security analysis is spread over many different schemes, - More algorithms increase chance any one of the algorithms is broken, Ideally Bitcoin would only have one signature algorithm at a time. Algorithm agility aims to provide a standardized upgrade path from a weakened algorithm to a new algorithm that the community overwhelmingly wishes to use. It should not require a menu of different signature opcodes. Yes, the backup signature algorithm exists, but it exists only to enable this secure upgrade path. In this light the high transaction fees of SLH_DSA can be seen as a benefit since they incentivize using SLH_DSA signatures only when absolutely necessary. > 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. As Bitcoin moves to PQ is I want to ensure the solution is standardized and that wallets use the standard approaches. I worry that some wallets might roll their own adhoc protections if we don't have a clear and well supported standard way to support PQ signatures. > 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. I agree that the incentives make that an extremely likely confiscatory soft-fork. While it seems like the most likely outcome, I don't feel comfortable making PQ plans that depend on this happening. I also don't feel comfortable advocating for a confiscatory soft-fork. For these reasons, I have not baked the assumption that a confiscatory soft-fork happens in my algorithm agility proposal. No one can say for certain, but it seems reasonable to assume long exposure attacks will be practical years before short exposure attacks. If true, then a soft-fork to freeze P2PK/P2TR will happen before EC opcodes are frozen as P2SH will still be safe to use (as long as the public key has not been exposed). By the time short exposure attacks are practical, will enough P2SH,P2WSH vulnerable coins remain to justify freezing EC opcodes? What's the breakdown on the number of coins in P2SH and P2WSH outputs that haven't moved in 5 years? As you ask, how much is enough? This question of what to do with EC opcodes is worth more discussion. My hope is that once everyone agrees that they are insecure, no one uses them, like no one using OP_TRUE scripts or OP_SHA1, but that hope is not justified, what should we do? opcode anti-discount? Disabling them like you propose? On Fri, Feb 13, 2026 at 11:23=E2=80=AFAM 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 toda= y. > > 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, regardles= s > 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 featur= es > 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 fo= r. > 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: > > - Camp (A), fearing an EC-break (CRQC or otherwise), wouldn't just > want FancySig as an option - they would want (feasible or not) that *n= ear-everyone > migrates to it*, because the prospect of millions 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 > 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 goo= d > 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 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 thi= s > 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 th= ey > 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 entir= e > ecosystem to change their assumptions. This does not mean that adding a n= ew > 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. An= d > it means that disabling secp256k1 EC operations (or near-everyone migrati= ng > to FancySig, but I think that is unlikely) is the only way to change the > collective security assumption from "secp256k1 AND FancySig are secure" t= o > "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 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 > *not* arguing that "Bitcoin" *will*, *should*, or even *can* do this, and > I'm quite sure that the inherent confiscation required will make the resu= lt > uninteresting to me personally. It may be that such disabling only happen= s > in a fork that doesn't end up being called Bitcoin, or it may be that thi= s > 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 mean= s > we shouldn't worry too much about what happens in chains in which EC is n= ot > 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. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/THqOJuI_s5C8B9jkklN73BB_Hzb9= SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh8NxxYbXwv4v6ikpStguW-QEvef4WgBZ7AQDz00P0st9= 1FMA%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/= CAEM%3Dy%2BWbqY4FE9XH50K2B8DjE5zx_D1zZ-sZmfdmg0vvUiyLTQ%40mail.gmail.com. --000000000000435cbd064abba833 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with your overall claim that we should be cautious= about which digital signature algorithms are added as op codes. The danger= of a break in ECC is real, but so is the danger of adopting a newer signat= ure algorithm with less vetting. These risks must both be taken seriously.<= br>
>=C2=A0 The idea is giving users/wallets the ability to choose the cryptographic pr= imitives used to protect their own coins, from a set of available primitive= s that may change over time.

Agreed that allowing users to choose th= eir cryptographic primitives from a menu of many options would be problemat= ic:

- Skub and fragmentation over which algorithm is best (Camp A vs= Camp B)
- Greater resource costs on wallets if they have=C2=A0to suppor= t many algorithms,
- Security analysis is spread over many different sch= emes,
- More algorithms increase chance any one of the algorithms is bro= ken,

Ideally Bitcoin would only have one signature algorithm at a ti= me.

Algorithm agility aims to provide a standardized upgrade path f= rom a weakened algorithm to a new algorithm that the community overwhelming= ly wishes to use. It should not require a menu of different signature opcod= es. Yes, the backup signature algorithm exists, but it exists only to enabl= e this secure upgrade path. In this light the high transaction fees of SLH_= DSA can be seen as a benefit since they incentivize using SLH_DSA signature= s only when absolutely necessary.

> A small note aside: you can a= rgue that it is possible for people to store coins insecurely, like in an O= P_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 w= hat possibilities exist, but which approaches people are likely to / asked = to adopt. Nobody is incentivized or encouraged to store coins in an OP_TRUE= .

As Bitcoin moves to PQ is I want to ensure the solution is standar= dized and that wallets use the standard approaches. I worry that some walle= ts might roll their own adhoc protections if we don't have a=C2=A0 clea= r and well supported standard way to support PQ signatures.

>=C2= =A0 I do believe that disabling EC opcodes will be necessary in any economicall= y-relevant surviving chain, due to the millions of BTC that are unlikely to= ever move.=C2=A0

I agree that the incentives make that an extremely= likely confiscatory soft-fork. While it seems like the most likely outcome= , I don't feel comfortable making PQ plans that depend on this happenin= g. I also don't feel comfortable advocating for a confiscatory soft-for= k. For these reasons, I have not baked the assumption that a confiscatory s= oft-fork happens in my algorithm agility proposal.

No one can say fo= r certain, but it seems reasonable to assume long exposure attacks will be = practical years before short exposure attacks.=C2=A0If true, then a soft-fo= rk to freeze P2PK/P2TR will happen before EC opcodes are frozen as P2SH wil= l still be safe to use (as long as the public key has not been exposed). By= the time short exposure attacks are practical, will enough=C2=A0P2SH,P2WSH= vulnerable coins remain to justify freezing EC opcodes? What's the bre= akdown on the number of coins in P2SH and P2WSH outputs that haven't mo= ved in 5 years? As you ask, how much is enough?

This question of wha= t to do with EC opcodes is worth more discussion. My hope is that once ever= yone agrees that they are insecure, no one uses them, like no one using OP_= TRUE scripts or OP_SHA1, but that hope is not justified, what should we do?= opcode anti-discount? Disabling them like you propose?


On Fri, Feb 13, 2026 at 11:23=E2=80=AFAM Pieter Wuille <bitcoin-dev@wuille.net> wrote:

Hi all,

A thread was recently started on this list about cryptographic agility=20 in Bitcoin. I believe there are important limitations around that idea, and= wanted to offer my own=20 perspective. It's more a philosophical consideration, and is not=20 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=20 becoming vulnerable to theft with cryptographic breakthroughs, so do=20 your own due to fungibility, regardless of how well protected they are.

=

As an extreme thought-experiment, imagine that tomorrow a= =20 new cryptographic signature scheme FancySig is published, with all the=20 features that Bitcoin relies on today: small signatures, fast to verify, presumed post-quantum, BIP32-like derivation, taproot-like tweaking,=20 multisignatures, thresholds, ... Further assume that within the next=20 year or two, voices (A) start appearing arguing that such a scheme=20 should be adopted, because it's the silver bullet the ecosystem has bee= n waiting=20 for. At the same time, another camp (B) may appear cautioning against=20 this, because the scheme is new, hasn't stood the test of time, and=20 isn't well-analyzed. These two camps may find themselves in a=20 fundamental disagreement:

  • Camp (A), fearing an E= C-break (CRQC or otherwise), wouldn't just=20 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 migrate to it, because the prospect of a potential break of FancySig threatens their ow= n hodling.

This is of course an extreme scenario, = and in reality the=20 divergence between camps may be much less incompatible, but I still=20 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= =20 people to store coins insecurely, like in an OP_TRUE script output, or=20 with 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=20 which I do not know the answer. Possibly, the prospect of 100k BTC=20 becoming vulnerable to theft won't threaten the value of the other=20 coins, while the prospect of 10M BTC becoming vulnerable may. Depending=20 on where your belief about this lies, you may end up with very different conclusions. Still, to me it is clear that some threshold=20 exists above which I would be uncomfortable with seeing that many coins=20 move into an untrustworthy scheme, even if they are not my own coins.

This brings us to the question then how at all Bitcoin=20 users can migrate to new cryptography, because we cannot assume that=20 secp256k1 will last forever. And I think the answer is essentially that=20 it requires the entire ecosystem to change their assumptions. This does=20 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=20 changing the collective security assumption from "secp256k1 is secure&= quot;=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 from= "secp256k1 AND FancySig are secure" to "FancySig is secure".

Because of that, if CRQCs or other EC-breaks become=20 reality, or just the fear about them becomes significant enough, I do=20 believe that disabling EC opcodes will be necessary in any=20 economically-relevant surviving chain, due to the millions of BTC that=20 are unlikely to ever move. Note that I am not arguing that= "Bitcoin" will, should, or even can d= o this, and I'm quite sure that the inherent=20 confiscation required will make the result uninteresting to me=20 personally. It may be that such disabling only happens in a fork that=20 doesn't end up being called Bitcoin, or it may be that this happens onl= y after a CRQC has been demonstrated to exist. Still, given a severe=20 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=20 which EC is not disabled while simultaneously EC is considered insecure: such chains will be worthless anyway.

--=C2=A0
Piet= er


--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/THqOJuI_s5C8B9jkklN73BB_Hzb9SsiLM6BFp4zFP3zWQoRevKoLVspdwj= wh8NxxYbXwv4v6ikpStguW-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/CAEM%3Dy%2BWbqY4FE9XH50K2B8DjE5zx_D1zZ-sZmfdmg0vvUiyLTQ%= 40mail.gmail.com.
--000000000000435cbd064abba833--