From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 14 Feb 2026 00:15:14 -0800 Received: from mail-oo1-f55.google.com ([209.85.161.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vrAo5-0003nX-8g for bitcoindev@gnusha.org; Sat, 14 Feb 2026 00:15:14 -0800 Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-67792d46a05sf10934483eaf.1 for ; Sat, 14 Feb 2026 00:15:12 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771056907; cv=pass; d=google.com; s=arc-20240605; b=W57NQbrOJ2Ljy5pVp84db1GRAXwLoDC32PzOiCOo3vaUCCN7sNDeM4dleEFU9TWK7A Ciud3rb+U+Lv1W/X49Z9F+FfnJoagy51B9JsK+fn9sMEwS+EIMtZSySaP9lr5f5FesKG Q6eamjaUT+MJ7DZo8flasulmuphSFGESq1gV7B2kMa9R7Fs9eiFjc35wEuEFbymJAsaM QTfOPlt3mw7RSvwzvdqXzz+WA6cqoJ5Za/FG2PfVMtkXCptD0u9OSyNi63nMNdurp+tH 5/X6Yl5Mob9Qa7pVpvUGAncPwNPuiUPhSndTY8Njk244cRUaqEhqmR0N0PQsxy5Ia4Vx IsXw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:content-transfer-encoding:subject :references:in-reply-to:message-id:cc:to:from:date:mime-version :feedback-id:sender:dkim-signature; bh=HYt/dFSGTIWllL7L8jUAZlkTVhTNqqr+5f2p04CNZMU=; fh=iM3fJ+76q+zxz/iH/bO/kjfKSB3dpniMRYQkm/Rfob4=; b=ftI5g9MwImw81+cM9qq3HgSZTEq0aummSGWSlG7oyuwkh8n0g9OHhRxwAELJppnnxZ EegR//QJnpEb+4gRgq0jzYEOuvxHY3IlTO0XWjUj1NB/ejVlsNbIojPIIVgbqdOKbJ72 LwbMmPFhCXO8uV2A9o75yhn8Wztza0zahqiaYv3BPpiKAQg+i+gEmlmGIxFGv/JF4kja 3J2IhCPfSMpNRALHMf/8252GizGuMJXVl2fVxp6DMzMEWKLwPr35RPf0FGmh7gqXxxFi iJZ17currJUG1j7Q47WEsb0NP4mifbNuRB95e2guaBDWrsD/sk5VOVujznG60Igb5/NP XDAg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@lightco.in header.s=fm2 header.b=h7wfTORz; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=DXRiiavp; spf=pass (google.com: domain of bitcoin-dev@lightco.in designates 103.168.172.159 as permitted sender) smtp.mailfrom=bitcoin-dev@lightco.in DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1771056907; x=1771661707; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:subject:references :in-reply-to:message-id:cc:to:from:date:mime-version:feedback-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=HYt/dFSGTIWllL7L8jUAZlkTVhTNqqr+5f2p04CNZMU=; b=uBU2ZYKOCg8nFa0Ypyn5aF+xtAAtEyUzOa/NwvRIvjt8bXAUxBnr73roNqX0qfegbR JB7ycvmbeUlEOR17hsfgvzjaErCYsprjiypFTRewwTjZmfRMtIDFQUiU/bAmTLSu7awU CZKSR6jv5YowZ4kJeOK49zO8gApPbyDEwZo7+deENg377gENkfeUEyltp4MEc0eVdKo9 6CCUOMHfriQde4XKu1X18uPfJBUOe1yNz5xLkp4lD7lic+6FqEMn8H3xfXNuVKCCkb2o HfHku3ZNXnsmOUuAC2q5rlv1DSM9YJfC39kXElnN2u38nG60IifxNRGpguBOiWnJjdWN 7hpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771056907; x=1771661707; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:subject:references :in-reply-to:message-id:cc:to:from:date:mime-version:feedback-id :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=HYt/dFSGTIWllL7L8jUAZlkTVhTNqqr+5f2p04CNZMU=; b=uu/B1zThQFQnjA8iraFzQUJNvUgYQPoQh4S0ubHshTr0D07RQTo7GrSh/sRssCnE/P wwXn0H9vrlpHGyM1TehBn25k8/Y99KDScRxe2/RVSHM/1F/6koXGw9fN84HtWDhKY1Dn l9r6sE2BGk9MXu1ojFTxeEYV92d7n94wxdEZ7XDqHH0Gg3a4re3NJKH2GdyiRRi6eYza nQ/j2ZKlj6HrRw1+34NkUpJY//Ryb7c4E6RMoqo0alBz+S4u5C2PUbFpPSnScXRP0e2v 3k8+A2eX25ufZZwilkW+X7p4f54PJXv/EHU4pe6GV1ht1PI19G/S2HC8d1xueQQnPhTr i0Rw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUaY+ym3U7wc8ZwmwLo6f0B6B9A4rT+ZoRsDQEC4XbuFAVPmoV+RRNemLumdvKpI2StOjSghrZexA/J@gnusha.org X-Gm-Message-State: AOJu0YxyWv8PJLlsUX/ihgTOAuB8uRcyH0J0kzLi9Cdy8PfE8Ve5FJWK xzcE0g46gjbeSgKx09UycpwUeSyYrdn/RiP7aGrcF4vECMmCici79Fap X-Received: by 2002:a4a:ee84:0:b0:663:dda:af96 with SMTP id 006d021491bc7-677674834e0mr1954559eaf.20.1771056906926; Sat, 14 Feb 2026 00:15:06 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+Ej9S3PAJvmRZSpWZkFmMN6il6xPGUF2s9v9IxOcSBKWg==" Received: by 2002:a05:6820:221a:b0:662:f8b5:76cb with SMTP id 006d021491bc7-676a4677f96ls1405146eaf.1.-pod-prod-08-us; Sat, 14 Feb 2026 00:15:02 -0800 (PST) X-Received: by 2002:a05:6808:4f2b:b0:45e:f926:4628 with SMTP id 5614622812f47-4639f220c4cmr2369560b6e.52.1771056902380; Sat, 14 Feb 2026 00:15:02 -0800 (PST) Received: by 2002:a05:6808:b2b:b0:44f:fe66:38a2 with SMTP id 5614622812f47-46395e57794msb6e; Fri, 13 Feb 2026 19:43:35 -0800 (PST) X-Received: by 2002:a05:6a00:21d3:b0:823:b6b:4859 with SMTP id d2e1a72fcca58-824c95e9f54mr3815689b3a.49.1771040614101; Fri, 13 Feb 2026 19:43:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771040614; cv=none; d=google.com; s=arc-20240605; b=eXnbPJsOsp81t3TnpDnPAMCnS7n7gprF0CoK5HLez1r8LbsBLbhj46Rf3hzbfnNb6v 3EPnr6UHtcQSM8mF3+WrLvReMS9hInLWbtnrAphhi1quwlaHowMAcJAYcc4yJmsH/VRT 0tpf7MNP0ovAcHZPxaUzO/nLm4ADr74IVEJ4THFbz+Pv6W+O5GVma2yC7gxcqR4oKlXJ /kE3Uz3vwavHI3PkuNtQsRHOzsVqgebygtYvKjdrwmn/9yWaiC1AJJ+Xv2WNH20ery9S gxvKfkAobOGK0lBcDHx6dUPCmKTNiC2CI2RsQDn8cH2orTo5eF2hMSy3LARVRbIF5+CZ jgkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:subject:references:in-reply-to:message-id :cc:to:from:date:mime-version:feedback-id:dkim-signature :dkim-signature; bh=4GUJiTeMyYr8ssYgOMRApTKtDrXfNDKMRZcTvh+sDbw=; fh=Knw0epVO236wKdH0z+TH/8zYgf0DgSZWAAYdGWdVQZo=; b=QY4SaJ6Qkaou/WhpRdiXuAlykdU4hLv1OBA6IV69rplhxxV+YIyy+6QzGsrQEdKtD2 vZUX/Ruqew9ZRHFGO9mqHrrkgJO54ZPRnhrZP01UbrP9ftALydbDB9ktGcLyJwo/qOx+ sia97XeJP+CGgkAYiMY4PQqCTULYEEW7sy64bY35NM1oyo0RY+eSgDpuuyon5srlqlVA Qy9SHLQmxgVI4uOy7XwLMrZy0vWmeHU7nxyOA56jXXXoxNwSHWK1fLN4QTlUeAY/hKJ8 TLLC4xkDkTNuUeG+AjtoidTMtRhKN9/qkjrAnapGuIbP6xOzYIPWCm2fHLSADeC5q/Ir /fvA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@lightco.in header.s=fm2 header.b=h7wfTORz; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=DXRiiavp; spf=pass (google.com: domain of bitcoin-dev@lightco.in designates 103.168.172.159 as permitted sender) smtp.mailfrom=bitcoin-dev@lightco.in Received: from fhigh-a8-smtp.messagingengine.com (fhigh-a8-smtp.messagingengine.com. [103.168.172.159]) by gmr-mx.google.com with ESMTPS id d2e1a72fcca58-824c6a2e4d5si126332b3a.2.2026.02.13.19.43.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Feb 2026 19:43:33 -0800 (PST) Received-SPF: pass (google.com: domain of bitcoin-dev@lightco.in designates 103.168.172.159 as permitted sender) client-ip=103.168.172.159; Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfhigh.phl.internal (Postfix) with ESMTP id 43F7E140010F; Fri, 13 Feb 2026 22:43:33 -0500 (EST) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-04.internal (MEProxy); Fri, 13 Feb 2026 22:43:33 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvuddttdekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucgoufhushhpvggtthffohhmrghinhculdegledmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtqhertdertdejnecuhfhrohhmpefnihhghhht uceosghithgtohhinhdquggvvheslhhighhhthgtohdrihhnqeenucggtffrrghtthgvrh hnpefgfeeiffffieetffevkeetgeehieejveetvdfhteeifeelfeffudeiveeiuedtjeen ucffohhmrghinhepshhtrggtkhgvgigthhgrnhhgvgdrtghomhdptghoihhnghhlrghssh drtghomhdpsghithgtohhinhhtrghlkhdrohhrghdpfihikhhiphgvughirgdrohhrghdp ghhithhhuhgsrdgtohhmpdihohhuthhurdgsvgdpghhoohhglhgvrdgtohhmpdhquhgrnh htrghmrghgrgiiihhnvgdrohhrghdpfihuihhllhgvrdhnvghtnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghithgtohhinhdquggvvheslh highhhthgtohdrihhnpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdp rhgtphhtthhopegsihhttghoihhnuggvvhesghhoohhglhgvghhrohhuphhsrdgtohhmpd hrtghpthhtohepuggrrhhoshhiohhrsehprhhothhonhhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: ic4c14615:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 13E17780075; Fri, 13 Feb 2026 22:43:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 X-ThreadId: AMpRsVj2rCRZ Date: Fri, 13 Feb 2026 22:43:12 -0500 From: Light To: "Antoine Poinsot" Cc: bitcoindev@googlegroups.com Message-Id: <8692bba5-47d0-49f4-9b7f-ccb564cc3630@app.fastmail.com> In-Reply-To: References: <088b5efd-7ba5-48f1-97f6-eb5881f5fd14@app.fastmail.com> Subject: Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: bitcoin-dev@lightco.in X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@lightco.in header.s=fm2 header.b=h7wfTORz; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=DXRiiavp; spf=pass (google.com: domain of bitcoin-dev@lightco.in designates 103.168.172.159 as permitted sender) smtp.mailfrom=bitcoin-dev@lightco.in Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.8 (/) Hi Antoine, > it would make any soft fork impossible. This is probably tangential to the topic of the thread, but since you bring= up the confiscatory potential of soft forks in general I will go ahead and= plant my flag here by saying that if given the choice between doing a soft= fork but with a high likelihood of freezing coins, or doing a hard fork to= avoid freezing coins, I would pick the hard fork every time. > As long as soft forks are tolerated, a degree of nuance needs to be=20 > introduced to take into account reasonable expectations from users I believe what I wrote accounts for this nuance. As far as I'm aware, no so= ft fork ever intentionally froze coins; on the contrary, my observation has= been that protocol developers are exceedingly cautious to avoid this side = effect.[1] It appears their efforts have not been in vain, since broad conf= idence in the security of bitcoin property rights remains intact, as eviden= ced by the millions of people who continue to use bitcoin to store value. > and incompatible with many soft fork proposal, including your own. I'm not sure what you're referencing here; I am not an author of any soft f= ork proposals. [1] Apparently the P2SH soft fork did freeze a total of 0.044 BTC: https://= bitcoin.stackexchange.com/a/115804 This seems unintentional since the coins were created after the activation = client was published and shortly before the fork activated, and I could not= find any record of alarms being raised at the time about the prospect of f= reezing these coins. On Fri, Feb 13, 2026, at 5:52 PM, Antoine Poinsot wrote: > Hi John, > > Without commenting on the (un)desirability of freezing vulnerable coins= =20 > (i largely share your > concerns, but haven't yet formed an opinion of my own), i would like to= =20 > surface one issue in part of > your reasoning. > > You state: >> 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 bi= tcoin. > > That's quite the sweeping claim, but it's trivially incorrect, or it=20 > would make any soft fork > impossible. This is both disproven historically, since Bitcoin made=20 > previously-valid redeem scripts > invalid on at least 5 occasions (post Satoshi), and incompatible with=20 > many soft fork proposal, > including your own. > > As long as soft forks are tolerated, a degree of nuance needs to be=20 > introduced to take into account > reasonable expectations from users, and not disabling=20 > potentially-vulnerable EC opcodes as opposed > to upgrade hooks needs to be defended on its own merit rather than=20 > appealing to the destruction of > Bitcoin. (And to be clear i think a strong case can be made in this=20 > regard, this is not to be > interpreted as an argument in favour of The Big Freeze.) > > Best, > Antoine > > > On Friday, February 13th, 2026 at 5:13 PM, Light = wrote: > >> Hi Pieter, >>=20 >> > A small note aside: you can argue that it is possible for people to >> > store coins insecurely, like in an OP_TRUE script output, or with >> > private keys 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. >>=20 >> While it is true that "nobody is incentivized or encouraged to store coi= ns in an OP_TRUE", I believe your argument is incomplete because it is miss= ing a more realistic mass-theft vector, which is that as of today approxima= tely 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 act= ors e.g. thefts from MtGox, Bitfinex, and scores of others, as well as publ= ic threat actors e.g. EO 6102.[2][3] >>=20 >> Despite this very real and large-scale theft risk, nobody is proposing t= hat we freeze coins held on exchanges. And yet some people find this (freez= ing 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. >>=20 >> > This brings us to the question then how at all Bitcoin users can >> > migrate to new cryptography, because we cannot assume that secp256k1 >> > will last 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 infeasibl= e >> > 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 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 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 b= e >> > 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 thin= k >> > 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 worthles= s >> > anyway. >>=20 >> I don't believe the predominant "collective security assumption" is that= "secp256k1 is secure". Everyone using bitcoin, going all the way back to t= he genesis block, has known (or should know) that secp256k1 is vulnerable t= o 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 co= ncerned about this risk". Note that this assumption does not, and cannot, p= reclude the possibility that other users store their coins in insecure ways= , even en masse (as shown empirically by the above example of millions of c= oins held by centralized custodians). >>=20 >> An alternative where "secp256k1 OR FancySig is secure" seems strictly pr= eferable to me (assuming we have some reasonable degree of confidence in th= e security of FancySig at the time of activation) than relying only on "sec= p256k1 is secure". >>=20 >> 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 th= e possibility that the people who leave their coins in CRQC-vulnerable addr= esses -- even after QR addresses are made available -- aren't doing so inte= ntionally, as a kind of bounty for developing a CRQC. Freezing these coins = would violate their intentions. This is just one example of the ethical pro= blems associated with such proposals. >>=20 >> 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 encumb= ered 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 re= ly on bitcoin to store value over time and the system would quickly collaps= e. Thus, any proposal to disable features in a way that freezes coins is a = proposal to destroy bitcoin. >>=20 >> Bitcoin can survive a temporary price dump, if that's what ends up happe= ning with vulnerable coins. Bitcoin cannot survive a violation of the funda= mental assumption that redeem scripts for existing UTXOs will always remain= valid, and certainly not a violation at the scale that you describe. >>=20 >> Regards, >> Light >>=20 >> [1] https://www.coinglass.com/Balance >> [2] https://bitcointalk.org/index.php?topic=3D5090869.0 >> [3] https://en.wikipedia.org/wiki/Executive_Order_6102 >> [4] https://github.com/bitcoin/bips/pull/1895 >> [5] https://youtu.be/a_B8BnwagEU&t=3D150 >>=20 >> On Fri, Feb 13, 2026, at 11:20 AM, Pieter Wuille wrote: >> > Hi all, >> > >> > A thread was >> > 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 >> > how important it is what *others do with their coins*. If others' coin= s >> > 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 BT= C >> > in EC-vulnerable coins threatens their own hodling. >> > =E2=80=A2 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 >> > 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 infeasibl= e >> > 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 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 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 b= e >> > 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 thin= k >> > 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 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 . >> > To view this discussion visit >> > https://groups.google.com/d/msgid/bitcoindev/THqOJuI_s5C8B9jkklN73BB_H= zb9SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh8NxxYbXwv4v6ikpStguW-QEvef4WgBZ7AQDz00P0= st91FMA%3D%40wuille.net >> > . >>=20 >> -- >> You received this message because you are subscribed to the Google Group= s "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/088b5efd-7ba5-48f1-97f6-eb5881f5fd14%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/= 8692bba5-47d0-49f4-9b7f-ccb564cc3630%40app.fastmail.com.