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

[Pieter Wuille]

Hi Jason,

See my comments below.

On Tuesday, May 19th, 2026 at 11:27 PM, Jason Resch <jason...@gmail.com> wrote:

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.

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? 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

[Jason Resch]

On Wed, May 20, 2026, 9:02 AM Pieter Wuille <bitco...@wuille.net> wrote:

Hi Jason,

See my comments below.

On Tuesday, May 19th, 2026 at 11:27 PM, Jason Resch <jason...@gmail.com> wrote:

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.

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? 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