From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: The limitations of cryptographic agility in Bitcoin
Date: Sat, 14 Feb 2026 04:02:02 -0800 (PST) [thread overview]
Message-ID: <8fa10605-8b55-4777-9fb9-82b9c0fd1dbfn@googlegroups.com> (raw)
In-Reply-To: <THqOJuI_s5C8B9jkklN73BB_Hzb9SsiLM6BFp4zFP3zWQoRevKoLVspdwjwh8NxxYbXwv4v6ikpStguW-QEvef4WgBZ7AQDz00P0st91FMA=@wuille.net>
[-- 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 --]
next prev parent reply other threads:[~2026-02-14 12:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-13 16:20 [bitcoindev] " Pieter Wuille
2026-02-13 19:39 ` Erik Aronesty
2026-02-13 21:50 ` Light
2026-02-13 22:52 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-02-14 3:43 ` Light
2026-02-17 14:11 ` Garlo Nicon
2026-02-16 9:59 ` sadiq Ismail
2026-02-13 21:54 ` Ethan Heilman
2026-02-14 12:02 ` waxwing/ AdamISZ [this message]
2026-02-17 3:49 ` 'conduition' via Bitcoin Development Mailing List
2026-02-17 20:04 ` [bitcoindev] " Pieter Wuille
2026-02-19 7:22 ` 'conduition' via Bitcoin Development Mailing List
2026-02-25 12:00 ` waxwing/ AdamISZ
2026-02-25 14:39 ` Erik Aronesty
2026-02-25 22:43 ` Ethan Heilman
2026-02-26 2:07 ` Alex
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8fa10605-8b55-4777-9fb9-82b9c0fd1dbfn@googlegroups.com \
--to=ekaggata@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox