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.
Replies (1)
I definitely agree, taproot approach is much better. I updated my post to point to yours. DASK is neat but I don't think we need to be that fancy, and your Taproot approach is more soft-fork friendly.
I do still think using a lighter-weight signature scheme like WOTS for certification would be better and more future proof than committing directly to SPHINCS right now.
If we do end up wanting to use SPHINCS in 20-30 years, it'd still be an option: Just enforce that the WOTS key must sign a SPHINCS pubkey, and verify everything else against the certified SPHINCS key. That would only add a kilobyte to the already-huge SPHINCS signature data.
Think of it this way: if you're correct and this is just an edgecase fallback opcode that only a few people ever end up using, then do we really want the huge kitchen-sink of bringing SPHINCS into the bitcoin consensus layer, just for it to be barely ever used?
On the other hand, if this PQ fallback opcode is used a LOT, then we stand to save a LOT of witness space by biding our time and seeing where the cards fall on the landscape of many-time post-quantum signatures, rather than committing to huge SPHINCS signatures today.
