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: Sun, 15 Feb 2026 07:12:57 -0500 [thread overview]
Message-ID: <da3265b4-e153-4c82-b0ed-e6bb021db7c6@mattcorallo.com> (raw)
In-Reply-To: <f9d2dd92-7fda-4d4c-a91d-02bc79460b69n@googlegroups.com>
On 2/14/26 7:39 AM, waxwing/ AdamISZ wrote:
> 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.)
No, its not just worse, it makes migration *impossible*. If we're talking about having a large
majority of coins (certainly ~all the "active" ones) move within a year or so, we'd have to first do
an immediate hard-fork to increase the block size to enable the migration to complete in time. In
the mean time fees will be insane.
> 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.
I don't really buy this. Sure, we won't be able to predict, with certainty, two years out, the exact
day on which the first private key will be calculated correctly from a public key. But we will, in
all likelihood, be able to predict two years out that a CRQC is somewhere between one and three
years away. In that case, again in many likely scenarios though not all, I really do not think that
disabling insecure (non-seedphrase) spend paths is somehow immoral or against the tao of bitcoin.
> 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 :)
Right again I think a decent part of our disagreement here is that we're imaging drastically
different scenarios. You (and I believe Odell and others) are imagining a world where there's a
secret government lab operating a CRQC and stealing Bitcoin. We aren't sure if its a CRQC that's
moving these coins, we have no strong public evidence of it, and there's debate as to whether to
burn coins in response to very weak evidence. In that scenario I'd likely agree with you.
However, I do not buy this scenario as at-all likely. Thus far we've seen QC research operate
largely in the open, with a small world of researchers publishing their progress for financing
reasons - the more you talk about the progress the more you can continue to raise money to keep
working on it. Even if some labs "go dark" after making substantial progress, we'll be aware of the
trajectory of their progress before they do and can make reasonable, if conservative, conclusions
about their timeline. Given the huge cost of these machines they largely haven't been the domain of
academic labs (where there is a long history of government research partnership), but rather private
enterprise, where there is an interest in public promotion to encourage the market to buy their stock.
Further, given consensus cryptography recommendations have been pushing supporting PQ schemes to
avoid a rush to upgrade in a decade and the adoption of such schemes, its not clear to me that, by
the time a CRQC is actually built, there will be all that much left waiting to upgrade (aside from,
of course, borderline-unmaintained projects). Keeping a government-secret CRQC when public QC
research is screaming "we're only a few years away" is probably not actually all that valuable - the
value is decrypting old, now-insecure communication you've already captured.
Finally, its worth noting that this "secret government lab CRQC" seems somewhat unlikely to run
around stealing large quantities of Bitcoin. Such a CRQC only has any value if it stays a secret,
and any Bitcoin you steal is likely to start generating rumors, which will intensify greatly as you
steal more. At some point you've basically tipped your hand and might as well just make it public.
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/da3265b4-e153-4c82-b0ed-e6bb021db7c6%40mattcorallo.com.
next prev parent reply other threads:[~2026-02-15 12:19 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
2026-02-15 12:12 ` Matt Corallo [this message]
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=da3265b4-e153-4c82-b0ed-e6bb021db7c6@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