From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: The limitations of cryptographic agility in Bitcoin
Date: Wed, 25 Feb 2026 04:00:44 -0800 (PST) [thread overview]
Message-ID: <823db0fa-08d3-4273-a428-04dc3d6da4d2n@googlegroups.com> (raw)
In-Reply-To: <fpr54OwSyhxOLkSM0ThB2HQN97XFCTL0c3oHbb9A-jmN0TiO6m38a-MqHYpHK9g4tokROwjJGFfFLjYtGluNRBg70PA4YThX9cMAiyw1B1k=@wuille.net>
[-- Attachment #1.1: Type: text/plain, Size: 16018 bytes --]
> Ironically, I think that actual "theft" (scare quotes or not) in this
context is much less concerning than uncertainty and fear about the
possibility of theft... and I realize this is getting closer to being a
statement about human psychology than technical properties. Let's say a PQC
scheme is added to Bitcoin in the next few years, and it sees some mild
adoption. Then we suddenly wake up one day, and the large majority of coins
in known-pubkey addresses have moved to a PQC address. Nobody knows who or
what did it, but it's widely assumed it was a CRQC. This might not affect
Bitcoin's value that much - after all, most of the damage is already done.
However, someone publishing a statement "I have a CRQC", signed by the same
set of pubkeys that held those coins, would likely send the market tumbling
down, and decimate Bitcoin's relevance for a long time.
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.
This is a big mess, but my reason for framing as in the previous paragraph
is to try to argue that that mess is 100% unavoidable even with the most
prudent behaviour and the most brilliant engineering. I am saying this to
argue against the idea that engineering decisions should take this
psychological effect, as you put it, into account. I have an intuition that
trying to address that will create bad outcomes.
> Because of that, if CRQCs or other EC-breaks become reality, or just the
fear about them becomes significant enough, I do believe that disabling EC
opcodes will be necessary in any economically-relevant surviving chain, due
to the millions of BTC that are unlikely to ever move. Note that I am *not*
arguing that "Bitcoin" *will*, *should*, or even *can* do this, and I'm
quite sure that the inherent confiscation required will make the result
uninteresting to me personally. It may be that such disabling only happens
in a fork that doesn't end up being called Bitcoin, or it may be that this
happens only after a CRQC has been demonstrated to exist. Still, given a
severe enough threat I think it is inevitable, and I think that this means
we shouldn't worry too much about what happens in chains in which EC is not
disabled while simultaneously EC is considered insecure: such chains will
be worthless anyway.
Just quoting the last paragraph of your OP here because, thanks for
clarification that you're not proposing a freeze, but I find this paragraph
ambiguous and I honestly don't understand it. First "disabling EC opcodes
will be necessary" (else worthless). Then "I am not arguing that this
happens and moreover it will be uninteresting to me." Then "such chains
will be worthless" referring to chains in which EC is not disabled. Does
this imply that you're only interested in the worthless chains? :)
Cheers,
AdamISZ
On Tuesday, February 17, 2026 at 5:09:59 PM UTC-3 Pieter Wuille wrote:
> Hi,
>
> Thank you all for the interesting comments. I want to respond to some of
> them, but feel like I need to clarify something first.
>
> *I am not proposing that coins are frozen in Bitcoin*, as I don't
> personally believe Bitcoin is interesting if it needs to give up that
> fundamental property. Rather, I am expressing the belief that levels of
> threat/fear can exist which cause the chain(s) in which large amounts of
> perceived-vulnerable coins remain to lose value to a devastating extent.
> This can take many forms. Maybe none of us are around anymore, and the
> people then hold different values. Maybe some people create a freezing fork
> before, or even after, a CRQC becomes reality, and that chain becomes more
> economically relevant. Maybe it's not called Bitcoin. Maybe nearly all(*)
> coins migrate to PQC addresses. Maybe CRQC fear fizzles out after some
> time. Maybe Bitcoin just doesn't survive CRQC fears.
>
> This is not a statement about what should or shouldn't be done about
> perceived-vulnerable coins. It is an observation that may however influence
> design around the introduction of other schemes:
>
> - Giving users the option to migrate to schemes with a different
> security assumption is not enough to remove that security assumption from
> the system. Bitcoin as a whole, and all its users including those who
> migrate, are and remain dependent on secp256k1 security as long as many(*)
> secp256k1-secured coins remain.
> - Users adopting schemes with a different security assumption at
> scale(*) is opting all users including those who do not migrate, into that
> security assumption.
> - We can design things for a future where no substantial(*) amount of
> coins are perceived to be vulnerable. Not because we're planning to freeze
> the coins that are, but because future chains in which such coins remain
> will lose value. I am not stating what the solution to get there is - I
> don't know - I am stating that we can operate under the premise that a
> solution will be found, because futures in which there isn't are
> uninteresting.
>
>
> I fundamentally disagree with this thesis you outlined here. The error in
> the second of the three quotes is subtle: it's not that rational users will
> not *want* others to migrate (of course, they will), it's that they will
> not *want* violation of property rights. See [1]
>
>
> Why not both? For Bitcoin to relevant, it needs to have value. One
> important component of that is differentiation with competing monetary
> systems, which includes properties like a fixed inflation schedule and
> inviolable property rights. But not having market fear wipe out your coins'
> value, even if you keep them, is a component too.
>
> I agree Bitcoin cannot promise anything about its exchange rate with
> real-world goods and services, or other currencies, but that doesn't mean
> this isn't relevant to its users. And as developers we ought to design for
> a system with properties we care about, but that doesn't mean we cannot
> make observations about the reality the system exists in.
>
>
> Suppose X% of the supply is held by negligent holders. Over time that X%
> will move away from those negligent holders to "thieves" (scare quotes
> because if literally held in outputs for which the unlocking script is
> publically derivable, it's debatable whether it's theft, even). The thieves
> will either be negligent themselves or not; in any case, over time, the
> coins will move to holders who are not negligent.
>
>
> Ironically, I think that actual "theft" (scare quotes or not) in this
> context is much less concerning than uncertainty and fear about the
> possibility of theft... and I realize this is getting closer to being a
> statement about human psychology than technical properties. Let's say a PQC
> scheme is added to Bitcoin in the next few years, and it sees some mild
> adoption. Then we suddenly wake up one day, and the large majority of coins
> in known-pubkey addresses have moved to a PQC address. Nobody knows who or
> what did it, but it's widely assumed it was a CRQC. This might not affect
> Bitcoin's value that much - after all, most of the damage is already done.
> However, someone publishing a statement "I have a CRQC", signed by the same
> set of pubkeys that held those coins, would likely send the market tumbling
> down, and decimate Bitcoin's relevance for a long time.
>
> This is also my response to Light's analogy with the systemic risk imposed
> by large amounts of coins held by exchanges. I think the ecosystem ought to
> be more concerned about that risk, but the fact that it isn't does not mean
> it also won't be concerned about the potential of large amounts of coins
> becoming vulnerable.
>
> Anyone who wants quantum security but is also afraid of fully trusting
> untested new algorithms like FancySig could easily use a hybrid locking
> script which requires both BIP340 AND FancySig signatures.
>
>
> This misses the point I was trying to make. If someone were truly hesitant
> about FancySig's security, then having them moving their own coins into a
> "BIP340 AND FancySig" outputs isn't a solution. They would would want
> *everyone*(*) who wants to use FancySig to stick to "BIP340 AND
> FancySig", i.e., this would be an argument against supporting FancySig-only
> outputs. And that is indeed a solution to the "people don't trust FancySig"
> problem, but it comes at a significant cost too.
>
> However, I only included the possibility of people distrustful in the
> other direction (fear of a new scheme) in my example to show the extreme
> incompatibility it may lead to. The point that (IMO) all Bitcoin users
> remain dependent on secp256k1 security as long as a substantial(*) amount
> of coins protected (solely) by it remain, is far more important.
>
> Disabling them like you propose?
>
>
> To be clear, I am not proposing that, and I'm not interested in discussing
> what Bitcoin should do.
>
> (*) = All of these statements are about some sufficiently large number of
> coins, which I don't know what it is.
>
> --
> Pieter
>
> On Friday, February 13th, 2026 at 11:20 AM, Pieter Wuille <
> bitco...@wuille.net> wrote:
>
> Hi all,
>
> A thread <https://groups.google.com/g/bitcoindev/c/7jkVS1K9WLo> was
> recently started on this list about cryptographic agility in Bitcoin. I
> believe there are important limitations around that idea, and wanted to
> offer my own perspective. It's more a philosophical consideration, and is
> not intended as an argument against (or for) any particular proposal today.
>
> The idea is giving users/wallets the ability to choose the cryptographic
> primitives used to protect their own coins, from a set of available
> primitives that may change over time. I think this ignores how important it
> is what *others do with their coins*. If others' coins lose value, for
> example due to fears about them becoming vulnerable to theft with
> cryptographic breakthroughs, so do your own due to fungibility, regardless
> of how well protected they are.
>
> As an extreme thought-experiment, imagine that tomorrow a new
> cryptographic signature scheme FancySig is published, with all the features
> that Bitcoin relies on today: small signatures, fast to verify, presumed
> post-quantum, BIP32-like derivation, taproot-like tweaking,
> multisignatures, thresholds, ... Further assume that within the next year
> or two, voices (A) start appearing arguing that such a scheme should be
> adopted, because it's the silver bullet the ecosystem has been waiting for.
> At the same time, another camp (B) may appear cautioning against this,
> because the scheme is new, hasn't stood the test of time, and isn't
> well-analyzed. These two camps may find themselves in a fundamental
> disagreement:
>
> - Camp (A), fearing an EC-break (CRQC or otherwise), wouldn't just
> want FancySig as an option - they would want (feasible or not) that *near-everyone
> migrates to it*, because the prospect of millions of BTC in
> EC-vulnerable coins threatens their own hodling.
>
>
> - Camp (B), fearing the possibility that FancySig gets broken soon,
> possibly even classically
> <https://www.quantamagazine.org/post-quantum-cryptography-scheme-is-cracked-on-a-laptop-20220824/>,
> don't want to just not use FancySig; they would want *near-nobody to
> migrate to it*, because the prospect of a potential break of FancySig
> threatens their own hodling.
>
> This is of course an extreme scenario, and in reality the divergence
> between camps may be much less incompatible, but I still think it's a good
> demonstration of the fact that *despite being a currency for enemies,
> Bitcoin essentially requires users to share trust assumptions in the
> cryptography, and its technology in general*.
>
> A small note aside: you can argue that it is possible for people to store
> coins insecurely, like in an OP_TRUE script output, or with private keys
> that are made public. I don't think this possibility affects the point
> above, because it is not about what possibilities exist, but which
> approaches people are likely to / asked to adopt. Nobody is incentivized or
> encouraged to store coins in an OP_TRUE.
>
> It is also good to ask what amounts are relevant here, to which I do not
> know the answer. Possibly, the prospect of 100k BTC becoming vulnerable to
> theft won't threaten the value of the other coins, while the prospect of
> 10M BTC becoming vulnerable may. Depending on where your belief about this
> lies, you may end up with very different conclusions. Still, to me it is
> clear that *some* threshold exists above which I would be uncomfortable
> with seeing that many coins move into an untrustworthy scheme, even if they
> are not my own coins.
>
> This brings us to the question then how at all Bitcoin users can migrate
> to new cryptography, because we cannot assume that secp256k1 will last
> forever. And I think the answer is essentially that it requires the entire
> ecosystem to change their assumptions. This does not mean that adding a new
> opt-in cryptographic primitive is infeasible or a bad idea; it just means
> that adding FancySig as an option is changing the collective security
> assumption from "secp256k1 is secure" to "secp256k1 AND FancySig are
> secure" once FancySig gets adopted at scale, and the discussion about
> adding new primitives should be treated with the gravity that entails. And
> it means that disabling secp256k1 EC operations (or near-everyone migrating
> to FancySig, but I think that is unlikely) is the only way to change the
> collective security assumption from "secp256k1 AND FancySig are secure" to
> "FancySig is secure".
>
> Because of that, if CRQCs or other EC-breaks become reality, or just the
> fear about them becomes significant enough, I do believe that disabling EC
> opcodes will be necessary in any economically-relevant surviving chain, due
> to the millions of BTC that are unlikely to ever move. Note that I am
> *not* arguing that "Bitcoin" *will*, *should*, or even *can* do this, and
> I'm quite sure that the inherent confiscation required will make the result
> uninteresting to me personally. It may be that such disabling only happens
> in a fork that doesn't end up being called Bitcoin, or it may be that this
> happens only after a CRQC has been demonstrated to exist. Still, given a
> severe enough threat I think it is inevitable, and I think that this means
> we shouldn't worry too much about what happens in chains in which EC is not
> disabled while simultaneously EC is considered insecure: such chains will
> be worthless anyway.
> --
> Pieter
>
>
>
>
--
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/823db0fa-08d3-4273-a428-04dc3d6da4d2n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 19766 bytes --]
next prev parent reply other threads:[~2026-02-25 12:24 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 [this message]
2026-02-25 14:39 ` Erik Aronesty
2026-02-25 22:43 ` Ethan Heilman
2026-02-26 2:07 ` Alex
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=823db0fa-08d3-4273-a428-04dc3d6da4d2n@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