Deactivating ECDSA/Schnorr

[Erik Aronesty]

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. 

[conduition]

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

--
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.

[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.

[Matt Corallo]

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 <er...@q32.com> wrote:



[Alex]

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>)

[Erik Aronesty]

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.

[Erik Aronesty]

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

To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/a058151d-3134-47e5-96c7-3f79f6dab5b2n%40googlegroups.com.