You don't need "the perfect signature" on day 1, you just need something everyone can agree on is good enough as a migration step. SLH-DSA can indeed fill that role - it means a transaction will cost about 10x more than now.

Whether SLH-DSA or ML-DSA is picked is IMO less important because eventually "the perfect signature" will be ready: https://sqisign.org/

SQIsign is 65 + 148 bytes and my DDR3 era Haswell PC (from 2014) can verify 1000 sigs per second using the non-optimized reference implementation. A modern budget CPU can do 30k verifications per second.

You only need SLH-DSA as an (optional) signature that maybe is never even used at all. It's just an insurance. When I hear people say "we don't need this we can just make a ZK proof of the seed phrase" - I'm pretty sure such a ZK proof is much larger than SLH-DSA anyways and would require a total halt of the Bitcoin network and be way less efficient. With SLH-DSA you would get that migration done seamlessly and more efficient anyways.

måndag 23 februari 2026 kl. 23:03:03 UTC+1 skrev Ethan Heilman:

>  I thought "tweaking", in general, is lost in SPHINCS, as well as multiparty sigs.  Be interested to see those solutions.   But, regardless, 17kb sigs are... not compatible with a decentralized bitcoin, imo.   Lattice-sigs are the only reasonable PQ way forward and they aren't ready yet.

SPHINCS is ~8kb (7,888 bytes) not 17kb.

SPHINCS SLH-DSA-128s has 32 byte public keys and 7,856 byte signatures
Total size of 7,888 bytes not 17kb.

The Lattice sigs aren't that much better than  SPHINCS

CRYSTALS-Dilithium ML-DSA has 1,312 byte public keys and 2,420 byte signatures
Total size of 3,732 bytes.

Falcon has 897 byte public keys and 666 signatures
1,563 bytes

ML-DSA currently has the most support in the Lattice world, but it is still too large to be a drop in replacement for ECC without a witness discount. If we had to choose tomorrow, I'd advocate for ML-DSA with a massive witness discount, but I'd be very unhappy with the witness discount. If the witness discount was out of the question, then I'd advocate for something similar to 324-byte stateful hash based SHRINCS signature. Neither is ideal.

My current thinking is to use SLH-DSA as a backup. This keeps us safe if everything goes wrong and allows us to reach safety early so we can take time to determine the right drop-in replacement for ECC. Hopefully in 3 years, SQI-sign is fast enough to be considered.

On Mon, Feb 23, 2026 at 2:08 PM Erik Aronesty <er...@q32.com> wrote:

I'd be excited to learn about this as an option. Erik, could you please answer my previous questions about the viability of your linked protocol? I'm not questioning its quantum-resistance properties (yet). I'm wondering how it is possible to instantiate this scheme in a way that allows a wallet to actually use this commit/reveal scheme without knowing the final destination CTV templates (denoted T & E in the delving post) in advance of creating the phase 0 locking script.

I provided an example script that shows how it works: https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2. you don't pin to the final destination in phase 0.

txhash is a partial-commitment, not over all fields.  this give the flexibility needed for the final spend, since you don't commit to it.   

however someone has pointed out a fee-problem that CCV's value-aware composability can solve.   coming around to thinking the ccv-based construction would be necessary.   CCV is more powerful but requires much more care in policy and analysis.  CTV is trivial, we could merge it tomorrow and hardly worry about surface area issues.   TXHASH is only slightly more complicated.  CCV has a much bigger burden of proof around implementation and node safety... but i think you could do many kinds of vaulting schemes with it alone.

But in the case of hash-based signature (HBS) schemes, i disagree. HBS is already mature. Whatever cryptanalytic breakthroughs the future holds, we can be reasonably sure that SHA256 preimage resistance will hold for a long time, so HBS security will hold. Even today md4 and md5 preimage resistance still holds. Securing coins using hashes alone is the ideal fallback, and even if HBS is not the most efficient class of schemes, that doesn't matter so much if we don't use HBS as our primary everyday signature scheme. Its value lies in security, not efficiency.

When I mean "too soon", I'm including SPHINCS, not sure what

1. Earlier versions of the SPHINCS framework were found to be susceptible to fault attacks
2. Earlier "Tight" proof for v1 SPHINCS was flawed, leading to 60 bits of security, not 128

> If you're worried about stuff like how xpubs would work with HBS, we have solutions for that too, and they are mostly drop-in replacements for existing standards.

I thought "tweaking", in general, is lost in SPHINCS, as well as multiparty sigs.  Be interested to see those solutions.   But, regardless, 17kb sigs are... not compatible with a decentralized bitcoin, imo.   Lattice-sigs are the only reasonable PQ way forward and they aren't ready yet.