From: sadiq Ismail <ask4ismailsadiq@gmail.com>
To: Light <bitcoin-dev@lightco.in>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin
Date: Mon, 16 Feb 2026 10:59:29 +0100 [thread overview]
Message-ID: <CAHR1cdX_hFGvOqFg-HwLJ=E06z2SFz_3r-XJzBe4+cmR8Ue3ng@mail.gmail.com> (raw)
In-Reply-To: <088b5efd-7ba5-48f1-97f6-eb5881f5fd14@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 14880 bytes --]
Hi list, light
I want to clarify a point in your argument.
> I don't believe the predominant "collective security assumption" is that
"secp256k1 is secure". Everyone using bitcoin, going all the way back to
the genesis block, has known (or should know) that secp256k1 is vulnerable
to a CRQC, and therefore secp256k1 is not unconditionally secure. So I
would rephrase the assumption to be that "secp256k1 is currently secure,
and if it is ever at risk of being broken, there is a large incentive for a
viable alternative to be discovered, implemented, and adopted by anyone who
is concerned about this risk". Note that this assumption does not, and
cannot, preclude the possibility that other users store their coins in
insecure ways, even en masse (as shown empirically by the above example of
millions of coins held by centralized custodians).
When we say a cryptographic scheme is "secure", that has a precise meaning:
there is no known "efficient" algorithm in the sense of probabilistic and
polynomial time PPT that breaks it. By that standard, secp256k1 is still
secure today.
A CRQC would break it, but a CRQC is not an "efficient" algorithm in this
sense, and the same premise underlies the security arguments for any
post-quantum scheme as well. So until we see an efficient PPT algorithm
that breaks secp256k1, saying it is "secure" is still technically correct,
and the proposed rephrasing isn't necessary.
Best,
Sadiq
On Fri, Feb 13, 2026 at 11:13 PM Light <bitcoin-dev@lightco.in> wrote:
> Hi Pieter,
>
> > 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.
>
> While it is true that "nobody is incentivized or encouraged to store coins
> in an OP_TRUE", I believe your argument is incomplete because it is missing
> a more realistic mass-theft vector, which is that as of today approximately
> 2.5 million BTC is held by less than two dozen centralized custodians.[1]
> These coins are at a real risk of theft, due to both private threat actors
> e.g. thefts from MtGox, Bitfinex, and scores of others, as well as public
> threat actors e.g. EO 6102.[2][3]
>
> Despite this very real and large-scale theft risk, nobody is proposing
> that we freeze coins held on exchanges. And yet some people find this
> (freezing coins) to be a reasonable response to the risk of cryptographic
> breaks (approximately 6.5 millions coins at risk).[4][5] Curious! But I
> digress.
>
> > 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.
>
> I don't believe the predominant "collective security assumption" is that
> "secp256k1 is secure". Everyone using bitcoin, going all the way back to
> the genesis block, has known (or should know) that secp256k1 is vulnerable
> to a CRQC, and therefore secp256k1 is not unconditionally secure. So I
> would rephrase the assumption to be that "secp256k1 is currently secure,
> and if it is ever at risk of being broken, there is a large incentive for a
> viable alternative to be discovered, implemented, and adopted by anyone who
> is concerned about this risk". Note that this assumption does not, and
> cannot, preclude the possibility that other users store their coins in
> insecure ways, even en masse (as shown empirically by the above example of
> millions of coins held by centralized custodians).
>
> An alternative where "secp256k1 OR FancySig is secure" seems strictly
> preferable to me (assuming we have some reasonable degree of confidence in
> the security of FancySig at the time of activation) than relying only on
> "secp256k1 is secure".
>
> As an aside, I note that because it has been known since before bitcoin
> even launched that secp256k1 is vulnerable to a CRQC, we cannot rule out
> the possibility that the people who leave their coins in CRQC-vulnerable
> addresses -- even after QR addresses are made available -- aren't doing so
> intentionally, as a kind of bounty for developing a CRQC. Freezing these
> coins would violate their intentions. This is just one example of the
> ethical problems associated with such proposals.
>
> A perhaps even more fundamental "collective assumption" of bitcoin users
> is that "a redeem script that was valid at the time that a UTXO was
> encumbered will always remain valid". This is fundamental to bitcoin's
> nature as p2p electronic cash. If users woke up one day no longer able to
> assume that their redeem scripts would remain valid, then they would not be
> able to rely on bitcoin to store value over time and the system would
> quickly collapse. Thus, any proposal to disable features in a way that
> freezes coins is a proposal to destroy bitcoin.
>
> Bitcoin can survive a temporary price dump, if that's what ends up
> happening with vulnerable coins. Bitcoin cannot survive a violation of the
> fundamental assumption that redeem scripts for existing UTXOs will always
> remain valid, and certainly not a violation at the scale that you describe.
>
> Regards,
> Light
>
> [1] https://www.coinglass.com/Balance
> [2] https://bitcointalk.org/index.php?topic=5090869.0
> [3] https://en.wikipedia.org/wiki/Executive_Order_6102
> [4] https://github.com/bitcoin/bips/pull/1895
> [5] https://youtu.be/a_B8BnwagEU&t=150
>
> On Fri, Feb 13, 2026, at 11:20 AM, Pieter Wuille 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 <mailto:
> bitcoindev%2Bunsubscribe@googlegroups.com>.
> > To view this discussion visit
> >
> https://groups.google.com/d/msgid/bitcoindev/THqOJuI_s5C8B9jkklN73BB_Hzb9SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh8NxxYbXwv4v6ikpStguW-QEvef4WgBZ7AQDz00P0st91FMA%3D%40wuille.net
> > <
> https://groups.google.com/d/msgid/bitcoindev/THqOJuI_s5C8B9jkklN73BB_Hzb9SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh8NxxYbXwv4v6ikpStguW-QEvef4WgBZ7AQDz00P0st91FMA%3D%40wuille.net?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/088b5efd-7ba5-48f1-97f6-eb5881f5fd14%40app.fastmail.com
> .
>
--
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/CAHR1cdX_hFGvOqFg-HwLJ%3DE06z2SFz_3r-XJzBe4%2BcmR8Ue3ng%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 18207 bytes --]
next prev parent reply other threads:[~2026-02-16 22:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 16:20 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 [this message]
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
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='CAHR1cdX_hFGvOqFg-HwLJ=E06z2SFz_3r-XJzBe4+cmR8Ue3ng@mail.gmail.com' \
--to=ask4ismailsadiq@gmail.com \
--cc=bitcoin-dev@lightco.in \
--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