From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 14 Apr 2026 15:17:12 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wCm4F-0007gb-QR for bitcoindev@gnusha.org; Tue, 14 Apr 2026 15:17:12 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-4230d3a66b9sf11631236fac.1 for ; Tue, 14 Apr 2026 15:17:11 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1776205025; cv=pass; d=google.com; s=arc-20240605; b=HI3dAAkhUGmpAGWYZWIbl672RJqRjyb5nxbir7ctLcoDSo9b9rlRhVr8cpuw7jK2uK c3sp8JDrTMTpSBcidbNXBw5MqytrvuRSZJQD3kEDmAwr1zsAO1hAtAOMa7tYyJdgAG4g Ta0NMV06N+CqnmV8YRqNB+5Ubl5sFMVF5e7FkrcSqhnN5lhjndalYDAPfNnCStv0PnpJ SvlrP2wm4r9C7VNVrJ5bqZTQMhCO8QlVGA9d28U5m7hNTHgYnP7LFwi7Sg9r606VFKOV wIHQEsuFNS17xaiLQKnC4lG83w1aH57VmBr2rBXbM1ISl+98OcFPoiB0hMOZ4cT3nV/l XHEA== 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=EQcAY17KI8geOsrqzDEWBCrvzFywnwvzcPiRIuR/MxA=; fh=IPiQ38e22dQHnISp7X1UCoHPm9xfIeTzZoPophjOtn4=; b=V+Qo6+L6Fcgii2axHKUZnFnWk/0fZ1buR74qkakunOccZx8Jg8Gh+KCGNNJhvQQP5A +F/4+C6GmsOL0Cvm3OFifpEi/jPninVC29SItIAtrgTgpdlBsQi0onPSOJ59uq/w2EiN 5B7LC53fb3KuNLWtA30HxpNGwd2OFqifNB3nZiuIq384SomJ/Vr7X2zssCJAilsphV5N H2/YVC1vGP2hvdDBHuQCYpdtO6minhrcY0dLWrr3EdYYDrH3Ee6Y6MuUOQ07xb+TzKvA jBj65oCBMQG7txf4nqPJLGucDHz3hC/pIPQwRgJT/CsY0kgkdSVAA0TU4gDIAvvZB+AK 86Xw==; darn=gnusha.org ARC-Authentication-Results: i=3; gmr-mx.google.com; dkim=pass header.i=@q32-com.20251104.gappssmtp.com header.s=20251104 header.b=03GhALzg; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::634 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=20251104; t=1776205025; x=1776809825; 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=EQcAY17KI8geOsrqzDEWBCrvzFywnwvzcPiRIuR/MxA=; b=HKceKLwYRbklgFchzfME6T5u7bOoqHznOeyi4XrR1Em3E0z2cqwdjqPYn/pnWR37eE fOt+EezHcULjUxLqKQO9twOwDtDe5yxVMUHlxDpY2PClOI0w1v2XnmUiHhlvx7O1RNpK KUyWxx3D346JRMhMXgpv16tjR1/nzSmS4fw2Stk3DSILlFKeyK4dQgMcZutiYhobvWwx 0zrmScELm7vEfNsE4FZ63YJMcAedEeMVO2qCRCwIokQ7CO64VI6NcpSuBw1axOhGr3ZR CeHboS/XBzxgdxh/a8rbfcrmUWilhO0BfuKJ2Wc/pv1HpRt+TjxhE5iwFk9D/Bg4ebMw mBvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776205025; x=1776809825; 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=EQcAY17KI8geOsrqzDEWBCrvzFywnwvzcPiRIuR/MxA=; b=KqCrV2DVgaiSn3l4X5arbJflVCL88El8pPS8fO25PsMC8EJ0JAU7MsQTWEMkCKASYN WZ/tZd64dK6fwx0ohbv7Ml+6HWnPPVnlk+JaQYq6+643xmPy8LOApVJe6bLugozrRSw8 vgtKnooi9EHEsYIiFsDmDD6uRYJy/BY9Wao7r/s6Qqq/+5n7Bx8/23WQrcbrZHTfRsGV S33pdd7+/WCmask8fl1EsI5HZ/A8n0zKibOaAvlW9/fK/v/r0a1+Ldlc7U9UK1YMSJi+ F8m2CtX0CzZmzxOP0FhPQc8kjoQTgJH00X5n3pDWgZd6OOwNALzbO1bPpiuDekQSCdO9 wkVA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ/V/UpeXe8Q24lVVEJKCe9rldXVVrCQb+Aq3MkoR2kxtOMxEePvWCEaOqKbmdwpsYGJd4NqB6yxaFRW@gnusha.org X-Gm-Message-State: AOJu0Yz9vDZo2oI4Sl8jJ4gQ3w2SWWb7kZL+MfrYANjyKCRYKEOBAGSZ cbpxIgvDvfxcj4Sp7jteokQO0zik0erByGRZssoWXjmtpeAfgft1DjKW X-Received: by 2002:a05:6871:709:b0:423:f59:31f4 with SMTP id 586e51a60fabf-423e0e19684mr11190720fac.11.1776205025293; Tue, 14 Apr 2026 15:17:05 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiI+8Nf8nLGV4hI73xx7bFL+DGq7B+Wwj0Y/MNkLGwGsoQ==" Received: by 2002:a05:6870:5d8d:b0:41c:592a:81e9 with SMTP id 586e51a60fabf-423dd005acals2609563fac.0.-pod-prod-01-us; Tue, 14 Apr 2026 15:17:00 -0700 (PDT) X-Received: by 2002:a05:6808:528e:b0:467:f9ff:7c54 with SMTP id 5614622812f47-4789f906ef6mr10355172b6e.45.1776205020707; Tue, 14 Apr 2026 15:17:00 -0700 (PDT) Received: by 2002:a05:600c:2288:b0:485:53e3:ec5e with SMTP id 5b1f17b1804b1-488f0766957ms5e9; Tue, 14 Apr 2026 15:00:07 -0700 (PDT) X-Received: by 2002:a5d:5f44:0:b0:439:ca9b:1f61 with SMTP id ffacd0b85a97d-43d6428a2a2mr26971937f8f.17.1776204005461; Tue, 14 Apr 2026 15:00:05 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776204005; cv=pass; d=google.com; s=arc-20240605; b=aEx3Muy9MiPPi9LJaxSCZMxFfbN49ALIRhT8djr/Y3TDZJVO0LZVKgpQ6VDxQWILmU OEkHRaYUB56urzsfgMyzc7B3Sur1NlvkB3zFt7XTZCfVDSdeO1aBcHTAKESuN3yLyRSu y9BXiYhSS4atwXWRj6zReR7rh7zoyt5pfKvJY8Q1VN9bUJSVUwybysZj8aiNtLdfjOKI qfeeYQyRc9lpfR1/4jM9Ns0mZBEKJpkVWdQIWSTyjA35ZXhN1XSE19Gg8Vvo0i/PUMAS KOSrc6joq1GpGZ7awBvv1TjVYYmPi3p66Ig25p05i8LzetbBbqaqHVQR14H04sdDv+jc C5fw== 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=uCztG9V6vWbCDY6VnS9AcAkH+WSOUSNbj2fKHNz2MuU=; fh=AraWG4EtKgnVZC3vx0kKXPCQKgjblcoyQOn27ZV865o=; b=dfM8/SdCjMcdn8E1firb8FngRSDi+MCbbsqabkqJAKx1iu4msQVWmCDgSRz8B5MSoN 9J2GXWzNWb638/71njYtQ3Q/j4eOcqmclREl9H9rSdOYg12gyJWcnBMTyotflWAFSsA+ b/YJCK4tNJaERQgj4W7V5qXd9slUvBspvJ+r11eqoZlYvSa0KnT1Uv5QykGCadZE72LX AqEXKE2nnr7T/UcboR9MyAANObJJUrw8K/138qdYIm7rhSMrxuGus1oG/5Q7McvftaGp vvId5BvpSNOTdpGuw5cnu8oHknT0hHjGAVB+6VoFAYE/b2Zo3d0FFb9pUj/aTxBdLwkg nlGw==; dara=google.com ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@q32-com.20251104.gappssmtp.com header.s=20251104 header.b=03GhALzg; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com. [2a00:1450:4864:20::634]) by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-43d63e17534si269298f8f.1.2026.04.14.15.00.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Apr 2026 15:00:05 -0700 (PDT) Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) client-ip=2a00:1450:4864:20::634; Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-b9d6c8871c7so908571666b.1 for ; Tue, 14 Apr 2026 15:00:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776204005; cv=none; d=google.com; s=arc-20240605; b=RkGvdnMak2o3y7crf4k08wqFma6qEiGLR4rqoCzS0gBVRPlx3hXEB+2xKFIHdyR2/A rXzREE8k1PjQmwy0F2HMDrTiyUPCpfgfCsjUCXBVHhHYNUdN2N/zm6x0OLrNFOLu8y49 jQXK3w0Z9dCEgZHXHRn8E2a4U2erRuY9gqph6Hrp2XZbW1bBQt3qOSPimQ5gTrWUt6v/ dYJse8jmBoj3Q07eZK4Q0CpwdSiDnomj8Xipeb5hrxg2AKBFr/u+P9ROU/D125I3oiUE iUfFuJ7qEHKhvhjAsc4pv/Qy77LNi+W9RJSPU4HCo6Ijvfv/jEm7HYd91mP7cb4JaWY6 nvKA== 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=uCztG9V6vWbCDY6VnS9AcAkH+WSOUSNbj2fKHNz2MuU=; fh=AraWG4EtKgnVZC3vx0kKXPCQKgjblcoyQOn27ZV865o=; b=hz5MZkUmaFqHQKmPTbm1P0a+SjiIogg7sNeePoU06FQyE7RT4+2fPupLIg6DSaHYBz yy+8W8z8oYpX2J/kbeIwD1MI2BSirZc5MrIk5G6cJBJeCq5NL3m+3e3JG9ux1bTbatcy I1DwcEOwqHcOwAAYZwt59G5Cj2yDzG7CA5bx5GwGOmJaUqdTG6KnTYJWPtUMM2KIf/Rp RDGM6El3ivCmVGMz/ZnT+C8VKSbuG7czjirtQScRS41tH130+UxdHISa3mrvFLeI7Ih/ UtTDVKxXVAdd62A0lJgDQBboUcAiVqllcOV8cbVkPUWGyleUhuDrCnagvbeYYjNfkOUl qYzw==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AeBDievIWnMzDzIn9CUBsoKRLGik0jEzxGF4rkHAsuPYjPRSRv/onVM40fQbgUbCCt3 F35YkA8DyM8BMWNMXdF3CEa1/3atkkpl3QlsROvrvz2l4u0gd2fO2yYWKjxBiYOA1dlXL8Y0iDK 5phDbQZfHlyEPeRTf7q0XTwV7y5rsDSyKTCPrRqSDQxt0S4v988gNYxQ1JQMv2rOTwuznXgq+GA /5a4QvOayAqk18XUpkyfHyOv79Jf9aXmPsDTtQGo202ewaf784BdhZtMIn3Bj0dGyVDd5zb1Tct UjCAQ2LB1j1T8K4hlsM6Eg6xtXZWXE1H7kklZKefxbWhnJoGhwEbp/fnVH2EuA== X-Received: by 2002:a17:907:3e2a:b0:b9c:bc08:7a9a with SMTP id a640c23a62f3a-b9d7243624emr1125603866b.10.1776204004500; Tue, 14 Apr 2026 15:00:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Tue, 14 Apr 2026 14:59:53 -0700 X-Gm-Features: AQROBzC1IuIvNq6AJ8K30gsxY4DMin54nqiT_gX7lDOXg9aEthPKzL-YztAhn44 Message-ID: Subject: Re: [bitcoindev] Deactivating ECDSA/Schnorr To: conduition Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000bcab7c064f72b873" X-Original-Sender: erik@q32.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@q32-com.20251104.gappssmtp.com header.s=20251104 header.b=03GhALzg; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::634 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 (/) --000000000000bcab7c064f72b873 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ethereum is the best example of why "available but not enforced" is the only path forward. it was wrong to claw-back those funds, especially since we don't even know if someone *paid to access that key*. maybe vitalik and friend sold the dao to someone in a drunken fit and then changed-his-mind being the arbitrator of "whether something was hacked" vs "whether it was staged" is the role bitcoin can never be in. instead, we provide tools. and people can choose to use them or not use them no amount of starks can help if someone steals my private key... it's my word against theirs. quantum computing is irrelevant as the mechanism here= . On Tue, Apr 14, 2026 at 1:25=E2=80=AFPM conduition w= rote: > Hi Erik, > > Deactivating ECDSA/Schnorr based schemes should not be discussed seriousl= y. > ... > The worst possible thing we could do is confiscate everybody's coin and > move to a NISD approved algorithm on the say so of large government funde= d > organizations. > > > You seem to be under the impression that a confiscatory soft fork would > completely lock and freeze any and every coin that isn't on a PQ-safe > address. If so, you are mistaken. I don't think anyone would ever be so > foolish as to deploy a soft fork that disables ECC spending without > introducing some set of rescue protocols to complement legacy ECC > spending rules. > > I'd urge you not to think of such a fork as "disabling" ECC spending, > because that is not the entire picture. Instead think of it as > "restricting" ECC spending to a tighter set of rules which a quantum > attacker should not be able to abuse. Laolu's recent work on building > concrete BIP32 STARKs > is one such > awesome example of a tool which can do this - It works today and it cover= s > every BIP32 wallet, even those with exposed pubkeys and xpubs. Though > personally I prefer commit/reveal for better scaling. > > There will probably be some non-zero subset of the UTXO set (whose holder= s > are alive and still have their keys) that cannot meet these stricter > conditions to satisfy the rescue protocol, and so cannot migrate. These > coins would indeed be confiscated. There is research needed to quantify > this, and it depends a lot on what rescue protocols can be invented betwe= en > now and Q-day, and on how many UTXOs we can reliably say are or aren't > covered by each protocol. Today, we can confidently say that any address > derived via BIP32, or any hashed address which has an unexposed public ke= y, > can be rescued. Others are open problems. > > There is simply no credible way you can convince somebody who is sovereig= n > that their encryption algorithm is broken aside from breaking it. > > > I suspect many Bitcoiners agree, which is why any confiscatory soft fork > which restricts ECC spending will probably only be triggered *after* a > CRQC has been demonstrated concretely, e.g. by breaking the NUMS point, o= r > spending satoshi's coins, or with a ZK-STARK that shows they *could* have > spent satoshi's coins, or whatever canary mechanism we might dream up and > agree on. > > Personally I'd prefer to trigger it earlier rather than later, because we > have no reason to expect a CRQC to cooperate with our canary system, but = I > realize that might be a hard pill to swallow, so a canary would be a dece= nt > compromise as long as the community has the option to push a panic button > and force-trigger the upgrade through majority hashrate consensus later, = to > cover the case of an adversarial CRQC who sidesteps our canary. > > Bitcoin is not a nanny state. > "oh no someone might break satoshi's keys" > Let them. if satoshi's 50 Bitcoin stash keys serve to be the bounty that > propels humanity to a future of limitless unbounded magical computing tha= t > is not a problem we need to solve right now. > The worst possible thing we could do is confiscate everybody's coin and > move to a NISD approved algorithm on the say so of large government funde= d > organizations. > > That sounds dystopian at best. > > > I appreciate your code-is-law purism, but there is an exception to every > rule. > > Ethereum's DAO hack shows us what happens to those who commit to such > uncompromising fervor. Ethereum's devs had committed to code-is-law, and > then faced a similar situation where a large fraction of their supply (on= e > third of it, if my sources are correct) was at risk of immediate theft, a= nd > they could either stick to their principles and do nothing, or intervene > and hard fork. The interventionist chain turned into ETH and the purist > chain turned into ETC. Today, ETH is far more economically relevant than > ETC, because their community recognized that *cruelty is not the ethical > response to tragedy.* Users prefer not losing their coins to attackers, > basically. They prefer to use technologies whose devs take steps to preve= nt > that sort of thing. ETC meanwhile has suffered a slow death, as devs and > users migrate to greener pastures. > > Their situation rhymes with ours, but is very different too. We can see > our threat (CRQCs) coming from years away, and can prepare today to avoid > the need for a hard fork. So in a way, our prospects are more optimistic, > but our problem is also far harder to engineer around. It's not just a > single bug we need to fix. It's the fact that our entire supply is > currently resting on a shaky assumption (the ECDLP is hard). When and if > that assumption breaks, some significant fraction of coins will also be a= t > risk, and we will be put to the same choice as the ETH devs were: Do we > intervene and compromise our principles to reduce the fallout, or do we d= o > nothing? > > Personally, I think we should learn from the history of the ETH DAO hack, > and make the same choice the ETH devs did: intervene. We have options to > mitigate the confiscatory effects of intervention, and we can do it witho= ut > a hard-fork. While I doubt the appetite exists to deploy any of this stuf= f > today, I suspect it will be someday when the threat looms larger. > > > regards, > conduition > On Tuesday, April 14th, 2026 at 1:51 PM, Erik Aronesty > wrote: > > Deactivating ECDSA/Schnorr based schemes should not be discussed > seriously. > > You give people alternatives, yes. I'm a big fan of quantum optionality. > > But we cannot have a forced vaccination situation. > > > There is simply no credible way you can convince somebody who is sovereig= n > that their encryption algorithm is broken aside from breaking it. > > People can send to bad keys today. > > There are lots of op codes that let people shoot themselves in the foot > > Bitcoin is not a nanny state. > > "oh no someone might break satoshi's keys" > > Let them. if satoshi's 50 Bitcoin stash keys serve to be the bounty that > propels humanity to a future of limitless unbounded magical computing tha= t > is not a problem we need to solve right now. > > The worst possible thing we could do is confiscate everybody's coin and > move to a NISD approved algorithm on the say so of large government funde= d > organizations. > > That sounds dystopian at best. > > > > > > > > -- > 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/CAJowKgJcGTvkzjkRN3cd8LRkfaz= WycSp8p6oOd5D5dtEYRaB1w%40mail.gmail.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/= CAJowKgLV4LQkkwUrGvgbuU3Lou1Sj%2B36%3DjW0KEMrRGqa0C4icQ%40mail.gmail.com. --000000000000bcab7c064f72b873 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ethereum is the best example of why "available but no= t enforced" is the only path forward.

