From: Matt Corallo <lf-lists@mattcorallo.com>
To: waxwing/ AdamISZ <ekaggata@gmail.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
Date: Thu, 12 Feb 2026 14:35:41 -0500 [thread overview]
Message-ID: <f0a2f902-2813-40f3-91ca-597ddcce1ed0@mattcorallo.com> (raw)
In-Reply-To: <efa3dd60-84c2-48ea-9fc7-ae5057590cb9n@googlegroups.com>
On 2/12/26 10:36 AM, waxwing/ AdamISZ wrote:
> > For what its worth I do not see a scenario where a decision ultimately made by the market will
pick
> the fork side with materially, say 5-10x higher, supply, over the side with lower supply...supply
> and demand is king, especially with the "confiscatory" nature is basically nil as ~all wallets today
> use seedphrases, which could still be spent with a ZK proof-of-seedphrase :).
>
> This line of reasoning is wrong imo.
>
> If supply and demand is king, why not just delete supply as much as possible? No more mining?
> Arbitrary freezing of various actors' coins (but with warning! so it's only confiscation in quotes,
> right?).
>
> Hypothetical: someone proposes a fork which freezes all coins residing at utxos with addresses
> containing "234" (insert technical description as appropriate - you get the idea). It'll be a bit
> like the rules about driving into town with various letters in your license plate, though, a bit
> more permanent :) The vast majority will benefit economically from the lazy few who don't notice,
> since if they pay attention, they can hop out of the frozen addresses with time to spare, so why
> doesn't it happen?
>
> Obviously, ridiculous examples, but .. point stands in general:
>
> It's a curious kind of self-referential. The "market" here is really the set of holders, their
> *short term* interest is to grab any they can, but their long term interest is to have their stash
> keep its value. There is *nothing* that will destroy bitcoin's value more effectively (certainly not
> technical issues like bugs, certainly not an unexpected unlock of a big amount of coins to be moved
> in the market) than an event that questions the "private property promise":
>
> 1/ coin inflation schedule is set in stone;
> 2/ if you can cryptographically validate a transfer, bitcoin will let you do it, i.e. you can always
> spend your own money;
> 3/ if you "locked" a utxo with a certain ruleset in the past, that ruleset will still be active and
> let you spend in future, i.e. you can't be locked out of your own money.
>
> Bitcoin is the only digital asset in the world for which those assertions are credible; it has never
> yet violated them, and imo it's the thing that keeps it unique and important (PoW ties in; it's
> another aspect of the same rigid adherence to no controlling entities).
>
> That's why both this idea and Peter Todd's tail emission idea, both high quality engineering-safety
> thinking, will not happen, in my opinion.
I obviously agree with you at a high level - the value of Bitcoin derives from its (attempt at)
trustlessness and any attempts to break that will necessarily result in the market rejecting them
precisely because they break the exact thing that gives Bitcoin value.
Its also hard to analyze this because it depends so much on the very exact scenario we're talking
about. There are indeed certainly scenarios I can imagine where I think the market would prefer to
not disable insecure spend paths. But at the risk of using an equally absurd example as yours,
Imagine we discover a breakthrough in refrigeration technology that we've missed for 200 years
tomorrow (or a room temperature superconductor, or...) plus a few other major engineering
breakthroughs and we're now on track to have a CRQC in 2-3 years instead of 15-20, and oh in 6
months we discover that they're not just gonna be buildable soon but pretty easy to build farms and
they'll be able to calculate a private key in seconds. Yes, we can stand on principle and watch as
the CRQCs steal all the bitcoin and sell them to recoup their investment, but the market is
obviously not going to value that because the thing that's left isn't recognizable as Bitcoin - its
just some weird cryptographic scheme where tokens are shifting around all the time and everyone is
stealing from everyone else.
There would certainly be market participants (like you, I guess :p) that try to hold on to the
original Bitcoin and might even invest some money in buying more (from the CRQC-operators). And the
insecure-spend-paths-disabled fork would probably have somewhat less value than the original as a
result. But the original chain would without question have nearly zero value, and the fork might
have some.
Now, this scenario maybe seems exaggerated, but actually I think its equivalent to the most likely
outcome. Not that I think we'll see multiple major 100-year physics breakthroughs soon, but rather
if we see a CRQC in the next 10-20 years, that the state of Bitcoin wallet adoption of PQ spend
paths will be only marginally better than it is today. Sure, maybe 50% of wallets have upgraded, but
that's not enough to have any outcome materially different from the above.
Finally, more philosophically, I disagree that these are somehow equivalent. Yes, in stated
black-and-white principles it violates the "ethics of Bitcoin", but that the *alternative does too*.
Leaving the coins to be stolen by a CRQC almost equally violates the "ethics of Bitcoin" - the
rightful owner of the coins, the one that created the private key and did not leak that private key
to anyone else no longer has the coins! but...
> > ZK proof-of-seedphrase :).
>
> Oh cool, that's a good point. Ethan's counterpoint is good too, that we would need a consensus rule
> and that's v. hard, but: my spidey sense is tingling a bit about whether people might find tricks to
> avoid it: if you consider the very clever tricks recently discovered around Glock, ArgoMAC and so
> on, they enable gating txs behind ZKP schemes w/o new consensus but what we're talking about here is
> way more narrowly defined than the larger problem they're trying to solve, which might support being
> optimistic ...).
I think this makes the philosophical point more stark! Now the options in front of the future
Bitcoin community aren't "burn the coins or let the CRQC-operator steal them" then options in front
of the future Bitcoin community are "burn some of the coins and let a probably-majority of the
rightful owners claim them, or let the CRQC-operator steal all of them". I cannot justify why the
second option is somehow more ethical or more in line with building the best, most trustless money
on the planet.
Matt
--
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/f0a2f902-2813-40f3-91ca-597ddcce1ed0%40mattcorallo.com.
next prev parent reply other threads:[~2026-02-13 16:21 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 14:20 Ethan Heilman
2026-02-10 8:53 ` Jonas Nick
2026-02-10 16:44 ` Ethan Heilman
[not found] ` <CAJowKg+WJLAJoMhyhVfkC9OSdks5jBieDWty9ce-Qju-84URFA@mail.gmail.com>
2026-02-10 23:13 ` Ethan Heilman
2026-02-11 0:19 ` Erik Aronesty
2026-02-11 2:40 ` Ethan Heilman
2026-02-11 7:25 ` Erik Aronesty
2026-02-11 16:37 ` Ethan Heilman
2026-02-17 4:13 ` 'conduition' via Bitcoin Development Mailing List
2026-02-17 7:39 ` 'conduition' via Bitcoin Development Mailing List
2026-02-19 14:35 ` Garlo Nicon
2026-02-20 1:41 ` Alex
2026-02-20 18:48 ` Erik Aronesty
2026-02-23 14:00 ` 'conduition' via Bitcoin Development Mailing List
2026-02-23 19:08 ` Erik Aronesty
2026-02-23 21:42 ` Ethan Heilman
2026-02-24 0:12 ` Alex
2026-02-25 10:43 ` Javier Mateos
2026-02-26 13:24 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-02-26 15:51 ` Matt Corallo
2026-02-27 15:18 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-02-27 19:31 ` 'conduition' via Bitcoin Development Mailing List
2026-03-01 12:24 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-03-01 21:28 ` Alex
2026-02-11 18:53 ` Matt Corallo
2026-02-11 22:57 ` Ethan Heilman
2026-02-12 14:55 ` Matt Corallo
2026-02-12 15:35 ` Alex
2026-02-12 19:20 ` Matt Corallo
2026-02-12 18:08 ` Ethan Heilman
2026-02-12 19:13 ` Matt Corallo
2026-02-12 20:35 ` Ethan Heilman
2026-02-12 20:43 ` Matt Corallo
2026-02-12 15:13 ` Alex
2026-02-12 19:16 ` Matt Corallo
2026-02-12 15:36 ` waxwing/ AdamISZ
2026-02-12 19:35 ` Matt Corallo [this message]
2026-02-12 19:43 ` Matt Corallo
2026-02-14 12:39 ` waxwing/ AdamISZ
2026-02-15 12:12 ` Matt Corallo
2026-02-10 21:51 ` 'Brandon Black' via Bitcoin Development Mailing List
2026-02-10 22:19 ` Ethan Heilman
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=f0a2f902-2813-40f3-91ca-597ddcce1ed0@mattcorallo.com \
--to=lf-lists@mattcorallo.com \
--cc=bitcoindev@googlegroups.com \
--cc=ekaggata@gmail.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