Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms

Erik Aronesty
2026-02-23T19:19:53Z

[-- Attachment #1: Type: text/plain, Size: 3016 bytes --]

>
>
>
> 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.

--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAJowKgL%2BYMWSgEPcVF-u8bNvPFK35cY-3cHtimWD2mtXdDhUzQ%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 4215 bytes --]