it was wrong to claw-back= those funds, especially since we don't even know if someone *paid to a= ccess that key*.=C2=A0 maybe vitalik=C2=A0and friend sold the dao to someon= e in a drunken fit and then changed-his-mind

being the arbitrator of= "whether something was hacked" vs "whether it was staged&qu= ot; is the role=C2=A0bitcoin can never be in.

instead, we provide to= ols.=C2=A0 =C2=A0and people can choose to use them or not use them

n= o amount of starks can help if someone steals my private key... it's my= word against theirs.=C2=A0 quantum computing is irrelevant as the mechanis= m here.






On Tue, Apr 14, 2026 a= t 1:25=E2=80=AFPM conduition <co= nduition@proton.me> wrote:
Hi Erik,

= Deactivating ECDSA/Schnorr based schemes should not be discussed seriously.=
...
= The worst possible thing we co= uld do is confiscate everybody's coin and move to a NISD approved algor= ithm on the say so of large government funded organizations.

You seem to be under the impression that a confisc= atory soft fork would completely lock and freeze any and every coin that is= n't on a PQ-safe address. If so, you are mistaken.=C2=A0I don't think a= nyone would ever be so foolish as to deploy a soft fork that disables ECC s= pending without introducing=C2=A0some set of rescue protocols to complement=C2= =A0legacy ECC spending rules.

