From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 Apr 2026 08:22:14 -0700 Received: from mail-oo1-f63.google.com ([209.85.161.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wD24D-0007Ty-AN for bitcoindev@gnusha.org; Wed, 15 Apr 2026 08:22:14 -0700 Received: by mail-oo1-f63.google.com with SMTP id 006d021491bc7-66b612efb4asf11405295eaf.0 for ; Wed, 15 Apr 2026 08:22:13 -0700 (PDT) ARC-Seal: i=3; a=rsa-sha256; t=1776266527; cv=pass; d=google.com; s=arc-20240605; b=M4lWDjPoXw+Kjou/Mg2kh+kqnt5gLLScleMxFim4L4MidF5OKpPIUgt2Zg2NQsBYx9 HO2Q0hKdFLHu7dvSv9zKyec8qUyot/C/qrQYBZ2Ze7PHaeBdEnExzNR2IxDc4grs46ZT H9CeKg0pdHGawKPuSES6o/YhNAFnWBHrIw5yPah9H6hc4Q1brgrKLAx0+J3ACNsoSAHo WZVtw1aPuRpdMYeIXjzoRnH/FZsOvfVKFewvu0a2HZOrXQ6wYChusMoCbwxRFev52hPy K+ErgIQqR4zBGUDY5khhYO2/i3qkuSlYQ1XdbGf5saWhWa51iyx4qwkFETb8ubGeJwFA IqtA== 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=uJdOD5yK3BSMgPYVGL1BmnjYxpfRRN43jAD8vjO5GLw=; fh=jWjvyExH07FiFyY+c1EW3k7t+CnNn5y6YlSv26cfooU=; b=V7vlY/p8FisxZktWFPKNNQwz673N17jdN97ThkTErOXylkXv1CBVxuj/cGzdi5cF88 MeOrnh9y/8Ki0NSr9ytENfhYKbvBGlp8jFo8OYjDFyewU3qbg9ebHRDB32WgS3Ez/PzC 0d7p9CFWVL/eB7GaENerezRfeuT2ZOv58GStvvLkMMGAhVsqRXS5f6eS7deh0zLfG3GH MY8KOMWs73gR06RVRxfq+YuG5par4MY3DPG/vB9GpMoeTi4fsHYSh3iY31WzBan4kHAi kjZ2hM8mYwn281jm3TBYoyIbvrIzgR+x04/17eS5aiciXrmI9XgxJPYUrle12FmdweY7 qgHA==; 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=UCZL14ZC; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::629 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=1776266527; x=1776871327; 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=uJdOD5yK3BSMgPYVGL1BmnjYxpfRRN43jAD8vjO5GLw=; b=og9Qc+FycHkVFvnbG30hz3QuJ+3mAZRaFIV7A6bAkKT1THFQbRr0wLtNxCiPUfj3+W e3kJAp6d6PWqUHGrgMdrVSbuqI4jNOk3EfQd6FHo15oCl59zGDy5OWwV7tiNezjty8Dn k727E3r0BBb5Mm2eZiZRY9xCiOJVlbB44hFLcWPRnXvktOV5gt2CQpA8y72qURxPoKLZ NxHhnYnWz0JeWgNrVDI02ROUlYUxOKtAVvePNJ3kmTo/XwZcW4Eb4DteJvD3MHhrprag Sl2pOJ+IaNHMh72a425lytC6q310nTOAtMbFfUFtCnHcVs8uMDB9XU4HWI4RQG212wld PsxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776266527; x=1776871327; 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=uJdOD5yK3BSMgPYVGL1BmnjYxpfRRN43jAD8vjO5GLw=; b=QnX76WoGl/r1awJiIOxOW4slHidke5VjNwFxU21ao9Tc/f+4iLit4Ax2UKsEzTWjMY ecYP4E0Jg5qx2vIT5Et8Se7/E/6WTi73Q15gjjG+++cZmMv7GH4D48XqlLOKrpToAqtT cloWOQOODkwA+qG+Qoil3JNlhnhUocsV1iB2D4bZtmQJv3YbsiV8HBnYtntOxqQwCeeV 4X1FzrIp+LA1MXjqWSI7/WZ4n6NFaIz2TiT2BwGNnCY+ets1s2YIebxSQ/tNxmr8kBcg nCJJmLB+WkPa0ta+W9WNO62X+M4Iq4BH7+8bVOifxqfLdqbQA2JoXV8HqeLlC6bqvQOU 41Jw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=3; AFNElJ9ASWAXdsTJ9jqDVLnrjbeqOMk6rAe9Y9SAbHkhohZkksQmeLH9U5oNBHxOr+KI6vmR4obCkcvJqKPP@gnusha.org X-Gm-Message-State: AOJu0YyRiIxaZzRkWRRHnvsScfoxtTIDtpA6gBL17ADeBL3HT1F3zjDP ByMccU6T9oNFHI7eXpoA1YbSnxhkqT9sO6Kkh+sygcxl4Glp/fkDY6su X-Received: by 2002:a05:6820:5603:b0:692:7ac5:f8d0 with SMTP id 006d021491bc7-6927ac6052fmr1436028eaf.3.1776266527039; Wed, 15 Apr 2026 08:22:07 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AYAyTiKLPY3Cb/s0hefVmYoY8qkOrlvWLCJq3Gk8WRGrL88qgw==" Received: by 2002:a4a:d192:0:b0:684:b057:49f5 with SMTP id 006d021491bc7-692c465768els93407eaf.0.-pod-prod-00-us-canary; Wed, 15 Apr 2026 08:22:01 -0700 (PDT) X-Received: by 2002:a05:6808:3095:b0:467:da0d:537e with SMTP id 5614622812f47-478b69b77e4mr9531587b6e.7.1776266521000; Wed, 15 Apr 2026 08:22:01 -0700 (PDT) Received: by 2002:aa7:df08:0:b0:670:312d:f74b with SMTP id 4fb4d7f45d1cf-67228b28a65msa12; Wed, 15 Apr 2026 02:37:39 -0700 (PDT) X-Received: by 2002:a05:6402:e99:b0:66e:43ef:2951 with SMTP id 4fb4d7f45d1cf-670786a3953mr10212969a12.4.1776245857409; Wed, 15 Apr 2026 02:37:37 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1776245857; cv=pass; d=google.com; s=arc-20240605; b=KGcEfI3SQKgkdpNBPg3jgxBUIpRC3lvmLfGlq+wWCdDZQTsWtb7D+7KbHzMIJV8njF agfwgYEVbSotGyRqK3W1SLPibq0fsm3rutOicCqMc0eC4BPzoEVBrX5oB3Pe/d42fHKz hWO6Kz12b6oBzAEjgahKYvqrVDrKP/lgyNdTJ4K7krVymAJuICCs0vdzyKLxwrmILHIH EX9hdY/RpfTP6ARdjUqkuln3OzlJvFOofmaYDn89TzDCx/FQwEV5J2HAkru/phSkVp6q FFqsF7bkdxuR97pjEHhiYF9l1W9jU9M2FUKaHLeMynmZ25csYOzzegt+ax90G5kO+W9B jGPg== 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=pTrgL3EPeqLqwvzgagnPF6t7LBtvpAc094zhbVBGR1U=; fh=/N7hLAnjazzpj1blspkoIYUbVf3N/Xvk2Re0f9S4crY=; b=drMkRck0sYZeVOtglvDpiBqFw3g+yglJb8kARIcW0soHpPx/Jk+OqKUHGnBY9uLngo vR2Vy62b8izJaethCWDymFvM3y+o1jAWVRh2ZSlMk5rdbZKRmwJFFcpeepjtcKptjh+H jCeS4c8aUUggIw8FfN/VMGCHIe0GJErLUmhQoC7qbuclvCZHI1P+/81rHYdIdyi6NLua q8M6QGI7TgCZ0Luy74lLlCcGhs6hCjVn9OPEj2bYDnKz1rxO4h8Lt4VQdF3wsGQRNAIR bYWvtHMZTGj/3qJcW01FxQFzv6E1X1XNCah43xPK5OJdFLG3RCBoraY4PyCGnBdbEjKP GZhw==; 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=UCZL14ZC; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::629 as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com. [2a00:1450:4864:20::629]) by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-6723801d078si24048a12.8.2026.04.15.02.37.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2026 02:37:37 -0700 (PDT) Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::629 as permitted sender) client-ip=2a00:1450:4864:20::629; Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-b79f8f7ea43so1183237966b.2 for ; Wed, 15 Apr 2026 02:37:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776245857; cv=none; d=google.com; s=arc-20240605; b=bXTW30kmj/hGL8ma/7TKMdqBP98HzwCandND/kz2AJALJSM2eZorMkRX5JXZuvPr2W gGY2ct61XJURdccXtVuTTs/ZoDAaUyzR18RbTtDyPO3SFYcrneKgNA6Bne6BpKLkPMTd kIBQrRIH+GytLkGkMkIAXzYYmFHGXrkhauk3YSbJ1yEdjeVCzTWt9iYWeBLBl8OX5y6H WWkmj57Z60MOZxgilupuA28PqLgpghFoeLyVJc7WfBKSQ0jdakvReC6HE2iq429cFFYm 1pBLg62XqocR0sFCgFPf31j0etdBsnYA2Ua2N4YQygW9KDViu5wvdspStxJR11UQnroi OtJQ== 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=pTrgL3EPeqLqwvzgagnPF6t7LBtvpAc094zhbVBGR1U=; fh=/N7hLAnjazzpj1blspkoIYUbVf3N/Xvk2Re0f9S4crY=; b=hTj+vEtIQtbMTpNVBxkDnRxztfgpTG7OQRmJoxXlVg9bl79zYTph0Glerg9lJZ03It +LxG0c28ivfpwXJCJ0wIWe/FEdf5pExwLK+7u1+IWMWvgSobLqZs3s9UYJW+IvZ+gq9Y 9kEY4Kp/E+DxqlHIFxNT5ncqliUp2YBW7bxO6vXN0nsKb+mbVRMXTn4bBZND86hHqmuU icf0+i8LG6kDw1PnCIQp54IbgDu3Jq/Vy+gIoN3dhm+jtTnPpZv220DlROLkkCbm6K/U SSar9bH+G8/w8wJzO1/qxI701jmIZqiTqXwHq8aDMGb8ibDHPaJ/7EwYuTUq9NN4c9xe 8A/Q==; dara=google.com ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Gm-Gg: AeBDievCZ/eoSGlIBoDeOThzYSOFIHBBIl5RaVRZHZuVNHQJc04D/vqfomZTabe1NYB Lmo85CEkxAr2o/XLEaHdkXvYz/UDA018z698TA8DF8TVRXWMjjQ/lAVf1dw2kUtIu+/vs9rRyQF WhlJ0Sdj/HoByDZQ5jAaUN/XZJTSoIHrZTBD9sfYM/ufCEdd2vnxYttDcNCa4kFFiIrylW8mCJX QWIMt/nBpLGPf18laiwWxBM/FJ6QFSj0a7gIX2ECpvHFmWBO3YGkge/tkFEIO2dAFvDWz2nMwpO r3opSYSsYk0l4l1lYxiRo+oMzE9FAN/dJeQOCsb/TZ8hdvLMNmU= X-Received: by 2002:a17:907:160f:b0:b9c:aba8:87c6 with SMTP id a640c23a62f3a-b9d729c050fmr1135122266b.37.1776245856552; Wed, 15 Apr 2026 02:37:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Wed, 15 Apr 2026 02:37:25 -0700 X-Gm-Features: AQROBzDDCbjU7wAbPLgq9GYYHIggymMCXDlcqjFDMc4Mw5HxpRlw4pWELj53Rfw Message-ID: Subject: Re: [bitcoindev] Deactivating ECDSA/Schnorr To: Alex Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000504c81064f7c7739" 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=UCZL14ZC; arc=pass (i=1); spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::629 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 (/) --000000000000504c81064f7c7739 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable i have no objection to changing key spends to be more secure at an incremental cost. merkle spends are more secure for a number of reasons, and quantum is only one of them i'm only speaking about the many, many confiscatory proposals that are discussed On Wed, Apr 15, 2026 at 12:55=E2=80=AFAM Alex wrote= : > The leading "platform" for PQC is BIP360 and many invalidly assume its > disabling of key spend path means "deactivating Schnorr". That's NOT what > the BIP does: > > * A new wallet address is ADDED (you optionally pay to it). Its existence > does not freeze your coins in other wallets. > * BIP360 disables key spend path; that is not actually disabling Schnorr > it just moves Schnorr spends to script spend path. > * In BIP360 you can still spend using Schnorr, you just need a few extra > bytes in the transaction since you now call upon an explicit OP-code rath= er > than implicit key spend path. > > BIP360 just moves from always exposing your Schnorr public key, to only > exposing it if you actually choose to use it (that's why BIP360 is called > Pay2MerkleRoot; it hides unused script leafs - and that is the key to > seamless transition from Schnorr to later on>) > onsdag 15 april 2026 kl. 00:17:05 UTC+2 skrev Erik Aronesty: > >> 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 sol= d >> the dao to someone in a drunken fit and then changed-his-mind >> >> being the arbitrator of "whether something was hacked" vs "whether it wa= s >> staged" is the role bitcoin can never be in. >> >> instead, we provide tools. and people can choose to use them or not us= e >> 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 h= ere. >> >> >> >> >> >> >> On Tue, Apr 14, 2026 at 1:25=E2=80=AFPM conduition = wrote: >> >>> Hi Erik, >>> >>> Deactivating ECDSA/Schnorr based schemes should not be discussed >>> seriously. >>> ... >>> 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 fun= ded >>> 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 cov= ers >>> 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 >>> holders are alive and still have their keys) that cannot meet these >>> stricter conditions to satisfy the rescue protocol, and so cannot migra= te. >>> 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 between now and Q-day, and on how many UTXOs we can reliably s= ay >>> are or aren't covered by each protocol. Today, we can confidently say t= hat >>> any address derived via BIP32, or any hashed address which has an unexp= osed >>> public key, can be rescued. Others are open problems. >>> >>> There is simply no credible way you can convince somebody who is >>> sovereign that their encryption algorithm is broken 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* a >>> 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* ha= ve >>> spent satoshi's coins, or whatever canary mechanism we might dream up a= nd >>> 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 >>> decent compromise as long as the community has the option to push a pan= ic >>> button and force-trigger the upgrade through majority hashrate consensu= s >>> later, to cover the case of an adversarial CRQC who sidesteps our canar= y. >>> >>> 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 tha= t >>> propels humanity to a future of limitless unbounded magical computing t= hat >>> 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 fun= ded >>> organizations. >>> >>> That sounds dystopian at best. >>> >>> >>> I appreciate your code-is-law purism, but there is an exception to ever= y >>> 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, an= d >>> then faced a similar situation where a large fraction of their supply (= one >>> third of it, if my sources are correct) was at risk of immediate theft,= and >>> they could either stick to their principles and do nothing, or interven= e >>> 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 s= teps >>> to prevent 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 avo= id >>> the need for a hard fork. So in a way, our prospects are more optimisti= c, >>> 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 i= f >>> 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 devs 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 same choice the ETH devs did: intervene. We have opt= ions >>> to mitigate the confiscatory effects of intervention, and we can do it >>> without a hard-fork. While I doubt the appetite exists to deploy any of >>> this stuff today, I suspect it will be someday when the threat looms la= rger. >>> >>> >>> 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 >>> sovereign 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 tha= t >>> propels humanity to a future of limitless unbounded magical computing t= hat >>> 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 fun= ded >>> 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+...@googlegroups.com. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/CAJowKgJcGTvkzjkRN3cd8LRkf= azWycSp8p6oOd5D5dtEYRaB1w%40mail.gmail.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/a058151d-3134-47e5-96c7-3f79= f6dab5b2n%40googlegroups.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/= CAJowKgKtiH_N8KLdOAi2TXfmt3_fDvHKnuoEoyrkMyMFYELqoA%40mail.gmail.com. --000000000000504c81064f7c7739 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i have no objection to changing key spends to be more secu= re at an incremental cost.=C2=A0 merkle spends are more secure for a number= of reasons, and quantum is only one of them

i'm only speaking a= bout the many, many confiscatory proposals that are discussed

On Wed, Apr 15, 2026 at 12:55=E2=80=AFAM Alex <alexhultman@gmail.com> wrote:
The leading "platform&quo= t; for PQC is BIP360 and many invalidly assume its disabling of key spend p= ath means "deactivating Schnorr". That's NOT what the BIP doe= s:

* A new wallet address is ADDED (you optionally pay t= o it). Its existence does not freeze your coins in other wallets.
* BIP360 disables key spend path; that is not actually disabling Schnorr i= t just moves Schnorr=C2=A0spends to script spend path.
* In BIP36= 0 you can still spend using Schnorr,=C2=A0you just need a few extra bytes i= n the transaction since you now call upon an explicit OP-code rather than i= mplicit key spend path.

BIP360 just moves from alw= ays exposing your Schnorr public key, to only exposing it if you actually c= hoose to use it (that's why BIP360 is called Pay2MerkleRoot; it hides u= nused script leafs - and that is the key to seamless transition from Schnor= r to <insert whatever PQC that will be added later on>)
onsdag 15 april 2= 026 kl. 00:17:05 UTC+2 skrev Erik Aronesty:
ethereum is the best example o= f why "available but not enforced" is the only path forward.
<= br>it was wrong to claw-back those funds, especially since we don't eve= n know if someone *paid to access that key*.=C2=A0 maybe vitalik=C2=A0and f= riend sold the dao to someone in a drunken fit and then changed-his-mind
being the arbitrator of "whether something was hacked" vs &q= uot;whether it was staged" is the role=C2=A0bitcoin can never be in.
instead, we provide tools.=C2=A0 =C2=A0and people can choose to use t= hem or not use them

no amount of starks can help if someone steals m= y private key... it's my word against theirs.=C2=A0 quantum computing i= s irrelevant as the mechanism here.






On Tue, Apr 14, = 2026 at 1:25=E2=80=AFPM conduition <condu...@proton.= me> wrote:
Hi Erik,

Deactivating ECD= SA/Schnorr based schemes should not be discussed seriously....
The worst possible thing we could do is confis= cate everybody's coin and move to a NISD approved algorithm on the say = so of large government funded 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.=C2=A0I don't think anyone would ever= be so foolish as to deploy a soft fork that disables ECC spending without = introducing=C2=A0some set of rescue protocols to complement=C2=A0legacy ECC spe= nding rules.

I'd urge you not to think of such a fork a= s "disabling" ECC spending, because that is not the entire pictur= e. Instead think of it as "restricting" ECC spending to a tighter= set of rules which a quantum attacker should not be able to abuse.=C2=A0Laolu's = recent 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 be= tter scaling.

There will prob= ably be some non-zero subset of the UTXO set (whose holders are alive and s= till have their keys) that cannot meet these stricter conditions to satisfy= the rescue protocol, and so cannot migrate. These coins would indeed be co= nfiscated. There is research needed to quantify this, and it depends a lot = on what rescue protocols can be invented between 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 ha= shed address which has an unexposed public key, can be rescued. Others are = open problems.

There is simply no credible way you ca= n convince somebody who is sovereign that their encryption algorithm is bro= ken aside from breaking it.

I suspect many Bitcoiners agree, which is why any confiscatory soft fo= rk 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=A0= have spent satoshi's coins, or whatever canary mechanism we might dream= up and agree on.

Personally I'd prefer to trigger it earli= er rather than later, because we have no reason to expect a CRQC to coopera= te with our canary system, but I realize that might be a hard pill to swall= ow, so a canary would be a decent compromise as long as the community has t= he option to push a panic button and force-trigger the upgrade through majo= rity hashrate consensus later, to cover the case of an adversarial CRQC who= sidesteps our canary.

Bitcoin is not a nanny state.
"oh no someone mi= ght break satoshi's keys"
Let them. if satoshi's 50 Bitcoin stash keys serv= e 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 coin and move to a NISD app= roved algorithm on the say so of large government funded organizations.
That sounds dystopi= an at best.

I appreci= ate 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 <er...@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+...@googlegroups= .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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/a058151d-3134-47e5-96c7-3f79f6dab5b2n%40googlegrou= ps.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/ms= gid/bitcoindev/CAJowKgKtiH_N8KLdOAi2TXfmt3_fDvHKnuoEoyrkMyMFYELqoA%40mail.g= mail.com.
--000000000000504c81064f7c7739--