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.
https://conduition.io/cryptography/quantum-hbs/#Upgrading-BitcoinI 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.