I'd urge you not to think= of such a fork as "disabling" ECC spending, because that is not = the entire picture. Instead think of it as "restricting" ECC spen= ding to a tighter set of rules which a quantum attacker should not be able = to abuse.=C2=A0Laolu's r= ecent work on building concrete BIP32 STARKs=C2=A0is one such awesome example of a tool which can = do this - It works today and it covers every BIP32 wallet, even those with = exposed pubkeys and xpubs. Though personally I prefer commit/reveal for bet= ter scaling.

There will proba= bly be some non-zero subset of the UTXO set (whose holders are alive and st= ill have their keys) that cannot meet these stricter conditions to satisfy = the rescue protocol, and so cannot migrate. These coins would indeed be con= fiscated. There is research needed to quantify this, and it depends a lot o= n what rescue protocols can be invented between now and Q-day, and on how m= any UTXOs we can reliably say are or aren't covered by each protocol. T= oday, we can confidently say that any address derived via BIP32, or any has= hed address which has an unexposed public key, can be rescued. Others are o= pen problems.

There is simply no credible way you can= convince somebody who is sovereign that their encryption algorithm is brok= en aside from breaking it.

I suspect many Bitcoiners agree, which is why any confiscatory soft for= k which restricts ECC spending will probably only be triggered after=C2=A0a CRQC has been demonstrated concretely,= e.g. by breaking the NUMS point, or spending satoshi's coins, or with = a ZK-STARK that shows they could=C2=A0h= ave spent satoshi's coins, or whatever canary mechanism we might dream = up and agree on.

=
Personally I'd prefer to trigger it earlie= r rather than later, because we have no reason to expect a CRQC to cooperat= e with our canary system, but I realize that might be a hard pill to swallo= w, so a canary would be a decent compromise as long as the community has th= e option to push a panic button and force-trigger the upgrade through major= ity hashrate consensus later, to cover the case of an adversarial CRQC who = sidesteps our canary.

Bitcoin is not a nanny state.
"oh no someone mig= ht break satoshi's keys"
Let them. if satoshi's 50 Bitcoin stash keys serve= to be the bounty that propels humanity to a future of limitless unbounded = magical computing that is not a problem we need to solve right now.<= /div>
The worst possible t= hing we could do is confiscate everybody's coin and move to a NISD appr= oved algorithm on the say so of large government funded organizations.
That sounds dystopia= n at best.

I apprecia= te your code-is-law purism, but there is an exception to every rule.=

=
Ethereum's DAO hack shows us what happens = to those who commit to such uncompromising fervor. Ethereum's devs had = committed to code-is-law, and then faced a similar situation where a large = fraction of their supply=C2=A0(one third of it, if my sources are corre= ct) was at risk of immediate theft, and they could either stick to their p= rinciples and do nothing, or intervene and hard fork. The interventionist c= hain turned into ETH and the purist chain turned into ETC. Today, ETH=C2=A0= is far more=C2=A0economically=C2=A0relevant than ETC, because their community recognized that cruelty is not the ethical response to tragedy.=C2=A0Users prefer not = losing their coins to attackers, basically. They prefer to use technologies= whose devs take steps to prevent that sort of thing. ETC meanwhile has suf= fered a slow death, as devs and users migrate to greener pastures. <= /div>

