* Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin
2026-02-13 16:20 [bitcoindev] The limitations of cryptographic agility in Bitcoin Pieter Wuille
@ 2026-02-13 19:39 ` Erik Aronesty
2026-02-13 21:50 ` Light
` (4 subsequent siblings)
5 siblings, 0 replies; 16+ messages in thread
From: Erik Aronesty @ 2026-02-13 19:39 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 7953 bytes --]
As a thought experiment, it's interesting, and I agree. One of the main
complaints about covenants, for example, isn't that they aren't opt-in -
they are, and most people understand that they don't enable special
concessions more than multisig. Instead, it's because of the perception of
Nth order effects around their usage in technologies like defi and
contracts. We have all heard the headlines about evm hacks and defi
hacks, and, to some extent, these steer "hard money" proponents toward
Bitcoin more than any arguments around decentralization.
However, "Q-day" may never arrive—and might just be a physics experiment
that proves finite energy is real. What's more, FancySig1 was already
proven insecure/broken. We are now on FancySig3.
Cloudflare has decided to ship hybrid FancySig3/ECC, requiring both for all
SSL. This approach would mitigate your concerns fully. You cannot use
either option alone. You have to use both. Sure, it's annoying. But if
we choose a sufficiently efficient FancySigN, we can build a system
guaranteed to satisfy the risks of both the new system and the old one.
In your extreme thought experiment, the only rational choice is "use both".
On Fri, Feb 13, 2026 at 8:23 AM Pieter Wuille <bitcoin-dev@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/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/CAJowKg%2B3pf801tggYf_S0rH4d%2BHr8mW7-oG-9dwckNX9tTB4%2Bg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9282 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin
2026-02-13 16:20 [bitcoindev] The limitations of cryptographic agility in Bitcoin 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-16 9:59 ` sadiq Ismail
2026-02-13 21:54 ` Ethan Heilman
` (3 subsequent siblings)
5 siblings, 2 replies; 16+ messages in thread
From: Light @ 2026-02-13 21:50 UTC (permalink / raw)
To: bitcoindev
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.
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin
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-16 9:59 ` sadiq Ismail
1 sibling, 1 reply; 16+ messages in thread
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2026-02-13 22:52 UTC (permalink / raw)
To: Light; +Cc: bitcoindev
Hi John,
Without commenting on the (un)desirability of freezing vulnerable coins (i largely share your
concerns, but haven't yet formed an opinion of my own), i would like to surface one issue in part of
your reasoning.
You state:
> 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.
That's quite the sweeping claim, but it's trivially incorrect, or it would make any soft fork
impossible. This is both disproven historically, since Bitcoin made previously-valid redeem scripts
invalid on at least 5 occasions (post Satoshi), and incompatible with many soft fork proposal,
including your own.
As long as soft forks are tolerated, a degree of nuance needs to be introduced to take into account
reasonable expectations from users, and not disabling potentially-vulnerable EC opcodes as opposed
to upgrade hooks needs to be defended on its own merit rather than appealing to the destruction of
Bitcoin. (And to be clear i think a strong case can be made in this regard, this is not to be
interpreted as an argument in favour of The Big Freeze.)
Best,
Antoine
On Friday, February 13th, 2026 at 5: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/Jks1E9HcmXK_xrxh-yeqn-uTH6FVyGvVVowbDSr5h3C0-J_7s-8YKK4dlKO77YjQLXw8rean8p2h6Feb72Qctky2xDLgxfZaJfFJiWwhWNg%3D%40protonmail.com.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin
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
0 siblings, 1 reply; 16+ messages in thread
From: Light @ 2026-02-14 3:43 UTC (permalink / raw)
To: Antoine Poinsot; +Cc: bitcoindev
Hi Antoine,
> it would make any soft fork impossible.
This is probably tangential to the topic of the thread, but since you bring up the confiscatory potential of soft forks in general I will go ahead and plant my flag here by saying that if given the choice between doing a soft fork but with a high likelihood of freezing coins, or doing a hard fork to avoid freezing coins, I would pick the hard fork every time.
> As long as soft forks are tolerated, a degree of nuance needs to be
> introduced to take into account reasonable expectations from users
I believe what I wrote accounts for this nuance. As far as I'm aware, no soft fork ever intentionally froze coins; on the contrary, my observation has been that protocol developers are exceedingly cautious to avoid this side effect.[1] It appears their efforts have not been in vain, since broad confidence in the security of bitcoin property rights remains intact, as evidenced by the millions of people who continue to use bitcoin to store value.
> and incompatible with many soft fork proposal, including your own.
I'm not sure what you're referencing here; I am not an author of any soft fork proposals.
[1] Apparently the P2SH soft fork did freeze a total of 0.044 BTC: https://bitcoin.stackexchange.com/a/115804
This seems unintentional since the coins were created after the activation client was published and shortly before the fork activated, and I could not find any record of alarms being raised at the time about the prospect of freezing these coins.
On Fri, Feb 13, 2026, at 5:52 PM, Antoine Poinsot wrote:
> Hi John,
>
> Without commenting on the (un)desirability of freezing vulnerable coins
> (i largely share your
> concerns, but haven't yet formed an opinion of my own), i would like to
> surface one issue in part of
> your reasoning.
>
> You state:
>> 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.
>
> That's quite the sweeping claim, but it's trivially incorrect, or it
> would make any soft fork
> impossible. This is both disproven historically, since Bitcoin made
> previously-valid redeem scripts
> invalid on at least 5 occasions (post Satoshi), and incompatible with
> many soft fork proposal,
> including your own.
>
> As long as soft forks are tolerated, a degree of nuance needs to be
> introduced to take into account
> reasonable expectations from users, and not disabling
> potentially-vulnerable EC opcodes as opposed
> to upgrade hooks needs to be defended on its own merit rather than
> appealing to the destruction of
> Bitcoin. (And to be clear i think a strong case can be made in this
> regard, this is not to be
> interpreted as an argument in favour of The Big Freeze.)
>
> Best,
> Antoine
>
>
> On Friday, February 13th, 2026 at 5: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/8692bba5-47d0-49f4-9b7f-ccb564cc3630%40app.fastmail.com.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin
2026-02-14 3:43 ` Light
@ 2026-02-17 14:11 ` Garlo Nicon
0 siblings, 0 replies; 16+ messages in thread
From: Garlo Nicon @ 2026-02-17 14:11 UTC (permalink / raw)
To: Light; +Cc: Antoine Poinsot, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 18873 bytes --]
> Apparently the P2SH soft fork did freeze a total of 0.044 BTC
If you mean 3Dnnf49MfH6yUntqY6SxPactLGP16mhTUq, then 0.04 BTC out of 0.05
BTCs is spendable. Because BIP-16 didn't confiscate old coins. For example:
0200000004c0017861860c77ec3a0b79252d7cd0b72d01857cc0ccb4e5defa55ea986163d001000000030e0020fdffffff1afa06d85986741e13ea1a46f09af2ea99979d9a9beb6001476ce14b2d9eb59a00000000030e0020fdffffff219a758936e67eeb55d888a932bdfe9bf0a1b84e03d15c5d12c4f16120c98f6500000000030e0020fdffffffeedc66625b962c85acd2812e06663130d8a90a90c204a749e2095193445a0b5100000000030e0020fdffffff0118053d0000000000160014aca46e72322504d0b87bc0317b540fb70abf2f6700000000
Of course, it is non-standard, and even Slipstream wouldn't help you,
because no miner would risk a block for 0.04 BTC (if you use 100% fees),
and because many parsers will crash on "0e0020", and mark it as "invalid",
even if pre-P2SH transactions are spendable in the old way.
sob., 14 lut 2026 o 09:15 Light <bitcoin-dev@lightco.in> napisał(a):
> Hi Antoine,
>
> > it would make any soft fork impossible.
>
> This is probably tangential to the topic of the thread, but since you
> bring up the confiscatory potential of soft forks in general I will go
> ahead and plant my flag here by saying that if given the choice between
> doing a soft fork but with a high likelihood of freezing coins, or doing a
> hard fork to avoid freezing coins, I would pick the hard fork every time.
>
> > As long as soft forks are tolerated, a degree of nuance needs to be
> > introduced to take into account reasonable expectations from users
>
> I believe what I wrote accounts for this nuance. As far as I'm aware, no
> soft fork ever intentionally froze coins; on the contrary, my observation
> has been that protocol developers are exceedingly cautious to avoid this
> side effect.[1] It appears their efforts have not been in vain, since broad
> confidence in the security of bitcoin property rights remains intact, as
> evidenced by the millions of people who continue to use bitcoin to store
> value.
>
> > and incompatible with many soft fork proposal, including your own.
>
> I'm not sure what you're referencing here; I am not an author of any soft
> fork proposals.
>
> [1] Apparently the P2SH soft fork did freeze a total of 0.044 BTC:
> https://bitcoin.stackexchange.com/a/115804
> This seems unintentional since the coins were created after the activation
> client was published and shortly before the fork activated, and I could not
> find any record of alarms being raised at the time about the prospect of
> freezing these coins.
>
> On Fri, Feb 13, 2026, at 5:52 PM, Antoine Poinsot wrote:
> > Hi John,
> >
> > Without commenting on the (un)desirability of freezing vulnerable coins
> > (i largely share your
> > concerns, but haven't yet formed an opinion of my own), i would like to
> > surface one issue in part of
> > your reasoning.
> >
> > You state:
> >> 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.
> >
> > That's quite the sweeping claim, but it's trivially incorrect, or it
> > would make any soft fork
> > impossible. This is both disproven historically, since Bitcoin made
> > previously-valid redeem scripts
> > invalid on at least 5 occasions (post Satoshi), and incompatible with
> > many soft fork proposal,
> > including your own.
> >
> > As long as soft forks are tolerated, a degree of nuance needs to be
> > introduced to take into account
> > reasonable expectations from users, and not disabling
> > potentially-vulnerable EC opcodes as opposed
> > to upgrade hooks needs to be defended on its own merit rather than
> > appealing to the destruction of
> > Bitcoin. (And to be clear i think a strong case can be made in this
> > regard, this is not to be
> > interpreted as an argument in favour of The Big Freeze.)
> >
> > Best,
> > Antoine
> >
> >
> > On Friday, February 13th, 2026 at 5: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/8692bba5-47d0-49f4-9b7f-ccb564cc3630%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/CAN7kyNi155H25NqGRg9NS_Yt6J5j9i3sRLBSULzkzJozYNz%3DEg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 23591 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin
2026-02-13 21:50 ` Light
2026-02-13 22:52 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
@ 2026-02-16 9:59 ` sadiq Ismail
1 sibling, 0 replies; 16+ messages in thread
From: sadiq Ismail @ 2026-02-16 9:59 UTC (permalink / raw)
To: Light; +Cc: bitcoindev
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin
2026-02-13 16:20 [bitcoindev] The limitations of cryptographic agility in Bitcoin Pieter Wuille
2026-02-13 19:39 ` Erik Aronesty
2026-02-13 21:50 ` Light
@ 2026-02-13 21:54 ` Ethan Heilman
2026-02-14 12:02 ` [bitcoindev] " waxwing/ AdamISZ
` (2 subsequent siblings)
5 siblings, 0 replies; 16+ messages in thread
From: Ethan Heilman @ 2026-02-13 21:54 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 10317 bytes --]
I agree with your overall claim that we should be cautious about which
digital signature algorithms are added as op codes. The danger of a break
in ECC is real, but so is the danger of adopting a newer signature
algorithm with less vetting. These risks must both be taken seriously.
> 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.
Agreed that allowing users to choose their cryptographic primitives from a
menu of many options would be problematic:
- Skub and fragmentation over which algorithm is best (Camp A vs Camp B)
- Greater resource costs on wallets if they have to support many algorithms,
- Security analysis is spread over many different schemes,
- More algorithms increase chance any one of the algorithms is broken,
Ideally Bitcoin would only have one signature algorithm at a time.
Algorithm agility aims to provide a standardized upgrade path from a
weakened algorithm to a new algorithm that the community overwhelmingly
wishes to use. It should not require a menu of different signature opcodes.
Yes, the backup signature algorithm exists, but it exists only to enable
this secure upgrade path. In this light the high transaction fees of
SLH_DSA can be seen as a benefit since they incentivize using SLH_DSA
signatures only when absolutely necessary.
> 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.
As Bitcoin moves to PQ is I want to ensure the solution is standardized and
that wallets use the standard approaches. I worry that some wallets might
roll their own adhoc protections if we don't have a clear and well
supported standard way to support PQ signatures.
> 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.
I agree that the incentives make that an extremely likely confiscatory
soft-fork. While it seems like the most likely outcome, I don't feel
comfortable making PQ plans that depend on this happening. I also don't
feel comfortable advocating for a confiscatory soft-fork. For these
reasons, I have not baked the assumption that a confiscatory soft-fork
happens in my algorithm agility proposal.
No one can say for certain, but it seems reasonable to assume long exposure
attacks will be practical years before short exposure attacks. If true,
then a soft-fork to freeze P2PK/P2TR will happen before EC opcodes are
frozen as P2SH will still be safe to use (as long as the public key has not
been exposed). By the time short exposure attacks are practical, will
enough P2SH,P2WSH vulnerable coins remain to justify freezing EC opcodes?
What's the breakdown on the number of coins in P2SH and P2WSH outputs that
haven't moved in 5 years? As you ask, how much is enough?
This question of what to do with EC opcodes is worth more discussion. My
hope is that once everyone agrees that they are insecure, no one uses them,
like no one using OP_TRUE scripts or OP_SHA1, but that hope is not
justified, what should we do? opcode anti-discount? Disabling them like you
propose?
On Fri, Feb 13, 2026 at 11:23 AM Pieter Wuille <bitcoin-dev@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/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/CAEM%3Dy%2BWbqY4FE9XH50K2B8DjE5zx_D1zZ-sZmfdmg0vvUiyLTQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 11567 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread* [bitcoindev] Re: The limitations of cryptographic agility in Bitcoin
2026-02-13 16:20 [bitcoindev] The limitations of cryptographic agility in Bitcoin Pieter Wuille
` (2 preceding siblings ...)
2026-02-13 21:54 ` Ethan Heilman
@ 2026-02-14 12:02 ` waxwing/ AdamISZ
2026-02-17 3:49 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
2026-02-17 20:04 ` [bitcoindev] " Pieter Wuille
5 siblings, 0 replies; 16+ messages in thread
From: waxwing/ AdamISZ @ 2026-02-14 12:02 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 9474 bytes --]
Hi Pieter, list,
> 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.
> 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.
> 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*.
> 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"
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]
The fact that other coins are held in an insecure way is in no way a threat
to my security. As you point out with e.g. OP_TRUE there is zero ability to
prevent people doing this.
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.
The only thing that the system as a whole *has* to promise is that there
exists a safe, practical way to keep possession (and also users should not
have to just "guess" which methods are secure!). The system is not
required, nor can it, to prevent people choosing insecure storage methods,
against the technical advice.
If value is held in large quantities in outputs which phase from secure to
insecure then for sure there are cases (even when said technical advice is
amply provided!) where this leads to turbulence in value (mostly due to
death or key loss), but value cannot be controlled or predicted anyway. As
per my message here: [1] there are private property rights principles which
cannot be violated, else the entire purpose of the project is lost. Good
safety-engineering reasoning is unfortunately not enough to trump such
principles.
(I think the title of your thread is interesting though: is *agility*
desirable? We're borrowing the term from other areas of the IT industry
where it makes more sense perhaps; perhaps here "flexibility" is the more
desirable part, at least if you take *my* side of this specific argument,
which is that no, others' security failings do not change the promise made
to users to protect their property. Flexibility helps exactly where there's
a lot of uncertainty about the security of different schemes. If it costs
$100 to move in quantum-secure way and $1 to move in a non-*, then it is
much better that flexibility exists.)
[1] https://groups.google.com/g/bitcoindev/c/7jkVS1K9WLo/m/btgqa9t7AwAJ
Cheers,
AdamISZ/waxwing
On Friday, February 13, 2026 at 1:23:16 PM UTC-3 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.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8fa10605-8b55-4777-9fb9-82b9c0fd1dbfn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 11154 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [bitcoindev] The limitations of cryptographic agility in Bitcoin
2026-02-13 16:20 [bitcoindev] The limitations of cryptographic agility in Bitcoin Pieter Wuille
` (3 preceding siblings ...)
2026-02-14 12:02 ` [bitcoindev] " waxwing/ AdamISZ
@ 2026-02-17 3:49 ` 'conduition' via Bitcoin Development Mailing List
2026-02-17 20:04 ` [bitcoindev] " Pieter Wuille
5 siblings, 0 replies; 16+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-02-17 3:49 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Development Mailing List
[-- Attachment #1.1.1: Type: text/plain, Size: 7526 bytes --]
Hi Pieter, and thanks for bringing this up.
I think your concern is valid. I'd agree with your thought experiment in the sense that there would definitely be competing movements for and against two such well-matched algorithms. However i don't see this debate affecting much in the real world, outside of twitter meme showdowns and reddit debates.
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. Or more efficiently they could commit their BIP340/FancySig pubkeys in separate tapscript leaves and use only BIP340 until quantum security is needed. This is even more secure than a hybrid locking script if we assume no address reuse. Users don't have to pick between algorithms until spending time, and even then they could reveal only a hybrid leaf for extra safety if they are unsure.
So no, i don't think we need to change our assumptions, even if an ideal PQ signature candidate appears tomorrow. We just need to design smart and secure standards for wallets to implement so that users get a (speculatively) quantum secure fallback without exposing themselves to risk of novel attacks on young cryptosystems.
regards,
conduition
On Friday, February 13th, 2026 at 4:23 PM, Pieter Wuille <bitcoin-dev@wuille.net> wrote:
> Hi all,
>
> A thread 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, 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/THqOJuI_s5C8B9jkklN73BB_Hzb9SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh8NxxYbXwv4v6ikpStguW-QEvef4WgBZ7AQDz00P0st91FMA%3D%40wuille.net.
--
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/ZA5N5pZmrZFiYFDqhSYz9gR6q2tqf68MHxGuEUI0iyQAu3GKDcNpw9XTamXahrpUFK4zwT6BV3s3SmoKCMdNBL_KqyozByLlX6SwwAKYuLE%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 9242 bytes --]
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread* [bitcoindev] Re: The limitations of cryptographic agility in Bitcoin
2026-02-13 16:20 [bitcoindev] The limitations of cryptographic agility in Bitcoin Pieter Wuille
` (4 preceding siblings ...)
2026-02-17 3:49 ` [bitcoindev] " 'conduition' via Bitcoin Development Mailing List
@ 2026-02-17 20:04 ` Pieter Wuille
2026-02-19 7:22 ` 'conduition' via Bitcoin Development Mailing List
2026-02-25 12:00 ` waxwing/ AdamISZ
5 siblings, 2 replies; 16+ messages in thread
From: Pieter Wuille @ 2026-02-17 20:04 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 11784 bytes --]
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 <bitcoin-dev@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/fpr54OwSyhxOLkSM0ThB2HQN97XFCTL0c3oHbb9A-jmN0TiO6m38a-MqHYpHK9g4tokROwjJGFfFLjYtGluNRBg70PA4YThX9cMAiyw1B1k%3D%40wuille.net.
[-- Attachment #2: Type: text/html, Size: 15292 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [bitcoindev] Re: The limitations of cryptographic agility in Bitcoin
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
1 sibling, 0 replies; 16+ messages in thread
From: 'conduition' via Bitcoin Development Mailing List @ 2026-02-19 7:22 UTC (permalink / raw)
To: Pieter Wuille; +Cc: Bitcoin Development Mailing List
[-- Attachment #1.1.1: Type: text/plain, Size: 15411 bytes --]
Thanks for elaborating, Pieter. I think i understand the point you're getting at a bit better now. You are saying that I as a self-interested Bitcoin user care about the cryptographic assumptions made by other Bitcoin users, insofar as other users' choices affect the market value of my own coins.
You're very right that this concern is highly relevant for holders worried about quantum procrastinators, who by failing to make a choice at all will be making a de-facto choice to protect their coins with a cryptosystem that may soon be broken. However, i disagree on your point here:
> Users adopting schemes with a different security assumption at scale(*) is opting all users including those who do not migrate, into that security assumption.
I disagree for the same reasons I outlined earlier: we have many options to design wallet standards which minimize users' exposure to novel attacks on young cryptosystems. Provided most wallets do not intentionally stray from best-practices in PQ wallet security, this risk - and any FUD borne from it - should be entirely manageable, especially considering the number one candidate everyone seems to agree on is hash-based signatures, which are even more conservative than BIP340.
But as you say, these fears are far less relevant than fears from the other camp (FUD around legacy coins protected only by ECDLP). So let's focus on that problem.
> This is not a statement about what should or shouldn't be done about perceived-vulnerable coins.
>
> 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'm a bit confused by this statement. You're saying we shouldn't worry about PQ-vulnerable coins because any chain in which they are exploitable would be worthless anyway? But you're NOT advocating for a freeze which would prevent coins from being stolen.
I think these aren't compatible views. If we do not freeze EC spending and replace it with PQ-safe rescue protocols, then those coins will be vulnerable, and as per your comment, the chain will become worthless. Thus, the only "interesting" chains are the ones which implement a freeze of some kind - at least under your assumptions.
Personally I am not entirely convinced of this claim that "future chains in which [PQ-Vulnerable] coins remain will lose value" and will therefore be "uninteresting" to work on. But I'll leave that discussion for another day.
FWIW i think a freeze (with rescue protocols) is indeed a good idea and we should work on it, maybe not today but eventually.
regards,
conduitionOn Tuesday, February 17th, 2026 at 8:10 PM, Pieter Wuille <bitcoin-dev@wuille.net> 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 <bitcoin-dev@wuille.net> wrote:
>
> > Hi all,
> >
> > A thread 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, 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/fpr54OwSyhxOLkSM0ThB2HQN97XFCTL0c3oHbb9A-jmN0TiO6m38a-MqHYpHK9g4tokROwjJGFfFLjYtGluNRBg70PA4YThX9cMAiyw1B1k%3D%40wuille.net.
--
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/gaAWxrXhxaj_y-siuqGvE2G-CKPtE9GgNKtYbw54H1HSLfpecRCpbrqrYDeF2lgE0C3S1qWLSCSntBQxizGLp0fdZq99ChKJZy2r6G_OXyg%3D%40proton.me.
[-- Attachment #1.1.2.1: Type: text/html, Size: 19739 bytes --]
[-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --]
[-- Type: application/pgp-keys, Size: 649 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* [bitcoindev] Re: The limitations of cryptographic agility in Bitcoin
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
1 sibling, 1 reply; 16+ messages in thread
From: waxwing/ AdamISZ @ 2026-02-25 12:00 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoindev] Re: The limitations of cryptographic agility in Bitcoin
2026-02-25 12:00 ` waxwing/ AdamISZ
@ 2026-02-25 14:39 ` Erik Aronesty
2026-02-25 22:43 ` Ethan Heilman
0 siblings, 1 reply; 16+ messages in thread
From: Erik Aronesty @ 2026-02-25 14:39 UTC (permalink / raw)
To: waxwing/ AdamISZ; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2054 bytes --]
> 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+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAJowKgJwq88yfJEQzZ%2Bv-33EtEuYif1y6qsXtyoRyk2V%2B44cww%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 2708 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoindev] Re: The limitations of cryptographic agility in Bitcoin
2026-02-25 14:39 ` Erik Aronesty
@ 2026-02-25 22:43 ` Ethan Heilman
2026-02-26 2:07 ` Alex
0 siblings, 1 reply; 16+ messages in thread
From: Ethan Heilman @ 2026-02-25 22:43 UTC (permalink / raw)
To: Erik Aronesty; +Cc: waxwing/ AdamISZ, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 4348 bytes --]
> 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 <erik@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+unsubscribe@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/CAEM%3Dy%2BW_KDes6WMWc-MtTptKHeEqrstnyi4fdxeEs1SstXQSKg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5366 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoindev] Re: The limitations of cryptographic agility in Bitcoin
2026-02-25 22:43 ` Ethan Heilman
@ 2026-02-26 2:07 ` Alex
0 siblings, 0 replies; 16+ messages in thread
From: Alex @ 2026-02-26 2:07 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread