From: Louise Michel <barsonneck@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Deactivating ECDSA/Schnorr
Date: Thu, 23 Apr 2026 01:46:24 -0700 (PDT) [thread overview]
Message-ID: <b6a90e69-513b-4f6f-91dd-1de8a4d9d1edn@googlegroups.com> (raw)
In-Reply-To: <CAJowKgJcGTvkzjkRN3cd8LRkfazWycSp8p6oOd5D5dtEYRaB1w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3608 bytes --]
Erik -
You were right to balk at some of the ideas that have been brought into the
milieu around Bitcoin. There is no acceptable number of UTXOs to confiscate
or lock out in Bitcoin. Outputs should continue to function unimpeded in
the way they did when they were first inscribed in the blockchain. It is
the prerogative of the users to decide if, when, how, and for what reason
they move and safeguard their value, not just because it is their property.
And it is a good idea for users to be informed and educate themselves about
the features and risks of the various tools and output types that allow
them to do so.
Certainly, new alternatives are worth exploring, but no options are without
tradeoffs. Bitcoin users should think carefully about what these are and
should evaluate for themselves the alternatives and their own threat
models. Ironically, the lesson of the DAO Hack might as well be that clever
-- but ultimately misguided and mis-implemented -- mechanisms have the
potential to cripple a cryptocurrency.
Of course, some users have lost access to their keys, or may simply refuse
to move their bitcoin, and some powerful cryptanalysts from the future may
one day recover keys and steal value (or maybe they won't). Developing
options for such a future is clearly a high priority for a subset of
Bitcoin users, but forks have to be carefully regarded because they are
highly consequential.
Unlike Ethereum, Bitcoin is an immutable chain. In Bitcoin, history doesn't
get re-written and consensus valid transactions that pay a market fee can
be included in a future block. Opting others into schemes they did not
consent to ex post facto is misguided at best. There may come a day when it
no longer makes sense to create new, legacy output types, and we have seen
that the market could just as well handle this. Virtually no one creates
P2PK outputs today. Still, no threat justifies retroactively restricting,
disabling, or stealing the property and value of others.
As M. Corallo points out, the market will ultimately decide.
Louise
On Tuesday, April 14, 2026 at 12:51:06 PM UTC-6 Erik Aronesty 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/b6a90e69-513b-4f6f-91dd-1de8a4d9d1edn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4821 bytes --]
prev parent reply other threads:[~2026-04-28 20:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
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-19 9:03 ` Ali Sherief
2026-04-14 22:29 ` Matt Corallo
2026-04-14 22:39 ` Erik Aronesty
2026-04-15 10:02 ` Alex
2026-04-23 8:46 ` Louise Michel [this message]
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=b6a90e69-513b-4f6f-91dd-1de8a4d9d1edn@googlegroups.com \
--to=barsonneck@gmail.com \
--cc=bitcoindev@googlegroups.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