* [bitcoindev] A "Quantum-Agile" Bitcoin address proposal
@ 2026-05-19 18:11 Jason Resch
2026-05-19 19:31 ` Pieter Wuille
0 siblings, 1 reply; 5+ messages in thread
From: Jason Resch @ 2026-05-19 18:11 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 2891 bytes --]
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
--
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/8d22c782-6da1-46f3-aa12-f686d5e1746dn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3241 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] A "Quantum-Agile" Bitcoin address proposal
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
0 siblings, 1 reply; 5+ messages in thread
From: Pieter Wuille @ 2026-05-19 19:31 UTC (permalink / raw)
To: Jason Resch; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 5462 bytes --]
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 <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. 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.
> - 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.
> - 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
--
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/pG8q9uABWbOoiN1qZI3TWf-oloP08k3UOpy0cjHZGoFq0P_xVufCwvtKtdFNL3SkC8P4gAfLtLM4v_89TfbUEVXlU9a6OYo9f02jKRetxRs%3D%40wuille.net.
[-- Attachment #2: Type: text/html, Size: 7435 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] A "Quantum-Agile" Bitcoin address proposal
2026-05-19 19:31 ` Pieter Wuille
@ 2026-05-20 3:10 ` Jason Resch
2026-05-20 13:02 ` Pieter Wuille
0 siblings, 1 reply; 5+ messages in thread
From: Jason Resch @ 2026-05-20 3:10 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] A "Quantum-Agile" Bitcoin address proposal
2026-05-20 3:10 ` Jason Resch
@ 2026-05-20 13:02 ` Pieter Wuille
2026-05-20 14:20 ` Jason Resch
0 siblings, 1 reply; 5+ messages in thread
From: Pieter Wuille @ 2026-05-20 13:02 UTC (permalink / raw)
To: Jason Resch; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 7705 bytes --]
Hi Jason,
See my comments below.
On Tuesday, May 19th, 2026 at 11:27 PM, Jason Resch <jasonresch@gmail.com> wrote:
> 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.
I do not believe that is correct. As I understand it, your proposal requires revealing all public keys (across all schemes) at spend time, because the hash in the address commits to their concatenation. Merkle script tree based solutions only require revealing the actually signed-with public key type, plus a logarithmic number of 32-byte Merkle steps for the other public key types. The other costs are either marginal or common between approaches. In Merkle script trees approaches, only one script is revealed, and (in the single-user setting which you seem to be talked about) consists of just a public key + an opcode. The 64-byte control block is unique to Taproot, but orthogonal; P2MR does not have it for example. It allows for one specific public key to be spent with extremely cheaply, at the cost of making everything else more expensive.
I believe that If there is at least one alternative key type in the construction that's larger than 32 bytes, or at least 2 alternative keys, Merkle tree based approaches will have a strictly lower on-chain footprint at spend time.
> 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?
There is no problem supporting multiple algorithms as long as everyone trusts all of them - and that is what will likely need to happen in practice. But coming to agreement on what that is, is part of the problem, and not all users might be willing to just trust NIST here to make that decision for everyone. Allowing users to choose individually between different "trusted" algorithms has only a marginal benefit: everyone already relies on none of these algorithms being broken for the currency to retain value. Picking a "stronger" algorithm for your own coins means you're optimizing for a scenario where other algorithms are broken, there is mass chaos due to theft and likely forks, but somehow your own coins make it through to the other side in a wasteland. It's certainly reasonable to expect that some individual users would make this choice if available, but systemically, as protocol designers, it does not seem like an interesting thing to focus on.
Again, I'm not arguing against the practical reality of Bitcoin likely needing to adopt multiple algorithms if migration to a PQC world is needed. I am arguing against user flexibility itself being something to optimize for.
> 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).
The enormous difference is that Bitcoin users already opted into trusting that algorithm by using Bitcoin in the first place. Adding more algorithms means expanding the set of trusted algorithms, possibly against those users' wishes. The threat of CRQCs may make us all reevaluate our trust in secp256k1's security, which is why we're having this discussion.
> 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).
I'm really not qualified to comment on this.
> 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.
I strongly disagree with this. The security difference between ed25519 and secp256k1 ECDSA is marginal. They are both based on hardness of the ECDLP problem. The secp256k1 curve has some unusual structure that may make it weaker than generic curves, though this is a theoretical concern right now. On the other hand, the ed25519 curve is slightly smaller, which should net it around 1.2 bits less security (also marginal). In theory, ECDSA may have weaknesses over Schnorr (which ed25519 and bip340 are instances of) in addition to their respective ECDLP hardness, but this is very theoretical.
But even ignoring the security distinction between the two, needing to trust both is worse than just trusting one, which IMO means there was never a justification for adding ed25519. And migrating fully to ed25519 (removing secp256k1 from the trust equation) would have come at a cost that isn't justified by the distinction between them. It is only due to the CRQC threat that we are now in a position that forces bearing that cost.
> 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.
This is not a decision that is up to developers, but up to the entire ecosystem. Certainly some people's opinion carry more weight than others, but software developers can only release software, not force people to use it. By participating in this discussion, you too are part of the reasoning that will ultimately guide the ecosystem towards the choice it makes. Please don't say it's up to some specific group of people to decide. If that were the case, Bitcoin has long failed already.
Cheers,
--
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/VYtAQB0c0TAb_GQlnazB1OE9rtZDe8FsrAOg5YU7R6rZ8Etho2eg5gVJ0kxnwt9Qpln0FxTU3BJsuwKFqjZOEz15HrF5UwoAxY-G8iIyXxU%3D%40wuille.net.
[-- Attachment #2: Type: text/html, Size: 10020 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] A "Quantum-Agile" Bitcoin address proposal
2026-05-20 13:02 ` Pieter Wuille
@ 2026-05-20 14:20 ` Jason Resch
0 siblings, 0 replies; 5+ messages in thread
From: Jason Resch @ 2026-05-20 14:20 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 9298 bytes --]
On Wed, May 20, 2026, 9:02 AM Pieter Wuille <bitcoin-dev@wuille.net> wrote:
> Hi Jason,
>
> See my comments below.
>
> On Tuesday, May 19th, 2026 at 11:27 PM, Jason Resch <jasonresch@gmail.com>
> wrote:
>
>
> 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.
>
>
> I do not believe that is correct. As I understand it, your proposal
> requires revealing *all* public keys (across all schemes) at spend time,
> because the hash in the address commits to their concatenation. Merkle
> script tree based solutions only require revealing the actually signed-with
> public key type, plus a logarithmic number of 32-byte Merkle steps for the
> other public key types. The other costs are either marginal or common
> between approaches. In Merkle script trees approaches, only one script is
> revealed, and (in the single-user setting which you seem to be talked
> about) consists of just a public key + an opcode. The 64-byte control block
> is unique to Taproot, but orthogonal; P2MR does not have it for example. It
> allows for one specific public key to be spent with extremely cheaply, at
> the cost of making everything else more expensive.
>
> I believe that If there is at least one alternative key type in the
> construction that's larger than 32 bytes, or at least 2 alternative keys,
> Merkle tree based approaches will have a strictly lower on-chain footprint
> at spend time.
>
Ahh, I think I understand now. If one used multiple algorithms in their
original commitment, then at spend time they can choose to reveal only one
public key and signature for an algorithm known to be secure at that point
in time. That is very elegant.
> 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?
>
>
> There is no problem supporting multiple algorithms as long as everyone
> trusts all of them - and that is what will likely need to happen in
> practice. But coming to agreement on what that is, is part of the problem,
> and not all users might be willing to just trust NIST here to make that
> decision for everyone. Allowing users to choose individually between
> different "trusted" algorithms has only a marginal benefit: everyone
> already relies on none of these algorithms being broken for the currency to
> retain value. Picking a "stronger" algorithm for your own coins means
> you're optimizing for a scenario where other algorithms are broken, there
> is mass chaos due to theft and likely forks, but somehow your own coins
> make it through to the other side in a wasteland. It's certainly reasonable
> to expect that some individual users would make this choice if available,
> but systemically, as protocol designers, it does not seem like an
> interesting thing to focus on.
>
> Again, I'm not arguing against the practical reality of Bitcoin likely
> needing to adopt multiple algorithms if migration to a PQC world is needed.
> I am arguing against user flexibility itself being something to optimize
> for.
>
I am beginning to come around on this, because I had not considered how
much more trust already exists for hash-based signatures. If hashes break,
then the whole concept of block chains breaks. So hash-based signatures
seem to add the least additional security assumptions. All the other
signature schemes require additional assumptions about the hardnesses of
certain mathematical problems.
> 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).
>
>
> The enormous difference is that Bitcoin users *already* opted into
> trusting that algorithm by using Bitcoin in the first place. Adding more
> algorithms means expanding the set of trusted algorithms, possibly against
> those users' wishes. The threat of CRQCs may make us all reevaluate our
> trust in secp256k1's security, which is why we're having this discussion.
>
That's true and I now understand your point. More algorithms means less
total trust in them all working out. Whereas moving to just one signature
scheme that had even more trust than ECDSA could make Bitcoin even more
trusted.
>
> 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).
>
>
> I'm really not qualified to comment on this.
>
> 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.
>
>
> I strongly disagree with this. The security difference between ed25519 and
> secp256k1 ECDSA is marginal. They are both based on hardness of the ECDLP
> problem. The secp256k1 curve has some unusual structure that may make it
> weaker than generic curves, though this is a theoretical concern right now.
> On the other hand, the ed25519 curve is slightly smaller, which should net
> it around 1.2 bits less security (also marginal). In theory, ECDSA may have
> weaknesses over Schnorr (which ed25519 and bip340 are instances of) in
> addition to their respective ECDLP hardness, but this is very theoretical.
>
> But even ignoring the security distinction between the two, needing to
> trust both is worse than just trusting one, which IMO means there was never
> a justification for adding ed25519.
>
That's a good point. I can agree then there never was sufficient reason to
change the protocol to add support for it.
And migrating fully to ed25519 (removing secp256k1 from the trust equation)
> would have come at a cost that isn't justified by the distinction between
> them. It is only due to the CRQC threat that we are now in a position that
> forces bearing that cost.
>
> 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.
>
>
> This is not a decision that is up to developers, but up to the entire
> ecosystem. Certainly some people's opinion carry more weight than others,
> but software developers can only release software, not force people to use
> it. By participating in this discussion, you too are part of the reasoning
> that will ultimately guide the ecosystem towards the choice it makes.
> Please don't say it's up to some specific group of people to decide. If
> that were the case, Bitcoin has long failed already.
>
I appreciate that. Thank you for taking the time to educate me on this
topic. I feel Bitcoin's future remains bright given all the thought the
community is directing towards this problem.
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%2BBCJUjN9%3Dprte7_Gfj_j8%3D2zSPfUQVQDm04aatyT7UAZp5i3A%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 12667 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-05-20 14:23 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2026-05-20 13:02 ` Pieter Wuille
2026-05-20 14:20 ` Jason Resch
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox