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.