From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 17 Feb 2026 06:20:12 -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 1vsLvu-0005eh-Hd for bitcoindev@gnusha.org; Tue, 17 Feb 2026 06:20:12 -0800 Received: by mail-oa1-f59.google.com with SMTP id 586e51a60fabf-40ed978ce56sf37517083fac.1 for ; Tue, 17 Feb 2026 06:20:10 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; t=1771338004; cv=pass; d=google.com; s=arc-20240605; b=OyY0vIbv8DP7iCY/BsY2xk4Aaofl/hFX8O+RgGufxwTf0EVllJSrft1xXn79DCvbdx wRaUeiYmPsbUdAF9fUukzxDkhykWHIS8VlvEHqUseS3V6rPu4qZzBqitrATxAetqEb7g I6iggDjs7X/EHUh6nKPsIm50MjDAKfevFgNcxuBNYl/ItrIYqQNP0Ud+Iu7Fu4BjXKXx zaQd9DTaNQqHG9JxpnGNnjBkiZrrzUONIFh88BJXbNqDb2931InU/zIZmXo+nuz/vSxy npcY16pIF6ncQ8aDbMjxYf3fJEAqzDLT5KqgouWewqvS6yEbbQRiKKQUUneXhgfXnRuv jWkw== 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=E1X9oi5544JD4Mpa3PuLH6o2w4yZi6Q1JOUiq9ySR5Q=; fh=IFuIVLEtp+ku1ruUHXm2D4gu2LWYrje/0/mC3arEkms=; b=X8aQdHoBWvwEHSTVUNaE3SwK6YEAdbuNKE+Kgl857YisxbgO6RqpZVSZ5Z9wPvWAJx C1lJSLSqHiOrpVFPMwsuTg6oK3lFSEtd4Gmc1Nsl9WHLOJKFSCkqyhwJmaTVXaTNDoJy /5PjUajOqxY2681c1bgitmrtx1GmDE6FJPk+kkgH3k7pqLgZP153RH0gfmqGXS8itSDQ tXXc8MPwALqAj87jDqruE336MEcpFRpdAEVRDOsL6w9ob+yq8ulqIHTccRUcr4xRKJ/D apnd8rCPc0pmLaH4TrkHODZH2Yu+Sm/jKcsaikG0hdEXMkFT7Q14zNwagCv95yp1ipiz f2lg==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=U3bVYwux; arc=pass (i=1); spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=garlonicon@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=1771338004; x=1771942804; 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=E1X9oi5544JD4Mpa3PuLH6o2w4yZi6Q1JOUiq9ySR5Q=; b=L+h7cGIsh/ydghhc76xnrHMW9t0BhpcYt4+OfHvIC7N5jfoEqDIi84fZDFJCw18EYa bXxlvMgZus3ErNgiB72LtazCDRZRGiMPrMApjXOcLr7DDR99glfj02HTDBNx9HQUn9Jl qDQdrIEVWMajpne8S6860HqwYIHBnX5HP5OKhMeTQ4JgmqrcylIBXrPRUqzeRzSd/NvU dsen6NkLv6ag4b5ZU70m1Q/BKuiOgwry0BgSh0FR7GnBmrsikU8NTyqjYsKOIiO3mcSy he7c+HTWSfgb0OSeW0cvDwnmUImElBskCIgVovjY6SEs2BM3rknURnJnPeCMmQ1PirAZ JvQw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771338004; x=1771942804; 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=E1X9oi5544JD4Mpa3PuLH6o2w4yZi6Q1JOUiq9ySR5Q=; b=lloPnZORKPJIip1vQE3ci7/q748PIc2wWU+/GIkXHzMefzkuUJ8szpTvnZZyqCd7j5 TJu4LE3dSfGxaPBoTielbeHlNlvjUwqk1+9wVuVv0csjSvesZt6MrAnzHIHX3MZ6t0gV inDfjEmPd2jgnREGUVzHtT/jVWwmoqte9xeryrCtpZVc0UgE8dJ/twTaEMHqJbA42tXy CyEEA7cCD8JVbqowlLAMBV0PndCNVT4vIeFE16x0CpGhtZawfb4lhRdeG/wjB5jJKuK5 pGKHFMJul8cPsMKLwFdOcJBsQSY32HMw9huYgNiJg369wO9pv4Dn9ev8nX9I9zj81qna 5n+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771338004; x=1771942804; 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=E1X9oi5544JD4Mpa3PuLH6o2w4yZi6Q1JOUiq9ySR5Q=; b=wNl9CcOxjlY9ASfYhOwO7/MePCs2S8rOShezvC0uGqSzX+5xvzlZXcMWr6ME96RSYR OiNHrR4d74xol0dw+T9FIhxyJOYCXolF9H9vDcI4K7Rhf8UTkB21Ub/WeUF+uwHfQATc Wwu1NtwXKWmm8na8llsY6yCsFPyXOEs0Hn27jiVKcscjvyKLmgSE5dics1Df5GANw6Ph vBrgVsCgg+UxQ9PbLGPgd7EyYx16VzcXmcLD1Nzw0JoMeDIPMxHulThRJnu2fNFx5EQi 1Zv186VP09mF1aZO+qxTd6nudDxdTWINxsOc4y8en+EIgSgBvEMiJjmUVKXheFvRhuH9 qKgw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AJvYcCUAoRYn8l4CfyS75Rb/SCNsiNFaQfP4PQ7bBOhQiZVzUbkpfVJ/je987t4vQQ2noisQyb993ZDN5AwU@gnusha.org X-Gm-Message-State: AOJu0YzpgPkISuzfStXC7AWDXOeuxOrxTxG40m4R9RyXDqJZj7VdEGQ+ NkNQzibPIldLxB9Il4M6AlVRrsNcjug2lMAdJS1nGbZtswuOcWDa0VcX X-Received: by 2002:a05:6871:1c7:b0:40a:62f3:54a4 with SMTP id 586e51a60fabf-40ef3b364e8mr6323377fac.17.1771338004100; Tue, 17 Feb 2026 06:20:04 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AV1CL+E1rSoWh+CQDX8wGnZt+DQt42Cd6MRLH/ys7Wjl+3sEjQ==" Received: by 2002:a05:6870:1582:b0:3ff:9f0a:cf52 with SMTP id 586e51a60fabf-40eefe9b9e2ls3601215fac.2.-pod-prod-07-us; Tue, 17 Feb 2026 06:19:58 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUMqw9vDLJdaOKIzL6XvHKEw/1NtgrblXXA7PlYP8me3Xszvgcasj2/VTLrkhhl5EFKug9pPxhcP5sC@googlegroups.com X-Received: by 2002:a05:6808:6958:b0:45e:cbf6:31e3 with SMTP id 5614622812f47-4639f1dce8amr5117175b6e.42.1771337998633; Tue, 17 Feb 2026 06:19:58 -0800 (PST) Received: by 2002:a05:600d:644f:10b0:483:7fa7:460a with SMTP id 5b1f17b1804b1-4837fa74d66ms5e9; Tue, 17 Feb 2026 06:11:41 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWg2vMD6THF43uySU2kVb30txDSuWI4Ud//ccPhdJtRCJqGYpEUmiDfcsqEePLEaXCoGAcOHef55Bu8@googlegroups.com X-Received: by 2002:a05:600c:4e49:b0:477:54cd:200e with SMTP id 5b1f17b1804b1-48373a08300mr229402945e9.1.1771337499736; Tue, 17 Feb 2026 06:11:39 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1771337499; cv=pass; d=google.com; s=arc-20240605; b=lZjnYzL1VQNgqbUHJrDs2q34QOEvX3k0w+d8MRQbKzkzOxsepa+N9RfgUszVsril0l K21H1aUuA73ulQzJhMs8xmGXJVavyKh5QLs8d5H+CeG1Zf4ARdvd0LBAcuP5TS6Z5IK4 8mtyMt7PTdJ26DZxXgBhtCNDKyDbSTdQwkboCPCpYzbtZ5KHz8IMd+YpKLjTz+FfEGH8 jivoCFtuUz8wEfAr5YiBaTB7SsRmMI3VUTNs88kCBHwzmZrJjPwlH+hev2OrpPJXK0ER rFVgp5E1Zum99FXtpKcTw5RcwfYG8QnfWlt56cKUdo3MFguaSfQj3ew3LJulb7Ev7N5h t9Zg== 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=cSKDM3JlAjFLEAafa4ViTgEa2pHMYRHpQOEqBodOAok=; fh=3yxovUmp5P68Yseq2KrH50ist5sYEUrLSfsd6zahU+g=; b=lAW6CDCyHrvh2nEDDhkH2ikGpgysyhdxam/g98qIgnQkGFRG7DTguhzSWlaAsATTQ0 dq8wZkQ75dZUqmXelaLqwz6WB6O99/sHQV0I8Q/u7Z2HhNXdX0Ug8BTE3fMNeZxDlq2D LpeihrJWnPq3e0aeSIlP/dS9Q+KOVlj1QZTnXp5Yo0Dy0NxWaY/RZ7zWjG8K/+zoImmD RvJj5aN4EJau7vTmMQXSKze3oPAtLDLkufwchJh48QBAhnHn9VP4BCWQd39mCPwTrOvl /m+VDOJ5jZ5ZtlO/act69vsH2u2mQeFXxj7mI879D1QSOX7FxEXWf4rJ0/z39VBPcCwy ffiA==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=U3bVYwux; arc=pass (i=1); spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=garlonicon@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com. [2a00:1450:4864:20::534]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-483719f92a8si466965e9.2.2026.02.17.06.11.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 17 Feb 2026 06:11:39 -0800 (PST) Received-SPF: pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) client-ip=2a00:1450:4864:20::534; Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-65c5a7785b4so714349a12.1 for ; Tue, 17 Feb 2026 06:11:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771337499; cv=none; d=google.com; s=arc-20240605; b=eKnVtRwxEfjgzXL4rXS/3HSCpXFYeSdCmGnwjlZQY7ADEZFOsmdIx+fkuhBQn0JiT8 bEKpnycG3hAJ/iLzQ2HPLweaTbwNlo4PyUnpvfdn4LZwJMQufJk76PPCETGOiHxn7w55 kiLqRitgoU23LsL5CAT9TB+B3XxZIjGxhc7l156K9rKiqFKcgidrwlRE1Eps+lUrR6on uR7nauVfiKcOUNlY/c3GvZHPvAVqyAcwLY98j11LzSH1r63ebA8MRCERByr8GTsjcI4k AylddZSW5gboJNAx94bEYfT5NO7af67AO2fsct2YAJgGSNQoDMYb67TZhYNWm3IbID3A OuDg== 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=cSKDM3JlAjFLEAafa4ViTgEa2pHMYRHpQOEqBodOAok=; fh=3yxovUmp5P68Yseq2KrH50ist5sYEUrLSfsd6zahU+g=; b=dJ0BtuuLdhyeAxaRH0Ikio/RJck0IKsDMvug2mtRI6iwZK/QhUtX1ILj/qgQ88KS1t DP/CKztvfrgvQ886TTyoA0sV1A4VLlIOmx20fHHUiXhmFxpS9h2cxDG7g0cm0VZlWpVt rJMZR5FaYjcQcU9UfqWChFmZUkgjd58wx0w4KgHL/SetOnAkf/pXGAtQbml/SfJH9Mlv IYayEGCkj9RhMb5Iz7eGAAOIfF1yDjMRiwVOcHHuJHZCB8dwaoKuP4CmTEbDMv//mOWN y9GNzS8o4VEm2k0PhzIjVJx2YoDvvCXy22RWML6nCiclMFWrNr6lyGrP3tZl/qF+Mw3Z TC3A==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Forwarded-Encrypted: i=1; AJvYcCX1hr5/dVB22dQGyUcn3Bd1b5bNLcNauxdP6MAbzBswnhuvkLtqvb7ETwrTn5V1gK8Oa+rQ0DzC6Lar@googlegroups.com X-Gm-Gg: AZuq6aJ0+Sji5YPOdABYUsbuojrE86ae56HGpw2pehd/fxBdWNoEvvun+glWjIKW2k4 FdUQ/dtzzXIlEAn1VHyu4E2e6YPfvugn6qPti5cejqq9wtyzN0Wu6UwhTKv4AcUKnTCkOxXfUz+ Hm8LO6gKD1Zur/qB6P5tRRlG2xWtJOp59Mo7lNEfRi0GiIOLQNKCKQ3Yg5bYSN73ku0Z/38I4e0 ECwdW8b1Kgk2FXx+OLHxU0ys3OHcgglhYSrB9ByFGS+5/phj37uL7yGwpT1duFTbu96uENA9yvY e5joSw== X-Received: by 2002:a17:906:7946:b0:b8e:7d43:edd7 with SMTP id a640c23a62f3a-b8fb44a683amr800553366b.30.1771337498406; Tue, 17 Feb 2026 06:11:38 -0800 (PST) MIME-Version: 1.0 References: <088b5efd-7ba5-48f1-97f6-eb5881f5fd14@app.fastmail.com> <8692bba5-47d0-49f4-9b7f-ccb564cc3630@app.fastmail.com> In-Reply-To: <8692bba5-47d0-49f4-9b7f-ccb564cc3630@app.fastmail.com> From: Garlo Nicon Date: Tue, 17 Feb 2026 15:11:26 +0100 X-Gm-Features: AaiRm5129_xiQoPN9a2gEP_x2CcZSdl7jOSbjlRlfDMucqJLdW3I22V52hCTI3s Message-ID: Subject: Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin To: Light Cc: Antoine Poinsot , bitcoindev@googlegroups.com Content-Type: multipart/alternative; boundary="0000000000005eb2c9064b05a68f" X-Original-Sender: garlonicon@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=U3bVYwux; arc=pass (i=1); spf=pass (google.com: domain of garlonicon@gmail.com designates 2a00:1450:4864:20::534 as permitted sender) smtp.mailfrom=garlonicon@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.0 (/) --0000000000005eb2c9064b05a68f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Apparently the P2SH soft fork did freeze a total of 0.044 BTC If you mean 3Dnnf49MfH6yUntqY6SxPactLGP16mhTUq, then 0.04 BTC out of 0.05 BTCs is spendable. Because BIP-16 didn't confiscate old coins. For example: 0200000004c0017861860c77ec3a0b79252d7cd0b72d01857cc0ccb4e5defa55ea986163d00= 1000000030e0020fdffffff1afa06d85986741e13ea1a46f09af2ea99979d9a9beb6001476c= e14b2d9eb59a00000000030e0020fdffffff219a758936e67eeb55d888a932bdfe9bf0a1b84= e03d15c5d12c4f16120c98f6500000000030e0020fdffffffeedc66625b962c85acd2812e06= 663130d8a90a90c204a749e2095193445a0b5100000000030e0020fdffffff0118053d00000= 00000160014aca46e72322504d0b87bc0317b540fb70abf2f6700000000 Of course, it is non-standard, and even Slipstream wouldn't help you, because no miner would risk a block for 0.04 BTC (if you use 100% fees), and because many parsers will crash on "0e0020", and mark it as "invalid", even if pre-P2SH transactions are spendable in the old way. sob., 14 lut 2026 o 09:15 Light napisa=C5=82(a): > 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 > > 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 > soft 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 bro= ad > confidence in the security of bitcoin property rights remains intact, as > evidenced 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 > fork 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 activatio= n > client was published and shortly before the fork activated, and I could n= ot > find any record of alarms being raised at the time about the prospect of > freezing 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 > > (i largely share your > > concerns, but haven't yet formed an opinion of my own), i would like to > > 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 > bitcoin. > > > > That's quite the sweeping claim, but it's trivially incorrect, or it > > would make any soft fork > > impossible. This is both disproven historically, since Bitcoin made > > previously-valid redeem scripts > > invalid on at least 5 occasions (post Satoshi), and incompatible with > > many soft fork proposal, > > including your own. > > > > As long as soft forks are tolerated, a degree of nuance needs to be > > introduced to take into account > > reasonable expectations from users, and not disabling > > potentially-vulnerable EC opcodes as opposed > > to upgrade hooks needs to be defended on its own merit rather than > > appealing to the destruction of > > Bitcoin. (And to be clear i think a strong case can be made in this > > 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, > >> > >> > 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 > coins in an OP_TRUE", I believe your argument is incomplete because it is > missing a more realistic mass-theft vector, which is that as of today > approximately 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 priva= te > threat actors e.g. thefts from MtGox, Bitfinex, and scores of others, as > well as public threat actors e.g. EO 6102.[2][3] > >> > >> Despite this very real and large-scale theft risk, nobody is proposing > that we freeze coins held on exchanges. And yet some people find this > (freezing coins) to be a reasonable response to the risk of cryptographic > breaks (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 secur= e" > >> > 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 assumpti= on > >> > 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 eve= r > >> > move. Note that I am *not* arguing that "Bitcoin" *will*, *should*, = or > >> > even *can* do this, and I'm quite sure that the inherent confiscatio= n > >> > 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 bac= k > 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, a= nd > adopted by anyone who is concerned about this risk". Note that this > assumption does not, and cannot, preclude the possibility that other user= s > store their coins in insecure ways, even en masse (as shown empirically b= y > the above example of 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 bitcoi= n > 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, a= nd > >> > 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 withi= n > >> > the next year or two, voices (A) start appearing arguing that such a > >> > scheme should be adopted, because it's the silver bullet the ecosyst= em > >> > 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 brok= en 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 FancySi= g > >> > 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 assumptio= ns > >> > 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, whi= le > >> > 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 mov= e > >> > 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 secur= e" > >> > 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 assumpti= on > >> > 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 eve= r > >> > move. Note that I am *not* arguing that "Bitcoin" *will*, *should*, = or > >> > even *can* do this, and I'm quite sure that the inherent confiscatio= n > >> > 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, se= nd > >> > 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 > . > >> > > -- > 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/8692bba5-47d0-49f4-9b7f-ccb5= 64cc3630%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/= CAN7kyNi155H25NqGRg9NS_Yt6J5j9i3sRLBSULzkzJozYNz%3DEg%40mail.gmail.com. --0000000000005eb2c9064b05a68f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Apparently the P2SH soft fork did freeze a total of 0= .044 BTC

If you mean 3Dnnf49MfH6yUntqY6SxPactLGP16mhTUq, then 0.04 B= TC out of 0.05 BTCs is spendable. Because BIP-16 didn't confiscate old = coins. For example:

0200000004c0017861860c77ec3a0b79252d7cd0b72d0185= 7cc0ccb4e5defa55ea986163d001000000030e0020fdffffff1afa06d85986741e13ea1a46f= 09af2ea99979d9a9beb6001476ce14b2d9eb59a00000000030e0020fdffffff219a758936e6= 7eeb55d888a932bdfe9bf0a1b84e03d15c5d12c4f16120c98f6500000000030e0020fdfffff= feedc66625b962c85acd2812e06663130d8a90a90c204a749e2095193445a0b510000000003= 0e0020fdffffff0118053d0000000000160014aca46e72322504d0b87bc0317b540fb70abf2= f6700000000

Of course, it is non-standard, and even Slipstream would= n't help you, because no miner would risk a block for 0.04 BTC (if you = use 100% fees), and because many parsers will crash on "0e0020", = and mark it as "invalid", even if pre-P2SH transactions are spend= able in the old way.

sob., 14 lut 2026 o 09:15=C2=A0Li= ght <bitcoin-dev@lightco.in> napisa=C5=82(a):
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 > introduced to take into account reasonable expectations from users

I believe what I wrote accounts for this nuance. As far as I'm aware, n= o soft fork ever intentionally froze coins; on the contrary, my observation= has been that protocol developers are exceedingly cautious to avoid this s= ide effect.[1] It appears their efforts have not been in vain, since broad = confidence in the security of bitcoin property rights remains intact, as ev= idenced by the millions of people who continue to use bitcoin to store valu= e.

> 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 an= y soft fork 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 coin= s
> (i largely share your
> concerns, but haven't yet formed an opinion of my own), i would li= ke to
> 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 use= rs woke up one day no longer able to
>> assume that their redeem scripts would remain valid, then they wou= ld not be able to rely on
>> bitcoin to store value over time and the system would quickly coll= apse. Thus, any proposal to
>> disable features in a way that freezes coins is a proposal to dest= roy bitcoin.
>
> That's quite the sweeping claim, but it's trivially incorrect,= or it
> would make any soft fork
> impossible. This is both disproven historically, since Bitcoin made > previously-valid redeem scripts
> invalid on at least 5 occasions (post Satoshi), and incompatible with =
> many soft fork proposal,
> including your own.
>
> As long as soft forks are tolerated, a degree of nuance needs to be > introduced to take into account
> reasonable expectations from users, and not disabling
> potentially-vulnerable EC opcodes as opposed
> to upgrade hooks needs to be defended on its own merit rather than > appealing to the destruction of
> Bitcoin. (And to be clear i think a strong case can be made in this > 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 <bitcoin-dev@lightco.in> w= rote:
>
>> Hi Pieter,
>>
>> > A small note aside: you can argue that it is possible for peo= ple to
>> > store coins insecurely, like in an OP_TRUE script output, or = with
>> > private keys that are made public. I don't think this pos= sibility
>> > affects the point above, because it is not about what possibi= lities
>> > exist, but which approaches people are likely to / asked to a= dopt.
>> > Nobody is incentivized or encouraged to store coins in an OP_= TRUE.
>>
>> While it is true that "nobody is incentivized or encouraged t= o store coins in an OP_TRUE", I believe your argument is incomplete be= cause it is missing a more realistic mass-theft vector, which is that as of= today approximately 2.5 million BTC is held by less than two dozen central= ized custodians.[1] These coins are at a real risk of theft, due to both pr= ivate threat actors e.g. thefts from MtGox, Bitfinex, and scores of others,= as well as public threat actors e.g. EO 6102.[2][3]
>>
>> Despite this very real and large-scale theft risk, nobody is propo= sing 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 b= reaks (approximately 6.5 millions coins at risk).[4][5] Curious! But I digr= ess.
>>
>> > This brings us to the question then how at all Bitcoin users = can
>> > migrate to new cryptography, because we cannot assume that se= cp256k1
>> > will last forever. And I think the answer is essentially that= it
>> > requires the entire ecosystem to change their assumptions. Th= is 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 optio= n is
>> > changing the collective security assumption from "secp25= 6k1 is secure"
>> > to "secp256k1 AND FancySig are secure" once FancySi= g gets adopted at
>> > scale, and the discussion about adding new primitives should = be treated
>> > with the gravity that entails. And it means that disabling se= cp256k1 EC
>> > operations (or near-everyone migrating to FancySig, but I thi= nk that is
>> > unlikely) is the only way to change the collective security a= ssumption
>> > from "secp256k1 AND FancySig are secure" to "F= ancySig 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-re= levant
>> > 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 e= nd up being
>> > called Bitcoin, or it may be that this happens only after a C= RQC has
>> > been demonstrated to exist. Still, given a severe enough thre= at 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 assu= mption" is that "secp256k1 is secure". Everyone using bitcoi= n, 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 unco= nditionally secure. So I would rephrase the assumption to be that "sec= p256k1 is currently secure, and if it is ever at risk of being broken, ther= e is a large incentive for a viable alternative to be discovered, implement= ed, 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 empirical= ly by the above example of millions of coins held by centralized custodians= ).
>>
>> An alternative where "secp256k1 OR FancySig is secure" s= eems strictly preferable to me (assuming we have some reasonable degree of = confidence in the security of FancySig at the time of activation) than rely= ing only on "secp256k1 is secure".
>>
>> As an aside, I note that because it has been known since before bi= tcoin even launched that secp256k1 is vulnerable to a CRQC, we cannot rule = out the possibility that the people who leave their coins in CRQC-vulnerabl= e addresses -- even after QR addresses are made available -- aren't doi= ng so intentionally, as a kind of bounty for developing a CRQC. Freezing th= ese coins would violate their intentions. This is just one example of the e= thical 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 t= hat a UTXO was encumbered will always remain valid". This is fundament= al 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, the= n they would not be able to rely on bitcoin to store value over time and th= e 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 end= s up happening with vulnerable coins. Bitcoin cannot survive a violation of= the fundamental assumption that redeem scripts for existing UTXOs will alw= ays remain valid, and certainly not a violation at the scale that you descr= ibe.
>>
>> Regards,
>> Light
>>
>> [1] https://www.coinglass.com/Balance
>> [2] https://bitcointalk.org/index.php?to= pic=3D5090869.0
>> [3] https://en.wikipedia.org/wiki/Executi= ve_Order_6102
>> [4] https://github.com/bitcoin/bips/pull/1895<= br> >> [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/bitcoindev/c/7jkVS1K9WLo> 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 consi= deration, and
>> > is not intended as an argument against (or for) any particula= r proposal
>> > today.
>> >
>> > The idea is giving users/wallets the ability to choose the >> > cryptographic primitives used to protect their own coins, fro= m 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 oth= ers' coins
>> > lose value, for example due to fears about them becoming vuln= erable 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 al= l 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 tha= t 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 ma= y find
>> > themselves in a fundamental disagreement:
>> >
>> >=C2=A0 =E2=80=A2 Camp (A), fearing an EC-break (CRQC or otherw= ise), wouldn't just
>> > want FancySig as an option - they would want (feasible or not= ) that
>> > *near-everyone migrates to it*, because the prospect of milli= ons of BTC
>> > in EC-vulnerable coins threatens their own hodling.
>> >=C2=A0 =E2=80=A2 Camp (B), fearing the possibility that FancyS= ig gets broken soon,
>> > possibly even classically
>> > <https://www.quantamagazine.org/post-quantum-cryptography-sche= me-is-cracked-on-a-laptop-20220824/>,
>> > don't want to just not use FancySig; they would want *nea= r-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 div= ergence
>> > between camps may be much less incompatible, but I still thin= k it's a
>> > good demonstration of the fact that *despite being a currency= for
>> > enemies, Bitcoin essentially requires users to share trust as= sumptions
>> > in the cryptography, and its technology in general*.
>> >
>> > A small note aside: you can argue that it is possible for peo= ple to
>> > store coins insecurely, like in an OP_TRUE script output, or = with
>> > private keys that are made public. I don't think this pos= sibility
>> > affects the point above, because it is not about what possibi= lities
>> > exist, but which approaches people are likely to / asked to a= dopt.
>> > Nobody is incentivized or encouraged to store coins in an OP_= TRUE.
>> >
>> > It is also good to ask what amounts are relevant here, to whi= ch I do
>> > not know the answer. Possibly, the prospect of 100k BTC becom= ing
>> > 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 differe= nt
>> > conclusions. Still, to me it is clear that *some* threshold e= xists
>> > above which I would be uncomfortable with seeing that many co= ins move
>> > into an untrustworthy scheme, even if they are not my own coi= ns.
>> >
>> > This brings us to the question then how at all Bitcoin users = can
>> > migrate to new cryptography, because we cannot assume that se= cp256k1
>> > will last forever. And I think the answer is essentially that= it
>> > requires the entire ecosystem to change their assumptions. Th= is 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 optio= n is
>> > changing the collective security assumption from "secp25= 6k1 is secure"
>> > to "secp256k1 AND FancySig are secure" once FancySi= g gets adopted at
>> > scale, and the discussion about adding new primitives should = be treated
>> > with the gravity that entails. And it means that disabling se= cp256k1 EC
>> > operations (or near-everyone migrating to FancySig, but I thi= nk that is
>> > unlikely) is the only way to change the collective security a= ssumption
>> > from "secp256k1 AND FancySig are secure" to "F= ancySig 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-re= levant
>> > 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 e= nd up being
>> > called Bitcoin, or it may be that this happens only after a C= RQC has
>> > been demonstrated to exist. Still, given a severe enough thre= at 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 G= oogle
>> > 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 &= lt;mailto:bitcoindev%2Bunsubscribe@googlegroups.com>.
>> > To view this discussion visit
>> > https://groups.google.com/d/msgid/bitcoindev/THqOJuI_s5C8B9jkklN73BB= _Hzb9SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh8NxxYbXwv4v6ikpStguW-QEvef4WgBZ7AQDz00= P0st91FMA%3D%40wuille.net
>> > <https://groups.google= .com/d/msgid/bitcoindev/THqOJuI_s5C8B9jkklN73BB_Hzb9SsiLM6BFp4zFP3zWQoRevKo= LVspdwjwh8NxxYbXwv4v6ikpStguW-QEvef4WgBZ7AQDz00P0st91FMA%3D%40wuille.net?ut= m_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/bi= tcoindev/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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 8692bba5-47d0-49f4-9b7f-ccb564cc3630%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/CAN7kyNi155H25NqGRg9NS_Yt6J5j9i3sRLBSULzkzJozYNz%3DEg%40ma= il.gmail.com.
--0000000000005eb2c9064b05a68f--