From: Jason Resch <jasonresch@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A "Quantum-Agile" Bitcoin address proposal
Date: Tue, 19 May 2026 23:10:20 -0400 [thread overview]
Message-ID: <CA+BCJUgfB1iYcxivr0=aWORUHVpQ-fTLs47yYDb5aXaTEbBrkw@mail.gmail.com> (raw)
In-Reply-To: <pG8q9uABWbOoiN1qZI3TWf-oloP08k3UOpy0cjHZGoFq0P_xVufCwvtKtdFNL3SkC8P4gAfLtLM4v_89TfbUEVXlU9a6OYo9f02jKRetxRs=@wuille.net>
[-- Attachment #1: Type: text/plain, Size: 11897 bytes --]
Dear Pieter,
Thank you for your illuminating feedback, I very much appreciate it. My
replies are in-line below:
On Tue, May 19, 2026 at 3:31 PM Pieter Wuille <bitcoin-dev@wuille.net>
wrote:
> Hi Jason,
>
> I think that in technical terms, this is how many people already think
> about PQC adoption. Most proposals (including P2MR and P2TRv2) are built on
> the script merkle tree construction introduced in Taproot. By having
> multiple leaves in the tree, with distinct PQC (or EC) keys/opcodes in
> each, it is possible to have multiple schemes in parallel.
>
Thank you for pointing out these alternatives to me. Is it correct that the
script Merkle tree would have the additional overhead of: script opcodes,
the script itself, the control block, and 32 bytes for each step in the
Merkle path?
In the proposal I shared, the only overhead (beyond the public key(s) +
signature(s) inherent to both) would be only a few bytes of metadata for
algorithm specification (which seems necessary in any multi-algorithm
implementation). So while the script tree offers more general flexibility,
it may be overkill compared to a more basic built-in support for
multi-algorithm signatures.
>
> However, I would not consider this "agility", but rather a necessary evil
> as the significant trade-offs in PQC schemes today (large signatures, high
> validation costs, lack of features like homomorphic derivation, low
> confidence, or combinations thereof) make it so that there is unlikely to
> be a single scheme that covers all needs.
>
I agree about PQC being a necessary evil. In an ideal world ECDSA would be
secure against quantum computers, or failing that, there should be a PQC
algorithm just as short, efficient, flexible, and vetted as ECDSA is. But
unfortunately no current PQC candidate is as good as ECDSA in all those
respects. Faced with that limitation, we must bite the bullet and plan for
a CRQC world. How would Satoshi have designed bitcoin if CRQCs already
existed, and no PQC was fully trusted to go 20-50 years without failing to
cryptanalysis?
I think having support one or two alternative fallback algorithms is good
insurance in case a common or popular algorithm fails. It is a small cost
to pay and would help many Bitcoiners to sleep better at night. Asymmetric
ciphers have a poor track record of appearing secure at first, before
catastrophically failing (Knapsack
<https://en.wikipedia.org/wiki/Merkle%E2%80%93Hellman_knapsack_cryptosystem>,
SIKE <https://en.wikipedia.org/wiki/Supersingular_isogeny_key_exchange>,
NTRUSign <https://en.wikipedia.org/wiki/NTRUSign>). Given the comparatively
short history of PQC algorithms, I think safeguards are another necessary
evil in case such a break impacts Bitcoin.
>
> In fact, I would go as far as claiming that to some extent, the more
> schemes are available, the less cryptographically agile Bitcoin becomes,
> assuming those schemes are actually adopted. This is because unlike in
> TLS/SSH/IPSec, one does not solely care about protecting their own
> connections/coins, but also other users' coins: if you believe many coins
> are held in insecure output types, you're likely worried about the effect
> on the currency's value in case a large-scale theft happens, even if your
> own coins are secure. Of course nobody can promise anything about Bitcoin's
> exchange value, ever, but it is shortsighted to ignore this aspect, and
> makes it effectively a tragedy of a commons: everyone has an incentive to
> make everyone's coins secure.
>
That leaves two options, as I see it:
A) Support a single PQC algorithm. (And hope no weakness is ever discovered
in it as then everyone would be screwed as there would be no quick
mitigation.)
B) Support multiple PQC algorithms. (And users who are extra security
conscious can use at least 2, to protect themselves from catastrophic
breaks, while users who use only one will at least have an immediate
mitigation path available: they just need to send their vulnerable coins to
a new address secured by a remaining unbroken algorithm).
I wholeheartedly agree with your sentiment that it is an ugly solution to
not have a single well-vetted PQC algorithm to recommend everyone use. But
given that we at present do not have one for the CRQC era, I would feel
much better as an end user to know there is an available mitigation plan in
the case an algorithm is broken.
>
> Bitcoin is, in my view, a consensus of rules, but also a consensus on what
> cryptography is considered secure. Giving users the option of more schemes
> means extending that consensus to needing *all* of them to be secure.
> That does not mean we cannot add schemes of course; obviously any actual
> PQC migration will boil down to adding new output types and having users
> migrate to them. But I think it is misleading to consider such flexibility
> a positive property.
>
Like Churchill said of Democracy, it is the worst option, aside from all
the others. Today, Bitcoin gives end-users ultimate decentralized control
over how they secure their wallets. Some take it to extremes and use
multi-sig, and custodians, or secret sharing across hard wallets, while
others might keep their keys in plain text on their internet-connected
computers or re-use addresses and expose their public keys to the world.
But today, end-users have no control over what algorithms to rely on. So
long as all provided options are considered secure enough to pass NIST
certification, why not allow some users to choose to use longer keys, or
multiple algorithms in combination, should they want to take that extra
step for themselves? If the reasoning is: "one of those algorithms might
break", that very same reason (in my mind) justifies not having Bitcoin
depend on any single algorithm (or algorithm family).
> More detailed comments inline below.
>
> On Tuesday, May 19th, 2026 at 2:43 PM, Jason Resch <jasonresch@gmail.com>
> wrote:
>
> and let end-users decide which one algorithm or combination of algorithms,
> best fits with their use-case, security requirements, and trust for
> different algorithms.
>
>
> I agree that's what may well happen, but for different reasons. If there
> somehow was one PQC scheme that everyone considered secure and supported
> all the features we needed, I am staunchly of the opinion we should be
> adding that and nothing else.
>
What are the thoughts here on SQIsign 2.0
<https://sqisign.org/spec/sqisign-20250205.pdf>? My understanding is that
it is 30X faster than the original SQISign, and this version is now being
evaluated by NIST. Its public key is only 2X ECDSA, and its signature is
only 2.3X, while its verification time is 5.1 million ops (approximately
1.5 ms on a 3.4 GHz CPU). If there were only one PQC signature algorithm to
choose, this one seems to have good trade offs (but it is still so new that
I wouldn't feel comfortable trusting it alone and there not being any
alternative to switch to).
> Such a scheme is unlikely to exist, so we may be forced - possibly over
> time - to adopt multiple schemes for different use cases. Still, the choice
> between them will follow guidelines, or practically speaking,
> wallet/provider implementation, not end user choice.
>
I agree, and say something similar in section 6 of my proposal:
"A quantum-agile Bitcoin wallet would not ask every user to understand
every cryptographic family. It would expose a small number of
understandable profiles while still allowing expert and institutional users
to choose custom all-of-N key bundle."
I then provide several example user profiles that wallet provides could
suggest to end-users to choose from.
>
>
> In short:
>
> - A wallet chooses one or more public keys from one or more approved
> signature algorithms.
> - This ordered public-key bundle is serialized canonically and hashed
> to form the address.
> - Senders do not need to know which algorithm or algorithms are behind
> the address.
> - At spend time, the spender reveals the public-key bundle and
> provides one valid signature for each key in the bundle.
>
>
> This is effectively what the BIP341 script tree already gives you, if
> multiple PQC opcodes were added.
>
I am very relieved and happy to hear that such proposals are already under
consideration!
>
>
> - Users who want higher assurance can use heterogeneous algorithm
> families, while users with lower-value or high-frequency wallets can choose
> cheaper single-algorithm profiles.
>
>
> While that is what may practically happen, I don't consider this a good
> thing, because of the tragedy of the commons here. Users who own small
> amounts that move frequently would likely rather see others adopt PQC
> rather than themselves.
>
>
> 2. It enables rapid migration to other algorithms, should any future
> cryptographic break or even suspicious of possible future breaks, occur in
> the future, without having to wait for a new consensus for a change to the
> Bitcoin software and protocol.
>
>
> I do not consider the ability for individual users to move their coins
> over to something else "migration", unless there is a reasonable
> expectation that ~everyone moves away. Due to the need for consensus on
> which schemes are secure, I'd call Bitcoin pretty much the least
> cryptographically agile system imaginable.
>
I don't think much thought has ever been given to the problem before. ECDSA
was the obvious choice in 2008. But newer, more efficient, and more secure
algorithms have since become available (e.g. Ed25519). I attribute the lack
of change more to inertia than to a lack of consensus on Ed25519's
security. Now that CRQCs loom, we have a general consensus that ECDSA will
soon no longer be secure, yet there is a general lack of consensus
regarding which PQC algorithms will survive cryptanalysis over the long
term. This lack of consensus here is not limited to Bitcoin or its users,
nor is it anything we can hope to solve from our present vantage point.
Only time will tell.
>
>
> 3. End users can choose security levels that correspond to their
> security needs and spending habits. Have a cold-wallet securing millions of
> bitcoin which you spend from once per decade? Use several PSQ algorithm
> families with large key sizes, and pay higher transaction fees for those
> rare occasions you move funds. Have a small spending wallet you use to make
> online purchases? Use the smallest key size possible to save on transaction
> fees.
>
>
> Sure, and this is especially relevant with the recent work on stateful and
> stateless hash-based signature schemes, which have significant trade-offs
> for cost and security that depend on the use case. Still, like above, I
> don't consider that an inherently positive property, but an unfortunate
> necessity.
>
I agree. If we do nothing and continue using ECDA, then CRQCs will destroy
trust in Bitcoin, so we must add support for PQC. Given that, we can bet
the farm on a single PQC algorithm, or we can hedge by supporting multiple
PQC algorithms. I don't envy the decision you and the other Bitcoin
developers must make, I only hope that I can help make your decision easier
by sharing my perspective.
Best wishes,
Jason
--
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/CA%2BBCJUgfB1iYcxivr0%3DaWORUHVpQ-fTLs47yYDb5aXaTEbBrkw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 15587 bytes --]
next prev parent reply other threads:[~2026-05-20 3:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 18:11 [bitcoindev] A "Quantum-Agile" Bitcoin address proposal Jason Resch
2026-05-19 19:31 ` Pieter Wuille
2026-05-20 3:10 ` Jason Resch [this message]
2026-05-20 13:02 ` Pieter Wuille
2026-05-20 14:20 ` Jason Resch
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='CA+BCJUgfB1iYcxivr0=aWORUHVpQ-fTLs47yYDb5aXaTEbBrkw@mail.gmail.com' \
--to=jasonresch@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