Thank you! I think some newer and better approaches than DASK have been proposed since i wrote this article and which would allow us to more easily implement these changes as a soft fork without any new address formats needed. Check out @MattCorallo’s post on the mailing list here.
Matt’s soft-fork proposal is to disable key-spending on P2TR addresses, and define one of the OP_SUCCESS opcodes reserved by BIP342 to validate a post-quantum signature scheme in a taproot script-path spend branch.
This implies some additional fun twists, such as the fact that one must now carefully hide this OP_SUCCESS script branch until activation day, otherwise it could be spent by literally anybody. But in principle it seems much more achievable to me than DASK, so i’m wholeheartedly in favor. If we were going to write a BIP, i think Matt’s idea would be the way to go. All power to you for writing that draft BIP but I think we should try to reuse P2TR if we can, so that we can get the space saving benefits of taproot for as long as possible.
He suggests using SPHINCS right off the bat for this, but i think a WOTS certification layer would be way better for future-proofing. Surely SPHINCS isn’t the best we will ever have. We could also use WOTS or FORS to directly sign a transaction instead, which would be even more efficient but less flexible/safe. So there’s still some kinks to iron out.
The action steps i can see would be:
- Find consensus on a flavor of hash-based signatures (i’m partial to Compact WOTS+C personally)
- Determine whether to use it as a certification layer or to sign transactions directly
- Create a reference implementation of the signature scheme (specifically key-generation)
- Define the ground rules for how validation of the new opcode should work (following past BIPs as examples should help). New rules, such as the specific signature scheme to certify with WOTS, can be added later, since we’re not planning to activate this upgrade for a long time.
- Write it all down in a BIP and start collecting feedback
A separate client-side BIP could be written to define deterministic key-gen of the HBS keypair, safe and future-proof taptree structure, etc.
I’m unfortunately tied up helping a full-time client at the moment and can’t spare the time to pursue these things myself, but I’d be happy to review if this is something you’re interested in.