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

Alex
2026-03-01T21:34:08Z

[-- Attachment #1.1: Type: text/plain, Size: 9128 bytes --]

> I don’t think that Fault attacks are mitigated for SLH-DSA, the
mitigation that is available is to run the signing process multiple times
and check if the signatures are the same. But fault injection attacks
require physical access to signing device with the ability to flip at least
one bit during the computation.

Whether a signing device has an implementation bug/issue that flips bits
and therefore exposes private information or not is irrelevant to the
Bitcoin network. The Bitcoin network only _verifies_ SLH-DSA. Highly
academic "what ifs" regarding "what if we corrupt memory of the signer
while it signs" is just that, academic. In reality, SLH-DSA does not have
any known weakness for validation and the algorithm is standardized PQC
NIST algo.

If your Trezor/Ledger/mobile phone device can't hold RAM non-corrupt while
it runs a signing algo, you have bigger problems.

SLH-DSA is not in need for any mitigations. If implementations cannot trust
their RAM they need to emulate error corrected RAM or use error corrected
RAM. It's an implementation detail of the signer.

In any case, hyper focusing on SLH-DSA is really missing the point of this
thread. The point is "algorithmic agility" meaning, we need to have a way
to support many algos, including SLH-DSA and/or ML-DSA. And the proposed
overall solution in this tread is to have those algos as OP-codes that are
invoked via a spending script that is part of a bigger Merkle tree of
spending scripts that optionally can be invoked as we find out what algos
are broken and which are not.
söndag 1 mars 2026 kl. 13:30:52 UTC+1 skrev Mikhail Kudinov:

> I don’t think that Fault attacks are mitigated for SLH-DSA, the mitigation
> that is available is to run the signing process multiple times and check if
> the signatures are the same. But fault injection attacks require physical
> access to signing device with the ability to flip at least one bit during
> the computation.
>
> As for the security proof.
> There was a problem with the old security proof, but the scheme still had
> a proof, just not as tight as it was claimed. The problem with the proof
> did not constitute any attack. A new proof was constructed with out
> changing the scheme even slightly. This new proof was later formally
> verified with EasyCrypt:
> https://eprint.iacr.org/2024/910
>
> Пт, 27 февр. 2026 г. в 22:21, 'conduition' via Bitcoin Development Mailing
> List <bitco...@googlegroups.com>:
>
>> I thought "tweaking", in general, is lost in SPHINCS, as well as
>> multiparty sigs. Be interested to see those solutions.
>>
>>
>> This is correct, but you don't actually need public-key tweaking to use
>> an SLH-DSA pubkey as a backup for an ECC xpub. You can just append the
>> SLH-DSA public key to a BIP32 xpub, and use the result to construct
>> PQ-hybridized child addresses. For privacy we can attach a pseudorandom
>> nonce derived from the chaincode, to prevent on-chain fingerprinting of
>> unused BIP360 leaves. The resulting tap leaf hash looks random, and the
>> SLH-DSA public key (and nonce) is only revealed if used for spending.
>>
>> All this will be spec'd out as part of a non-consensus BIP, to help
>> wallets build safe and robust quantum-resistant addresses.
>>
>> 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.
>>
>>
>> This pseudocode seems to commit the CTV hashes T & E in the anchor_script
>> <https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2#file-gistfile1-txt-L305> which
>> is used to construct the funding UTXO
>> <https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2#file-gistfile1-txt-L324-L328>.
>> This is exactly the problem I mentioned which would prevent this technique
>> from being usable as a PQ fallback script.
>>
>> 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.
>>
>>
>> You've stated specifically in your post that TXHASH enforces that the
>> AnchorPublishTx​ creates a UTXO paying to P_anchor​.
>>
>> OP_TXHASH is used only in Phase 0 to enforce a partial covenant... [that] pins
>> the next envelope (P_anchor)
>>
>>
>> You've also stated that P_anchor​ commits to the CTV template hashes T​ &
>> E​.
>>
>> P_anchor: Taproot output key committing to an Anchor script tree that ... enforces
>> reveal-or-escape spending conditions
>>
>>
>> This statement is backed up by the pseudocode which depends on T​ and E​
>> when constructing P_anchor​, as i pointed out earlier in this email.
>>
>> Thus, TXHASH (and by extension, the funding script pubkey) commits to CTV
>> hashes T​ & E​, yes?
>>
>> Perhaps it would help if you mentioned which TxFieldSelector​ you are
>> using, otherwise i'm just left to guess. The pseudocode is unclear.
>>
>> regards,
>> conduition
>>
>> On Monday, February 23rd, 2026 at 11:08 AM, 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.
>>
>>
>> --
>> 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+...@googlegroups.com.
>>
> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/xGWRYbDSxkWxiv5eYH_LbX3hTXs1x2wrn6ar5EfMKKCwvRAT137keXQZqs9SaeTxOjrb5tziRcFU82wSPGD-QVokCrA-Aikfr4vktqSvK7c%3D%40proton.me
>> <https://groups.google.com/d/msgid/bitcoindev/xGWRYbDSxkWxiv5eYH_LbX3hTXs1x2wrn6ar5EfMKKCwvRAT137keXQZqs9SaeTxOjrb5tziRcFU82wSPGD-QVokCrA-Aikfr4vktqSvK7c%3D%40proton.me?utm_medium=email&utm_source=footer>
>> .
>>
>

--
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/187d45c3-2b19-4d57-99cb-e6511818d6b7n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 18644 bytes --]