From: Alex <alexhultman@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: The limitations of cryptographic agility in Bitcoin
Date: Wed, 25 Feb 2026 18:07:24 -0800 (PST) [thread overview]
Message-ID: <188bb1b6-e86e-468b-b09b-ace7e084794dn@googlegroups.com> (raw)
In-Reply-To: <CAEM=y+W_KDes6WMWc-MtTptKHeEqrstnyi4fdxeEs1SstXQSKg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 6428 bytes --]
> bitcoin *cannot* respond to claims that unicorns exist with protocol
change
This is not claiming that a unicorn is currently existing, it's claiming
the obviously-under-construction unicorn eventually having the chance of
becoming a unicorn. There are many famously wrong tech. predictions
throughout history (and they are hilarious by today's knowledge). The only
thing you can know for sure is that you know nothing at all, and so
considering both possibilities and their risk implications:
1. There is never any such thing as a quantum computer (unicorn); it
renders the optional PQC script spend path and PQ signatures unnecessary
bloat to Bitcoin (and the entire tech and military industry) and makes
Schnorr signatures slightly more expensive (script spend path as a
necessity; no key spend path implied)
2. There is eventually such a thing as a quantum computer, rendering
Bitcoin worthless or critically injured, and/or in need of the first total
outage and network halting (no blocks, no fees, no action) in order to try
and duct tape existing wallets to new PQC wallets using hundreds of KB of
zero knowledge proofs that are significantly more costly to validate and
store (and therefore basically DOS vulnerabilities to Bitcoin nodes) per
individual UTXO (which nobody will be reasonably able to afford) and so the
network essentially becomes useless for anything more than the handful of
mega whales that can afford such a move.
Introducing SLH-DSA now (or any such bloated PQC) means you have the
_optionality_ to seamlessly migrate your funds at a cost of basically 10
USD per transaction (if and only if you do chose to use SLH-DSA in the
first place). SLH-DSA is bloated, yes, but it is from what I have gathered
MASSIVELY less bloated than a ZK proof used to migrate funds after the
unicorn.
onsdag 25 februari 2026 kl. 23:46:02 UTC+1 skrev Ethan Heilman:
> > the physics is cool, but the engineering needed to scale may still well
> be impossible in the physical world. bitcoin *cannot* respond to claims
> that unicorns exist with protocol change
>
> We may never have a CRQC that's a real but unlikely possibility. Let's say
> you believe in your heart of hearts that CRQCs are impossible. Algorithm
> agility is still critical to the future of Bitcoin in such a world.
>
> To quote from Guidelines for Cryptographic Algorithm Agility and
> Selecting Mandatory-to-Implement Algorithms (RFC 7596)
> <https://datatracker.ietf.org/doc/html/rfc7696>
>
> "Cryptographic algorithms age; they become weaker with time. As new
> cryptanalysis techniques are developed and computing capabilities improve,
> the work required to break a particular cryptographic algorithm will
> reduce, making an attack on the algorithm more feasible for more
> attackers. While it is unknown how cryptoanalytic attacks will evolve, it
> is certain that they will get better."
> ...
> Protocol designers need to assume that advances in computing power or
> advances in cryptoanalytic techniques will eventually make any algorithm
> obsolete."
>
> A CRQC is one of many threats to the cryptography used in Bitcoin
> signatures. If we want Bitcoin to be a secure store of value over at least
> one human lifetime, then algorithm agility is a must. Part of that security
> is that your coins don't get stolen due to cryptographic weaknesses, part
> of that security is that know your coins are unlikely to get stolen,
> i.e. epistemological problem.
>
>
> On Wed, Feb 25, 2026 at 10:03 AM Erik Aronesty <er...@q32.com> wrote:
>
>>
>> I'm in, I think, a group of people now, that have pointed this out, here
>>> and elsewhere ... I like to call it the "epistemological problem" because,
>>> why use short words when a long one will do :) The scenario is all the
>>> worse because (as, again, has been pointed out before): the "I have a CRQC"
>>> signed message you mention is (more likely), or can be, someone who has
>>> just placed a short in the market, rather than an actual CRQC holder. The
>>> point is that during a period from "bitcoin doesn't have PQ algos" to
>>> "bitcoin has PQ algos" the transition will always be essentially 100%
>>> opaque; every honest action of moving to safety looks identical, onchain,
>>> to theft.
>>>
>>
>>
>> a key that is crackable in-advance of bitcoin being cracked, so that we
>> know quanutm is "real".
>>
>> 1. deterministic random elliptic-curve address on a much
>> smaller-bit-strength curve, but not so much smaller that classical attacks
>> are feasable
>> 2. bounty for the solution enforceable with a smart contract
>> 3. refusal to accept that "i have a CRQC" message unless this
>> well-known-key is used, because anything else is likely a scam (private key
>> known in advance)
>> 4. understanding that cracking a 180-bit key only gives us 6 months to a
>> year of quantum engineering scaling to fix bitcoin
>> 6. published plan to move quickly as needed
>>
>> the physics is cool, but the engineering needed to scale may still well
>> be impossible in the physical world. bitcoin *cannot* respond to claims
>> that unicorns exist with protocol changes. but we *can* respond with a bip
>> that allows us to rapidly deploy defense against unicorn horns once
>> irrefutable evicence arrives that they exist.
>>
>> --
>>
> 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/CAJowKgJwq88yfJEQzZ%2Bv-33EtEuYif1y6qsXtyoRyk2V%2B44cww%40mail.gmail.com
>> <https://groups.google.com/d/msgid/bitcoindev/CAJowKgJwq88yfJEQzZ%2Bv-33EtEuYif1y6qsXtyoRyk2V%2B44cww%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/188bb1b6-e86e-468b-b09b-ace7e084794dn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8602 bytes --]
prev parent reply other threads:[~2026-02-26 3:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 16:20 [bitcoindev] " Pieter Wuille
2026-02-13 19:39 ` Erik Aronesty
2026-02-13 21:50 ` Light
2026-02-13 22:52 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-02-14 3:43 ` Light
2026-02-17 14:11 ` Garlo Nicon
2026-02-16 9:59 ` sadiq Ismail
2026-02-13 21:54 ` Ethan Heilman
2026-02-14 12:02 ` [bitcoindev] " waxwing/ AdamISZ
2026-02-17 3:49 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
2026-02-17 20:04 ` [bitcoindev] " Pieter Wuille
2026-02-19 7:22 ` 'conduition' via Bitcoin Development Mailing List
2026-02-25 12:00 ` waxwing/ AdamISZ
2026-02-25 14:39 ` Erik Aronesty
2026-02-25 22:43 ` Ethan Heilman
2026-02-26 2:07 ` Alex [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=188bb1b6-e86e-468b-b09b-ace7e084794dn@googlegroups.com \
--to=alexhultman@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