From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: 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: Sat, 14 Feb 2026 04:39:45 -0800 (PST) [thread overview]
Message-ID: <f9d2dd92-7fda-4d4c-a91d-02bc79460b69n@googlegroups.com> (raw)
In-Reply-To: <f0a2f902-2813-40f3-91ca-597ddcce1ed0@mattcorallo.com>
[-- Attachment #1.1: Type: text/plain, Size: 10499 bytes --]
Hi Matt, on this point:
> 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.
For sure. It's unlikely but it's certainly *not* out of scope. Basically
the "it happens fast" scenario.
I don't see how it changes anything about the general principles. It's just
worse. People who are active
are going to move their coins to new outputs. People who are dead or lost
the keys are not. (People who
have locked them in a way that they are 100% inaccessible for 5+ years are
of course the most unfortunate case here, perhaps worth discussing
separately.)
It's just a worse (in terms of turbulence) version of the (far, far more
likely) slow scenario.
Look, I get the "yuck" reflex and the "this is ridiculous" reflex; if
something is patently obviously "open" and previously wasn't, then
"obviously" we should just lock it up - or do something, anyway. But the
real world, whether it's a 2 year time frame or the more likely 20-50++
year timeframe, doesn't have this clean epistemology: we won't *know for
sure* when the world shifts from "outputs are safe" to "this stuff is
claimable by anyone with the machine". Even *if* it isn't all developed in
super-secret (it probably will be), we still won't know. That's why I said
"perhaps worth discussing separately" for timelocks; there you have
objective, public-verifiable "this is frozen" status. The "secure" vs
"insecure" status simply will not be knowable in advance. That makes any
engineering decisions that even *might* violate private property rights
completely unworkable.
> we can stand on principle and watch as
the CRQCs steal all the bitcoin and sell them to recoup their investment
yes, this is precisely what you would have to do (except as per previous
paragraph, it will *not* be obvious, even if large movements occur - what
if someone actually owns the coins and is trying to trick the market?).
Assuming the thesis is correct (that it's CRQCs doing it), then the coins
at that point are held in completely insecure outputs. Who has the right to
take them? Answer: anyone who's fast enough, just like a coin whose private
key is "123" or similarly insecure, gets taken all the time. Should the
network freeze insecure private keys when it sees them?
The problem is not the *reasoning* of safety. The problem is that, more
than safety, principles matter, and unlike Groucho Marx, we don't have any
others :)
On Friday, February 13, 2026 at 1:21:28 PM UTC-3 Matt Corallo wrote:
>
>
> 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/f9d2dd92-7fda-4d4c-a91d-02bc79460b69n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 11579 bytes --]
next prev parent reply other threads:[~2026-02-14 21:39 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
2026-02-12 19:43 ` Matt Corallo
2026-02-14 12:39 ` waxwing/ AdamISZ [this message]
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=f9d2dd92-7fda-4d4c-a91d-02bc79460b69n@googlegroups.com \
--to=ekaggata@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