From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 13 Feb 2026 14:13:31 -0800 Received: from mail-ot1-f57.google.com ([209.85.210.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vr1Pm-0004fP-Q2 for bitcoindev@gnusha.org; Fri, 13 Feb 2026 14:13:31 -0800 Received: by mail-ot1-f57.google.com with SMTP id 46e09a7af769-7d496d080d8sf7080817a34.0 for ; Fri, 13 Feb 2026 14:13:30 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1771020804; cv=pass; d=google.com; s=arc-20240605; b=XVhuxR/mPXk1CAPcT1yMNM8AJJwJwCQHNNIzpxRYlt25BB6Tf0j3wSI77pSO8j+uat tldYeO97siXxZoHneTDXnxpn8GYadI0K0o1C/ySHl/DbV14/HJXaWR21ns05AzfgbjFJ 9cfT8PKLcHnsK0EZmCGh06qKX4suU2Roov5GXVwSXTbJlUhfFXZLWRyHpOS3Bz1nC4Lm D1oK99K8yg/1AP+f6g61hTCTE0Vdq/mJlo2AnVYpHUxayFkopErZs6btR8d1QeR67peF zszX4IxrfKqOhz/vGF5LFkNOxj1w+KgvgHYPh+pGlZZgwTuPXLYNVU/IE7jzLUWJrhfT Gdbw== 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; bh=PgVgs6DMgreBFAXF3QZFauDk7OkGkdO1QoNioE3CW24=; fh=RToah1H81JNuXCUBMwTpiyM3Kfftyimop6zTQskb7oo=; b=lTHtWyCwGYw2IS9J8HVuET/zcUfmbyYoDYmcStVIwZVSiM7+NcL2Trw2vUUiyQQzfz V4ZbuXZBJVZMJ+hXiWs3sySr7kot/H7CCyW8SiYwVo92KGrxfCA/Fz5xK/IZ77Gk0MKa mKaR27j7YDSG8UJI0csiYlhPTHGxrpl227kdHx8oSdrQdhkZgZrlWwbY6mlsb//TKz22 XpbVxWSz1EmcRsVyHmpuCNVjrMo/u+T4wnr2UuLuc77eWbtT1GrO+pyoR+J1bZK9dJ77 ezumu4FOvAXm8PLAlNFQe7Pp2vFxrXF0SbrJVnuK71mUjwb+0RrFVKt3rxevM+AGkTVS 8agQ==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b=qwLz8nPM; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1771020804; x=1771625604; 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=PgVgs6DMgreBFAXF3QZFauDk7OkGkdO1QoNioE3CW24=; b=fpr6Va5uMXJnj9iInHHh2KNBHVZ9p1w/KeX0OFqDJjzFpdZyvK1/9b4pdvwWgpLR8x G19FUk9uaKalf4qdrTQNOEsKlwhFGaIgRhUwyFf+eLQnIMrW8y1tnjZGVGBCOLN0i5B9 UWUfs2lzfKjEseIZHPxdxORSy9NiG7cC3mnv2V1EivCSYtZBoITzgG9W1bVZXPItaWq5 DRTWINzDHkE1ZS44PIddsUd2jeuDEa1NkuC0Sc0BEiQO5/2Lv1VDUdocRPprphoVxM1n koQzBL63z8fUiKEmp9XzWv7rmidMYbpmRPanTqcpZiKVVdpz04EJ2i1nSiTgE2iZI6WH eDZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771020804; x=1771625604; 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=PgVgs6DMgreBFAXF3QZFauDk7OkGkdO1QoNioE3CW24=; b=ushZypSe9NzwisZSjGcNYTkDbQSYVPw6X3kv4xmUQnFVW6dkm0rXf+gq36mom3/dyL oS+Tc3CWgOLHaB8hg+9nJOoeN9NcIXzvRh3gAWruvGCJFaZ20gegldA81zDMOaL+5gQ8 yxiCr4vv9V99StYx7QZvh1izYt1rr2Gi5rks7skmpg2WzgHA5F8d/T4LKL0BrDssmjX4 ZU5/hSvMapu0POcQxTYINbUDQOfft59xy7qigAJE+KCA3luuvFkrAC5qUjOsXDqj4hng 5nz71X/iJ2Aj4QPJ3MbsNMKFgczF6hb+9YONFD+x5aac69TjJH/vLZkcPXT0Xw8hwhcK V2UQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCVYA7CZs3rk376BG7o1tGZOOL3DMvVIhtP8lqya2gMSSvDMDms6Ovez1Ef3QD0Sfl9nhHGYe46idxT3@gnusha.org X-Gm-Message-State: AOJu0YwyzXqhorOLELvMDgimskLgohkDhcCBLsF30gf68JdRmRtqkTfa Jn59yKlMldIUODaT7NfcHBxWhcSbKsDYzK3+qDFY+MzCIQdZQAHI2HIZ X-Received: by 2002:a05:6808:23cd:b0:45e:91ea:89fc with SMTP id 5614622812f47-4639eedba4fmr1681218b6e.2.1771020804525; Fri, 13 Feb 2026 14:13:24 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+E4tMZAMFrwGuvSStWgQWs6Ioz+JzLBIsGezi4iymWADg==" Received: by 2002:a05:6870:2114:b0:3d4:d703:74d7 with SMTP id 586e51a60fabf-40eca31b5f4ls984733fac.0.-pod-prod-02-us; Fri, 13 Feb 2026 14:13:20 -0800 (PST) X-Received: by 2002:a05:6808:23cd:b0:45e:91ea:89fc with SMTP id 5614622812f47-4639eedba4fmr1681154b6e.2.1771020800176; Fri, 13 Feb 2026 14:13:20 -0800 (PST) Received: by 2002:a05:600c:5908:b0:483:6a76:922 with SMTP id 5b1f17b1804b1-483702f5e0ems5e9; Fri, 13 Feb 2026 11:39:25 -0800 (PST) X-Received: by 2002:a05:600c:198b:b0:483:703e:4ad9 with SMTP id 5b1f17b1804b1-48379be80f3mr5445635e9.19.1771011563164; Fri, 13 Feb 2026 11:39:23 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771011563; cv=pass; d=google.com; s=arc-20240605; b=OvoYTdAwZ1fd5NYxcdk2qVA4KtRz5PtlyGfbvcFoiq2Nvss8lL3AG1c1AKOFsjCJtp Pxwd2UddOsFmP/2PDqqRL5FXnNJ9+8qSCztgzSu0yt+c2sLyc7OSlfvQhbYK+t9GOhVX YxuaDsa8CJPnquLpmwcbAnGm6iesw1cYFF0O9uqXxl8DhZiMejxESEmtgPltzmsEu7as 03r/r0auEGXY7137ya7OWKBKKQiFSClhE+vZrCiEqqmTC+kBq6QyQjc4dH/lLWy/8Xt/ UWfeD7qs41F5hsfIbcsr8GDfIUC/AUvXXs9y8kdRZk/g0BLTAIA5g13J97amzdlJ77PI fR1g== 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=oa3cZc3zV5r5nCU1axH9u4U7U5fan+66yjAlDXb7qJk=; fh=dRl5MJeON1RwI+/xO4/cP/Y3U38+pgB9/4rd/p1o9tg=; b=JgPSbd/B+pYBeby898XPTuxc/5QP6O1N34KLHmnyahlnB+4QYx6YEyTN9RzRy8Pe2j I1NxepVu77cHbOXBNciY7u0E9CMF5bT5TqmuwNo2VBF1E674qdPJkINH5RCtbtLE2a9G Tcfq5BZkFSuCLsuQrr/woGJd22ZrycC90WZ5f+LCKMBqgvNDoBviilDAHxcFx8mdH/O6 8Crz1bOdcdS7qDNX5t2e8yNNts57Lt/Z1/0fB05DGe7gLib3JnvpSt3SBfIS9dehak+m Y4mir5SVVOLQNP7FVa20f0ter9wabD8xTOLL7NuJFVrGAG/vdI+xYfoR6oaPt6n0DNmB zekg==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b=qwLz8nPM; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com. [2a00:1450:4864:20::632]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-4836a4b3741si100625e9.2.2026.02.13.11.39.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Feb 2026 11:39:23 -0800 (PST) Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) client-ip=2a00:1450:4864:20::632; Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-b885e8c679bso166923966b.1 for ; Fri, 13 Feb 2026 11:39:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771011562; cv=none; d=google.com; s=arc-20240605; b=DUXBWIJY3Yfs3zpzizfOK2xZiZmNa0nQFglJSVNreL0BETY3EqR7RG9liq4ClQCvJ/ MPPPniYZPXdfxxdqXvpAEgj1MRhFZ6YA73i9pFO7vADJxVIOCkVU/kHR8SgbWicCzqsD x2C5E/FuJpcCADHHNt9JtCgBwQgwhiVaTW74Hn+yoc8qslKDJxwIDnPZqIjfgXy0qTWi /TcUcZ+7bWfB0QPev7QgrRQ9wmzxJNYfKXxggIOQIDugl2xdfuvyRNRmEhReGca8SXQw wpc7wNXiw5it6Tag9QbyH0r5lHOnjOMYaN78k0Ki6ZA9tDgn+9gYtfaMqcRgn/V3Y7c3 InVQ== 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=oa3cZc3zV5r5nCU1axH9u4U7U5fan+66yjAlDXb7qJk=; fh=dRl5MJeON1RwI+/xO4/cP/Y3U38+pgB9/4rd/p1o9tg=; b=LJXCQwR+GWkFpfixXAco6/zqILIL8qHk2xj7fjz1ZB5TTfJUCftbJDF368/So00WbR 4w5Kj1gIxx/nUl+3fvRrBv1wVeinbdi0lhpULErxaNQYL/m3lEagTinQNBpwClwlG+rb G4Av3TjRRa7i77zI3w1toTXOVnMWd1R7xe6lCWnfgQX5n04mMoVhC2EJ7xppCEncmarA 22/rhTSfWB90AdPyCozcTgBEDngOKYyeE+ZDtrYwmyEfxBEUW0IQH3FOQREQD3FIe9zj diWmx0ST+y6ErTI8yngPlOqafT+F1o9z7e3OaqI8d82yrQiPNcQxy7T/RzvfqmDlp6Rc elNQ==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AZuq6aLBfpouLKcZh9gDMus2EjFfrHeNikaFNV3dG0nafGgIWmjSMPP7rskjFfUtPb2 Qk6m4hRDPGg48QM8dyP+t/wPso0tReKOeZBJl7khHt3p/YBR6fokxpNkMuxsKGvQGpjUztqioqq EIbMQPHHvrVqE0tiZeWuqCdr64J9PUvvDPbnoYmvWqo1A7ssOwq3M3EJi14jJa82Dhg25Js+Ddx al206goCwtFz4dP6IaLdeDKEWHT4yoJg6XIbp+hiCoyJ5FryrDg36yT+ev4lmH/t8yNJDQxUjQW 4iigjAqah0EyyqC+O/Hio2VLs3Xy3VohE2j+VFX5M1jKhWrPBtYY0kKpx2vfP+yvA9LLEtoJ9x1 P6A== X-Received: by 2002:a17:907:c24:b0:b8f:7200:63bd with SMTP id a640c23a62f3a-b8fc3ca8153mr26870566b.42.1771011562086; Fri, 13 Feb 2026 11:39:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Fri, 13 Feb 2026 11:39:10 -0800 X-Gm-Features: AZwV_Qi8ToOcH4t5lVOxMPI6oU7ATU4Z1sPAr2H9BIdFdvr3zlqv-Suq8xkrWfw 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="0000000000000d2700064ab9c38b" X-Original-Sender: erik@q32.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b=qwLz8nPM; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::632 as permitted sender) smtp.mailfrom=earonesty@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.7 (/) --0000000000000d2700064ab9c38b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As a thought experiment, it's interesting, and I agree. One of the main complaints about covenants, for example, isn't that they aren't opt-in - they are, and most people understand that they don't enable special concessions more than multisig. Instead, it's because of the perception of Nth order effects around their usage in technologies like defi and contracts. We have all heard the headlines about evm hacks and defi hacks, and, to some extent, these steer "hard money" proponents toward Bitcoin more than any arguments around decentralization. However, "Q-day" may never arrive=E2=80=94and might just be a physics exper= iment that proves finite energy is real. What's more, FancySig1 was already proven insecure/broken. We are now on FancySig3. Cloudflare has decided to ship hybrid FancySig3/ECC, requiring both for all SSL. This approach would mitigate your concerns fully. You cannot use either option alone. You have to use both. Sure, it's annoying. But if we choose a sufficiently efficient FancySigN, we can build a system guaranteed to satisfy the risks of both the new system and the old one. In your extreme thought experiment, the only rational choice is "use both". On Fri, Feb 13, 2026 at 8: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/= CAJowKg%2B3pf801tggYf_S0rH4d%2BHr8mW7-oG-9dwckNX9tTB4%2Bg%40mail.gmail.com. --0000000000000d2700064ab9c38b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a thought experiment, it's interesting, and I agree= .=C2=A0 One of the main complaints about covenants, for example, isn't = that=C2=A0they aren't opt-in - they are, and most people understand tha= t they don't enable special concessions more than multisig.=C2=A0 Inste= ad, it's because of the perception of Nth order effects around their us= age in technologies like defi and contracts.=C2=A0 =C2=A0We have all heard = the headlines about evm hacks and defi hacks, and, to some extent, these st= eer "hard money" proponents toward Bitcoin more than any argument= s around decentralization.

However, "Q-day" may never arri= ve=E2=80=94and might just be a physics experiment that proves finite energy= is real.=C2=A0 What's more, FancySig1 was already proven insecure/brok= en.=C2=A0 We are now on FancySig3.=C2=A0=C2=A0

Cloudflare has decide= d to ship hybrid FancySig3/ECC, requiring both for all SSL.=C2=A0 This appr= oach would mitigate your concerns fully.=C2=A0 You cannot use either option= alone.=C2=A0 =C2=A0You have to use both.=C2=A0 =C2=A0Sure, it's annoyi= ng.=C2=A0 But if we choose a sufficiently efficient=C2=A0FancySigN, we can build a system guar= anteed to satisfy the risks of both the new system and the old one.

In your extreme thought experiment, the only rational choice is &quo= t;use both".


On Fri, Feb 13, 2026 at 8:23= =E2=80=AFAM Pieter Wuille <bit= coin-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.co= m/d/msgid/bitcoindev/CAJowKg%2B3pf801tggYf_S0rH4d%2BHr8mW7-oG-9dwckNX9tTB4%= 2Bg%40mail.gmail.com.
--0000000000000d2700064ab9c38b--