From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 28 Apr 2026 13:47:12 -0700 Received: from mail-qv1-f60.google.com ([209.85.219.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wHpKp-00015E-2l for bitcoindev@gnusha.org; Tue, 28 Apr 2026 13:47:12 -0700 Received: by mail-qv1-f60.google.com with SMTP id 6a1803df08f44-8b02af4345fsf113193876d6.1 for ; Tue, 28 Apr 2026 13:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1777409225; x=1778014025; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=w6dR4+hYbT8xc9sWkcf72HTmIAyLXOjJ0flE9OYM45A=; b=b/xeg4wPtGVzWSWpLt5u6d/J9fovnabjSqaJC3xn6zuonks6I9RV7h9/4xLJp2msku ia+yUCMHgQXTivEvSmVjoHfXGfL8uLYzs0camoYnZAFxkDppazL9pEwtQg4M0NS/Jtcg VCDBORVN/ENh3ZKIuYqRf4T9ZlfpZY8NOLgWV5ieaMnDH4xESw/8R3jg/au+dL9Q9s8Z L354bvm/vAxDTtHgRUc27jYBEmGQYhzt5xzr9i2RbPbsKZtToTjh91YMNlV8XNyDzlpQ v6ma3S0FWVzmpn0VUXdj1h5jyjLrs5fXBjJCiyBA5XpLuxfe8+JN0IFVwKRkDYeRPLUt 2Abg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777409225; x=1778014025; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=w6dR4+hYbT8xc9sWkcf72HTmIAyLXOjJ0flE9OYM45A=; b=Ys2P/mObZiuFpQ7rBpQEm0Pz3zOyWTJzQCxSKNixmZ8oJMlsRPWx5+MeT+vIZ3D7KY GjzPr5NEGhTNPcTzO/lx/vOIHrNJ6NFAL8J1JrIt8HLrRWjnQwXof5KeHBDz32btTO0o lJV2nc2VoqAghk+sADewQ36bFCi6F5tnRgLOlvmb+z+SLTKsdXgqvW2ydhVsat6GnuJm kvZMwbM/LBvKfX5EgsDAsqMFJG/4RSbZYuoiNyj55gL7mIhOjfUmJG455BBpdMejVYik 2KXpINoPOJCnwi/CVHbIRCVhB2ZhbVB1CNe+ycgN9/fy9EM9Mf5Wf1bLqGyZftf1KOts +7vw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ8QsKzL19W+tgd5oIrbBjA0WS97edd3r/PHOs17OLLpBZ4/gj6U35ziV2pHAgrUSX64izAU5taXSfos@gnusha.org X-Gm-Message-State: AOJu0YyUWyRmP373Zgblojejg1GfcZ7c8W3klDt+8m0FpzIbPGh406Se aOrFAfuW1sz0Z25SW4nO7hA93vGKIiN3wVnWeQlu8QuIMZZvy7YU1n6N X-Received: by 2002:a05:6214:449a:b0:89c:4be3:5d6 with SMTP id 6a1803df08f44-8b3e31bc68fmr82126706d6.29.1777409224801; Tue, 28 Apr 2026 13:47:04 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOoyfY3pCujTglSggd5rpl0BFbj+Aa8Cor5c/6uXtRykw==" Received: by 2002:a05:6214:764:b0:8ac:a471:c7d8 with SMTP id 6a1803df08f44-8ae81d15dfals232346576d6.0.-pod-prod-06-us; Tue, 28 Apr 2026 13:46:57 -0700 (PDT) X-Received: by 2002:a05:620a:45a2:b0:8ea:ed9a:21fb with SMTP id af79cd13be357-8f7d9902043mr664549485a.45.1777409217486; Tue, 28 Apr 2026 13:46:57 -0700 (PDT) Received: by 2002:a05:690c:d19:b0:7b3:443:26a9 with SMTP id 00721157ae682-7b9ed99b113ms7b3; Sun, 19 Apr 2026 02:03:13 -0700 (PDT) X-Received: by 2002:a05:690c:6e86:b0:7b2:64f4:a2dc with SMTP id 00721157ae682-7b9eceb27f8mr90186027b3.9.1776589392839; Sun, 19 Apr 2026 02:03:12 -0700 (PDT) Date: Sun, 19 Apr 2026 02:03:12 -0700 (PDT) From: Ali Sherief To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: Re: [bitcoindev] Deactivating ECDSA/Schnorr MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_499216_199176335.1776589392218" X-Original-Sender: ali@notatether.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 (/) ------=_Part_499216_199176335.1776589392218 Content-Type: multipart/alternative; boundary="----=_Part_499217_967976918.1776589392218" ------=_Part_499217_967976918.1776589392218 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't like the idea of disabling ECDSA and Schnorr spending. For one thing, this action is a non-starter until some quantum-safe address= =20 has been created. Second of all, this change will not be possible without a hard fork. Hard= =20 forks are generally avoided by the community because they introduce=20 fragmentation. Last, the idea of somehow allowing recovery of locked legacy coins via the= =20 private key is way too complicated to implement. You will basically need to= =20 freeze the UTXO set at a particular timestamp which means accepting that=20 future coin spends will be lost until the migration is complete. Or hope=20 that quantum computers do not have enough tx data to reverse-engineer the= =20 private key from the ECDSA or Schnorr signatures, which would make=20 quantum-proofing useless as an attacker can just restore and spend. -Ali On Wednesday, April 15, 2026 at 6:22:07=E2=80=AFPM UTC+3 Erik Aronesty wrot= e: > i have no objection to changing key spends to be more secure at an=20 > incremental cost. merkle spends are more secure for a number of reasons,= =20 > and quantum is only one of them > > i'm only speaking about the many, many confiscatory proposals that are=20 > 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= =20 >> disabling of key spend path means "deactivating Schnorr". That's NOT wha= t=20 >> the BIP does: >> >> * A new wallet address is ADDED (you optionally pay to it). Its existenc= e=20 >> does not freeze your coins in other wallets. >> * BIP360 disables key spend path; that is not actually disabling Schnorr= =20 >> it just moves Schnorr spends to script spend path. >> * In BIP360 you can still spend using Schnorr, you just need a few extra= =20 >> bytes in the transaction since you now call upon an explicit OP-code rat= her=20 >> than implicit key spend path. >> >> BIP360 just moves from always exposing your Schnorr public key, to only= =20 >> exposing it if you actually choose to use it (that's why BIP360 is calle= d=20 >> Pay2MerkleRoot; it hides unused script leafs - and that is the key to=20 >> 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= =20 >>> only path forward. >>> >>> it was wrong to claw-back those funds, especially since we don't even= =20 >>> know if someone *paid to access that key*. maybe vitalik and friend so= ld=20 >>> the dao to someone in a drunken fit and then changed-his-mind >>> >>> being the arbitrator of "whether something was hacked" vs "whether it= =20 >>> was staged" is the role bitcoin can never be in. >>> >>> instead, we provide tools. and people can choose to use them or not= =20 >>> use them >>> >>> no amount of starks can help if someone steals my private key... it's m= y=20 >>> word against theirs. quantum computing is irrelevant as the mechanism = here. >>> >>> >>> >>> >>> >>> >>> On Tue, Apr 14, 2026 at 1:25=E2=80=AFPM conduition = wrote: >>> >>>> Hi Erik, >>>> >>>> Deactivating ECDSA/Schnorr based schemes should not be discussed=20 >>>> seriously. >>>> ... >>>> The worst possible thing we could do is confiscate everybody's coin an= d=20 >>>> move to a NISD approved algorithm on the say so of large government fu= nded=20 >>>> organizations. >>>> >>>> >>>> You seem to be under the impression that a confiscatory soft fork woul= d=20 >>>> completely lock and freeze any and every coin that isn't on a PQ-safe= =20 >>>> address. If so, you are mistaken. I don't think anyone would ever be= =20 >>>> so foolish as to deploy a soft fork that disables ECC spending without= =20 >>>> introducing some set of rescue protocols to complement legacy ECC=20 >>>> spending rules.=20 >>>> >>>> I'd urge you not to think of such a fork as "disabling" ECC spending,= =20 >>>> because that is not the entire picture. Instead think of it as=20 >>>> "restricting" ECC spending to a tighter set of rules which a quantum= =20 >>>> attacker should not be able to abuse. Laolu's recent work on building= =20 >>>> concrete BIP32 STARKs=20 >>>> is one such=20 >>>> awesome example of a tool which can do this - It works today and it co= vers=20 >>>> every BIP32 wallet, even those with exposed pubkeys and xpubs. Though= =20 >>>> personally I prefer commit/reveal for better scaling. >>>> >>>> There will probably be some non-zero subset of the UTXO set (whose=20 >>>> holders are alive and still have their keys) that cannot meet these=20 >>>> stricter conditions to satisfy the rescue protocol, and so cannot migr= ate.=20 >>>> These coins would indeed be confiscated. There is research needed to= =20 >>>> quantify this, and it depends a lot on what rescue protocols can be=20 >>>> invented between now and Q-day, and on how many UTXOs we can reliably = say=20 >>>> are or aren't covered by each protocol. Today, we can confidently say = that=20 >>>> any address derived via BIP32, or any hashed address which has an unex= posed=20 >>>> public key, can be rescued. Others are open problems. >>>> >>>> There is simply no credible way you can convince somebody who is=20 >>>> sovereign that their encryption algorithm is broken aside from breakin= g it. >>>> >>>> >>>> I suspect many Bitcoiners agree, which is why any confiscatory soft=20 >>>> fork which restricts ECC spending will probably only be triggered=20 >>>> *after* a CRQC has been demonstrated concretely, e.g. by breaking the= =20 >>>> NUMS point, or spending satoshi's coins, or with a ZK-STARK that shows= they=20 >>>> *could* have spent satoshi's coins, or whatever canary mechanism we=20 >>>> might dream up and agree on. >>>> >>>> Personally I'd prefer to trigger it earlier rather than later, because= =20 >>>> we have no reason to expect a CRQC to cooperate with our canary system= , but=20 >>>> I realize that might be a hard pill to swallow, so a canary would be a= =20 >>>> decent compromise as long as the community has the option to push a pa= nic=20 >>>> button and force-trigger the upgrade through majority hashrate consens= us=20 >>>> later, to cover the case of an adversarial CRQC who sidesteps our cana= ry. >>>> >>>> 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=20 >>>> that propels humanity to a future of limitless unbounded magical compu= ting=20 >>>> that is not a problem we need to solve right now. >>>> The worst possible thing we could do is confiscate everybody's coin an= d=20 >>>> move to a NISD approved algorithm on the say so of large government fu= nded=20 >>>> organizations. >>>> >>>> That sounds dystopian at best. >>>> >>>> >>>> I appreciate your code-is-law purism, but there is an exception to=20 >>>> every rule. >>>> >>>> Ethereum's DAO hack shows us what happens to those who commit to such= =20 >>>> uncompromising fervor. Ethereum's devs had committed to code-is-law, a= nd=20 >>>> then faced a similar situation where a large fraction of their supply = (one=20 >>>> third of it, if my sources are correct) was at risk of immediate theft= , and=20 >>>> they could either stick to their principles and do nothing, or interve= ne=20 >>>> and hard fork. The interventionist chain turned into ETH and the puris= t=20 >>>> chain turned into ETC. Today, ETH is far more economically relevant=20 >>>> than ETC, because their community recognized that *cruelty is not the= =20 >>>> ethical response to tragedy.* Users prefer not losing their coins to= =20 >>>> attackers, basically. They prefer to use technologies whose devs take = steps=20 >>>> to prevent that sort of thing. ETC meanwhile has suffered a slow death= , as=20 >>>> devs and users migrate to greener pastures.=20 >>>> >>>> Their situation rhymes with ours, but is very different too. We can se= e=20 >>>> our threat (CRQCs) coming from years away, and can prepare today to av= oid=20 >>>> the need for a hard fork. So in a way, our prospects are more optimist= ic,=20 >>>> but our problem is also far harder to engineer around. It's not just a= =20 >>>> single bug we need to fix. It's the fact that our entire supply is=20 >>>> currently resting on a shaky assumption (the ECDLP is hard). When and = if=20 >>>> that assumption breaks, some significant fraction of coins will also b= e at=20 >>>> risk, and we will be put to the same choice as the ETH devs were: Do w= e=20 >>>> intervene and compromise our principles to reduce the fallout, or do w= e do=20 >>>> nothing?=20 >>>> >>>> Personally, I think we should learn from the history of the ETH DAO=20 >>>> hack, and make the same choice the ETH devs did: intervene. We have op= tions=20 >>>> to mitigate the confiscatory effects of intervention, and we can do it= =20 >>>> without a hard-fork. While I doubt the appetite exists to deploy any o= f=20 >>>> this stuff today, I suspect it will be someday when the threat looms l= arger. >>>> >>>> >>>> regards, >>>> conduition >>>> On Tuesday, April 14th, 2026 at 1:51 PM, Erik Aronesty = =20 >>>> wrote: >>>> >>>> Deactivating ECDSA/Schnorr based schemes should not be discussed=20 >>>> seriously.=20 >>>> >>>> You give people alternatives, yes. I'm a big fan of quantum=20 >>>> optionality.=20 >>>> >>>> But we cannot have a forced vaccination situation.=20 >>>> >>>> >>>> There is simply no credible way you can convince somebody who is=20 >>>> sovereign that their encryption algorithm is broken aside from breakin= g it.=20 >>>> >>>> People can send to bad keys today. >>>> >>>> There are lots of op codes that let people shoot themselves in the foo= t=20 >>>> >>>> Bitcoin is not a nanny state. >>>> >>>> "oh no someone might break satoshi's keys"=20 >>>> >>>> Let them. if satoshi's 50 Bitcoin stash keys serve to be the bounty=20 >>>> that propels humanity to a future of limitless unbounded magical compu= ting=20 >>>> that is not a problem we need to solve right now.=20 >>>> >>>> The worst possible thing we could do is confiscate everybody's coin an= d=20 >>>> move to a NISD approved algorithm on the say so of large government fu= nded=20 >>>> organizations. >>>> >>>> That sounds dystopian at best.=20 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> --=20 >>>> You received this message because you are subscribed to the Google=20 >>>> Groups "Bitcoin Development Mailing List" group. >>>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>>> an email to bitcoindev+...@googlegroups.com. >>>> To view this discussion visit=20 >>>> https://groups.google.com/d/msgid/bitcoindev/CAJowKgJcGTvkzjkRN3cd8LRk= fazWycSp8p6oOd5D5dtEYRaB1w%40mail.gmail.com >>>> . >>>> >>>> >>>> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/a058151d-3134-47e5-96c7-3f7= 9f6dab5b2n%40googlegroups.com=20 >> >> . >> > --=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/= ddcdca6a-86a3-482a-a4d3-d7601b690f57n%40googlegroups.com. ------=_Part_499217_967976918.1776589392218 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't like the idea of disabling ECDSA and Schnorr spending.

For one thing, this action is a non-starter until some quantum-saf= e address has been created.

Second of all, this = change will not be possible without a hard fork. Hard forks are generally a= voided by the community because they introduce fragmentation.
Last, the idea of somehow allowing recovery of locked legacy = coins via the private key is way too complicated to implement. You will bas= ically need to freeze the UTXO set at a particular timestamp which means ac= cepting that future coin spends will be lost until the migration is complet= e. Or hope that quantum computers do not have enough tx data to reverse-eng= ineer the private key from the ECDSA or Schnorr signatures, which would mak= e quantum-proofing useless as an attacker can just restore and spend.
=

-Ali <zenulabidin.com>

On Wednesda= y, April 15, 2026 at 6:22:07=E2=80=AFPM UTC+3 Erik Aronesty wrote:
i ha= ve no objection to changing key spends to be more secure at an incremental = cost.=C2=A0 merkle spends are more secure for a number of reasons, and quan= tum is only one of them

i'm only speaking about the many, many c= onfiscatory proposals that are discussed

On= Wed, Apr 15, 2026 at 12:55=E2=80=AFAM Alex <alexh...@gmail.com> wrote:
The lead= ing "platform" for PQC is BIP360 and many invalidly assume its di= sabling 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 ot= her wallets.
* BIP360 disables key spend path; that is not actual= ly disabling Schnorr it just moves Schnorr=C2=A0spends to script spend path= .
* In BIP360 you can still spend using Schnorr,=C2=A0you just ne= ed a few extra bytes in the transaction since you now call upon an explicit= OP-code rather than implicit key spend path.

BIP3= 60 just moves from always exposing your Schnorr public key, to only exposin= g it if you actually choose to use it (that's why BIP360 is called Pay2= MerkleRoot; it hides unused script leafs - and that is the key to seamless = transition from Schnorr to <insert whatever PQC that will be added 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 o= nly path forward.

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

being the arbitrator of "whether something = was hacked" vs "whether it was staged" is the role=C2=A0bitc= oin can never be in.

instead, we provide tools.=C2=A0 =C2=A0and peop= le can choose to use them or not use them

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



<= br>

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

Deactivating ECDSA/Schnorr based schemes should not be discussed ser= iously.
...
The worst possible thin= g we could do is confiscate everybody's coin and move to a NISD approve= d algorithm on the say so of large government funded organizations.<= br>

You seem to be under the impression that = a confiscatory soft fork would completely lock and freeze any and every coi= n 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 disab= les ECC spending without introducing=C2=A0some set of rescue protocols to compl= ement=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 spending to a tighter set of rules which a quantum attacker should not = be able to abuse.=C2=A0Laolu&#= 39;s recent work on building concrete BIP32 STARKs=C2=A0is one such awesome example of a tool whic= h 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 f= or 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 sa= tisfy 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 between now and Q-day, and on= how many UTXOs we can reliably say are or aren't covered by each proto= col. Today, we can confidently say that any address derived via BIP32, or a= ny hashed address which has an unexposed public key, can be rescued. Others= are open problems.

There is simply no credible way y= ou can convince somebody who is sovereign that their encryption algorithm i= s broken aside from breaking it.

I suspect many Bitcoiners agree, which is why any confiscatory so= ft fork which restricts ECC spending will probably only be triggered after=C2=A0a CRQC has been demonstrated concr= etely, e.g. by breaking the NUMS point, or spending satoshi's coins, or= with a ZK-STARK that shows they could= =C2=A0have 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 c= ooperate 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 panic button and force-trigger the upgrade throug= h majority hashrate consensus later, to cover the case of an adversarial CR= QC who sidesteps our canary.

Bitcoin is not a nanny stat= e.
"oh no some= one might break satoshi's keys"
Let them. if satoshi's 50 Bitcoin stash key= s serve to be the bounty that propels humanity to a future of limitless unb= ounded magical computing that is not a problem we need to solve right now.<= /span>
The worst pos= sible thing we could do is confiscate everybody's coin and move to a NI= SD approved algorithm on the say so of large government funded organization= s.
That sounds d= ystopian at best.

I a= ppreciate your code-is-law purism, but there is an exception to every rule.=
Ethereum's DAO hack shows us what h= appens to those who commit to such uncompromising fervor. Ethereum's de= vs 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= correct) was at risk of immediate theft, and they could either stick to t= heir principles and do nothing, or intervene and hard fork. The interventio= nist chain turned into ETH and the purist chain turned into ETC. Today, ETH= =C2=A0is far more=C2=A0economically=C2=A0relevant than ETC, because their community recognized tha= t cruelty is not the ethical response to tragedy.=C2=A0Users prefer = not losing their coins to attackers, basically. They prefer to use technolo= gies whose devs take steps 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, a= nd can prepare today to avoid the need for a hard fork. So in a way, our pr= ospects 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 t= hat 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 at risk, and we will be put to the same choice as the E= TH devs were: Do we intervene and compromise our principles to reduce the f= allout, or do we do nothing?

Persona= lly, 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 t= he confiscatory effects of intervention, and we can do it without a hard-fo= rk. While I doubt the appetite exists to deploy any of this stuff 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 <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/= CAJowKgJcGTvkzjkRN3cd8LRkfazWycSp8p6oOd5D5dtEYRaB1w%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+...@googlegro= ups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/a058151d-3134-47e5-96c7-3f79f6dab5b= 2n%40googlegroups.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/bitcoind= ev/ddcdca6a-86a3-482a-a4d3-d7601b690f57n%40googlegroups.com.
------=_Part_499217_967976918.1776589392218-- ------=_Part_499216_199176335.1776589392218--