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.

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