From: "'conduition' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Erik Aronesty <erik@q32.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Deactivating ECDSA/Schnorr
Date: Tue, 14 Apr 2026 20:25:22 +0000 [thread overview]
Message-ID: <NaG-z72AcUvBjEO5c4yZzEbmkuPkUCwYlHMEGECRPE3C2cUhnD6on_F3eSI38-7quhWNIziELfkQUl3KbWnFSMl7aCtRDNLvb79eqRgrkWI=@proton.me> (raw)
In-Reply-To: <CAJowKgJcGTvkzjkRN3cd8LRkfazWycSp8p6oOd5D5dtEYRaB1w@mail.gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 7208 bytes --]
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 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. 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 covers 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 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 protocol. Today, we can confidently say that any address derived via BIP32, or any hashed address which has an unexposed 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 fork 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 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 decent 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 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 approved algorithm on the say so of large government funded 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 (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 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 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 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 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 options 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 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.
>
> 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 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 approved algorithm on the say so of large government funded 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/CAJowKgJcGTvkzjkRN3cd8LRkfazWycSp8p6oOd5D5dtEYRaB1w%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/NaG-z72AcUvBjEO5c4yZzEbmkuPkUCwYlHMEGECRPE3C2cUhnD6on_F3eSI38-7quhWNIziELfkQUl3KbWnFSMl7aCtRDNLvb79eqRgrkWI%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 14143 bytes --]
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
next prev parent reply other threads:[~2026-04-14 22:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-14 18:37 Erik Aronesty
2026-04-14 20:25 ` 'conduition' via Bitcoin Development Mailing List [this message]
2026-04-14 21:59 ` Erik Aronesty
2026-04-15 4:27 ` Alex
2026-04-15 9:37 ` Erik Aronesty
2026-04-14 22:29 ` Matt Corallo
2026-04-14 22:39 ` Erik Aronesty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='NaG-z72AcUvBjEO5c4yZzEbmkuPkUCwYlHMEGECRPE3C2cUhnD6on_F3eSI38-7quhWNIziELfkQUl3KbWnFSMl7aCtRDNLvb79eqRgrkWI=@proton.me' \
--to=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--cc=erik@q32.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox