A "Quantum-Agile" Bitcoin address proposal

[Jason Resch]

Dear Bitcoin Developers,

I've been thinking about the threat of quantum computers to ECDSA, and I had an idea that I consider to be valuable and worth sharing with the broader community.

The essential idea is that rather than attempt to choose any one post-quantum-secure algorithm as a replacement, instead, bitcoin ought to support a set of various algorithms, 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. 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.
• 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.

This agile approach, inspired by TLS, SSH, and IPSec (all of which support multiple suites of different algorithms) has many advantages:

1. It defers the decision of which algorithm to use and trust to the future, when there will be more information available. Bitcoin developers can't predict what future algorithm breaks might happen, and enabling users to decide absolves Bitcoin developers of having to try to predict the future.
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.
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.

I have put together a white paper that offers some further detail on how this could work: https://zenodo.org/records/20292912 and welcome any comments/feedback.

Jason

[Pieter Wuille]

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.

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.

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.

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.

More detailed comments inline below.

On Tuesday, May 19th, 2026 at 2:43 PM, Jason Resch <jason...@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. 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.

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.

• 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.

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.

-- 
Pieter

[Jason Resch]

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 <bitco...@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, SIKE, 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 <jason...@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? 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