* [bitcoindev] Deactivating ECDSA/Schnorr
@ 2026-04-14 18:37 Erik Aronesty
2026-04-14 20:25 ` 'conduition' via Bitcoin Development Mailing List
2026-04-14 22:29 ` Matt Corallo
0 siblings, 2 replies; 7+ messages in thread
From: Erik Aronesty @ 2026-04-14 18:37 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 1309 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2340 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Deactivating ECDSA/Schnorr
2026-04-14 18:37 [bitcoindev] Deactivating ECDSA/Schnorr Erik Aronesty
@ 2026-04-14 20:25 ` 'conduition' via Bitcoin Development Mailing List
2026-04-14 21:59 ` Erik Aronesty
2026-04-14 22:29 ` Matt Corallo
1 sibling, 1 reply; 7+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-04-14 20:25 UTC (permalink / raw)
To: Erik Aronesty; +Cc: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Deactivating ECDSA/Schnorr
2026-04-14 20:25 ` 'conduition' via Bitcoin Development Mailing List
@ 2026-04-14 21:59 ` Erik Aronesty
2026-04-15 4:27 ` Alex
0 siblings, 1 reply; 7+ messages in thread
From: Erik Aronesty @ 2026-04-14 21:59 UTC (permalink / raw)
To: conduition; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 8162 bytes --]
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 PM conduition <conduition@proton.me> 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 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
> <https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI> 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/CAJowKgLV4LQkkwUrGvgbuU3Lou1Sj%2B36%3DjW0KEMrRGqa0C4icQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 14457 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Deactivating ECDSA/Schnorr
2026-04-14 18:37 [bitcoindev] Deactivating ECDSA/Schnorr Erik Aronesty
2026-04-14 20:25 ` 'conduition' via Bitcoin Development Mailing List
@ 2026-04-14 22:29 ` Matt Corallo
2026-04-14 22:39 ` Erik Aronesty
1 sibling, 1 reply; 7+ messages in thread
From: Matt Corallo @ 2026-04-14 22:29 UTC (permalink / raw)
To: Erik Aronesty; +Cc: bitcoindev
[-- Attachment #1: Type: text/html, Size: 6236 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Deactivating ECDSA/Schnorr
2026-04-14 22:29 ` Matt Corallo
@ 2026-04-14 22:39 ` Erik Aronesty
0 siblings, 0 replies; 7+ messages in thread
From: Erik Aronesty @ 2026-04-14 22:39 UTC (permalink / raw)
To: Matt Corallo; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 3363 bytes --]
Well, I guess we have to trust that the market isn't stupid and won't
invest in spurious or forged results. I guess that's rare enough.
Crypographically negligible.
On Tue, Apr 14, 2026 at 3:29 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:
> Firstly I want to echo everything conduition said but I want to raise one
> further point.
>
> You don’t get to decide. Nor do I. The market does.
>
> Both bitcoins will, without question, exist - one where insecure spend
> paths are disabled (with the exceptions conduition raises, and probably
> any more we can come up with [1])) and one where they are not, and the
> market will decide which it prefers.
>
> I’m quite confident the market is going to pick the side that has
> something like 100x less supply, especially if it avoids burning any coins
> to the maximum extent possible…the law of supply and demand doesn’t care
> all that much about our feelings on the matter.
>
> Matt
>
>
> [1] I’ve noted before we should allow for both seedphrase recovery schemes
> as well as a commit-before-Q-day-reveal-after scheme to allow anyone who
> has keys to non-seedphrase coins to retain ownership without having to go
> to chain. This may bee important, for example, for the owner of the patoshi
> coins.
>
> On Apr 14, 2026, at 14:51, 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
> <https://groups.google.com/d/msgid/bitcoindev/CAJowKgJcGTvkzjkRN3cd8LRkfazWycSp8p6oOd5D5dtEYRaB1w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
>
--
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/CAJowKgKQqRx9E-CMOSJGgOWBO9ew2RxxNOMH4WAh%3Dh3wOozEvw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6276 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Deactivating ECDSA/Schnorr
2026-04-14 21:59 ` Erik Aronesty
@ 2026-04-15 4:27 ` Alex
2026-04-15 9:37 ` Erik Aronesty
0 siblings, 1 reply; 7+ messages in thread
From: Alex @ 2026-04-15 4:27 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 9396 bytes --]
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 rather
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 <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
> 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 PM conduition <condu...@proton.me> 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 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
>> <https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI> 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 <er...@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+...@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/a058151d-3134-47e5-96c7-3f79f6dab5b2n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 16051 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] Deactivating ECDSA/Schnorr
2026-04-15 4:27 ` Alex
@ 2026-04-15 9:37 ` Erik Aronesty
0 siblings, 0 replies; 7+ messages in thread
From: Erik Aronesty @ 2026-04-15 9:37 UTC (permalink / raw)
To: Alex; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 10396 bytes --]
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 AM Alex <alexhultman@gmail.com> 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 rather
> 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 <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
>> 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 PM conduition <condu...@proton.me> 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 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
>>> <https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI> 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 <er...@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+...@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/a058151d-3134-47e5-96c7-3f79f6dab5b2n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/a058151d-3134-47e5-96c7-3f79f6dab5b2n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAJowKgKtiH_N8KLdOAi2TXfmt3_fDvHKnuoEoyrkMyMFYELqoA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 16886 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2026-04-15 15:22 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-04-14 18:37 [bitcoindev] Deactivating ECDSA/Schnorr Erik Aronesty
2026-04-14 20:25 ` 'conduition' via Bitcoin Development Mailing List
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox