Hey @Matt Corallo, I can't reply on google groups but you should check out my article on hash-based signatures and my DASK proposal, it's very similar to your idea, in the way clients can opt into future quantum resistance without any consensus changes. I chose a different mechanism for my approach. Instead of an opcode in a tapscript leaf, DASK uses a PQ signature scheme pubkey as an secp256k1 secret key, and assumes future PQ bitcoin clients will validate against that PQ pubkey. I think your proposal has a major benefit over mine in that it makes soft-fork compliance way easier. My DASK idea seems like it would need a hard fork on Q-Day, but yours would seem to be fully compatible with old clients. Big props 🎉 One idea from my post which I think you might want to consider copying is: Instead of committing to a SPHINCS key on-chain, commit to a hash-based certification key with shorter signatures, like WOTS. Yes, it's a one-time signature scheme so we can't reuse the key, but we can be pretty sure than post-quantum cryptography will progress a long way in the coming decades, and we can use that one-time signature (which we are highly confident is secure today) to endorse a post-quantum key for a signature algorithm that might not exist yet, or that might exist today but that we don't know is secure, like Kyber. Your opcode soft-fork would have to specify the exact validation semantics later, but the WOTS authentication key has already been committed to, so the coins are safe.

Replies (1)

Yes, I saw your post, I thought it was quite clever! That said, I think the Taproot approach is slightly cleaner - it allows wallets more flexibility (eg they could use a static PQ key for all their addresses, and no one would ever know unless they were used). In terms of one-time vs larger-signatures, my mental model here is basically this stuff will only be used on the margin. Wallets that upgrade today and that people don’t touch for two decades will be safe, but wallets people sure actively using in five or seven years might use other, newer options for PQC. Thus, a bit worse design is fine, if it makes the solution more bulletproof. Now, that said, maybe that’s indeed an argument for a single-use scheme, just because it’s simpler to implement.