Hi Jason, See my comments below.
On Tuesday, May 19th, 2026 at 11:27 PM, Jason Resch <[email protected]> wrote: > On Tue, May 19, 2026 at 3:31 PM Pieter Wuille <[email protected]> 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/VYtAQB0c0TAb_GQlnazB1OE9rtZDe8FsrAOg5YU7R6rZ8Etho2eg5gVJ0kxnwt9Qpln0FxTU3BJsuwKFqjZOEz15HrF5UwoAxY-G8iIyXxU%3D%40wuille.net.