<= div style=3D"font-family:Arial,sans-serif;font-size:14px">Their situation rhymes with ours, but is very d= ifferent too. We can see our threat (CRQCs) coming from years away, and can= prepare today to avoid the need for a hard fork. So in a way, our prospect= s are more optimistic, but our problem is also far harder to engineer aroun= d. It's not just a single bug we need to fix. It's the fact that ou= r entire supply is currently resting on a shaky assumption (the ECDLP is ha= rd). When and if that assumption breaks, some significant fraction of coins= will also be at risk, and we will be put to the same choice as the ETH dev= s were: Do we intervene and compromise our principles to reduce the fallout= , or do we do nothing?

Personally, I= think we should learn from the history of the ETH DAO hack, and make the s= ame choice the ETH devs did: intervene. We have options to mitigate the con= fiscatory effects of intervention, and we can do it without a hard-fork. Wh= ile I doubt the appetite exists to deploy any of this stuff today, I suspec= t it will be someday when the threat looms larger.


regards,
conduition
On Tuesday, April 14th, 2026 at 1:51 PM, Erik Aronesty <erik@q32.com> wrote:
Deactivating ECDSA/Schnorr = based schemes should not be discussed seriously.
<= br>
You give people alternatives, yes. I'm a big= fan of quantum optionality.

But we cannot have a forced vaccination situation.


There is simp= ly no credible way you can convince somebody who is sovereign that their en= cryption algorithm is broken aside from breaking it.

People can send to bad keys today.

There are lots of op codes that le= t people shoot themselves in the foot

Bitcoin is not a nanny state.

"oh no someone might break satoshi's keys&quo= t;

Let them. if satosh= i's 50 Bitcoin stash keys serve to be the bounty that propels humanity = to a future of limitless unbounded magical computing that is not a problem = we need to solve right now.

The worst possible thing we could do is confiscate everybody's coi= n and move to a NISD approved algorithm on the say so of large government f= unded organizations.

Tha= t sounds dystopian at best.







<= /div>

--
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@googl= egroups.com.
To view this discussion visit https://groups= .google.com/d/msgid/bitcoindev/CAJowKgJcGTvkzjkRN3cd8LRkfazWycSp8p6oOd5D5dt= EYRaB1w%40mail.gmail.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/CAJowKgLV4LQkkwUrGvgbuU3Lou1Sj%2B36%3DjW0KEMrRGqa0C4icQ%= 40mail.gmail.com.
--000000000000bcab7c064f72b873--