From: Matt Corallo <lf-lists@mattcorallo.com>
To: Ethan Heilman <eth3rs@gmail.com>, Erik Aronesty <erik@q32.com>
Cc: conduition <conduition@proton.me>,
"garlonicon@gmail.com" <garlonicon@gmail.com>,
Jonas Nick <jonasd.nick@gmail.com>,
bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Algorithm Agility for Bitcoin to maintain security in the face of quantum and classic breaks in the signature algorithms
Date: Thu, 26 Feb 2026 10:51:28 -0500 [thread overview]
Message-ID: <1ee30c09-ca46-404f-a9f4-2ff8ff6a2c0b@mattcorallo.com> (raw)
In-Reply-To: <CAEM=y+WAR3YXmdrrT-zN210ob53dmYC1KZwBZ=OK2bKgNeAHUg@mail.gmail.com>
On 2/23/26 4:42 PM, Ethan Heilman wrote:
> > 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.
Why not just do SHRINCS today? The cost to use it in "stateless mode" is only marginally higher than
other stateless hash-based signatures, and wallets can elect to use the stateful mode at signing
time if they're set up for it.
Matt
--
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/1ee30c09-ca46-404f-a9f4-2ff8ff6a2c0b%40mattcorallo.com.
next prev parent reply other threads:[~2026-02-26 15:56 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 14:20 Ethan Heilman
2026-02-10 8:53 ` Jonas Nick
2026-02-10 16:44 ` Ethan Heilman
[not found] ` <CAJowKg+WJLAJoMhyhVfkC9OSdks5jBieDWty9ce-Qju-84URFA@mail.gmail.com>
2026-02-10 23:13 ` Ethan Heilman
2026-02-11 0:19 ` Erik Aronesty
2026-02-11 2:40 ` Ethan Heilman
2026-02-11 7:25 ` Erik Aronesty
2026-02-11 16:37 ` Ethan Heilman
2026-02-17 4:13 ` 'conduition' via Bitcoin Development Mailing List
2026-02-17 7:39 ` 'conduition' via Bitcoin Development Mailing List
2026-02-19 14:35 ` Garlo Nicon
2026-02-20 1:41 ` Alex
2026-02-20 18:48 ` Erik Aronesty
2026-02-23 14:00 ` 'conduition' via Bitcoin Development Mailing List
2026-02-23 19:08 ` Erik Aronesty
2026-02-23 21:42 ` Ethan Heilman
2026-02-24 0:12 ` Alex
2026-02-25 10:43 ` Javier Mateos
2026-02-26 13:24 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-02-26 15:51 ` Matt Corallo [this message]
2026-02-27 15:18 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-02-27 19:31 ` 'conduition' via Bitcoin Development Mailing List
2026-03-01 12:24 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2026-03-01 21:28 ` Alex
2026-02-11 18:53 ` Matt Corallo
2026-02-11 22:57 ` Ethan Heilman
2026-02-12 14:55 ` Matt Corallo
2026-02-12 15:35 ` Alex
2026-02-12 19:20 ` Matt Corallo
2026-02-12 18:08 ` Ethan Heilman
2026-02-12 19:13 ` Matt Corallo
2026-02-12 20:35 ` Ethan Heilman
2026-02-12 20:43 ` Matt Corallo
2026-02-12 15:13 ` Alex
2026-02-12 19:16 ` Matt Corallo
2026-02-12 15:36 ` waxwing/ AdamISZ
2026-02-12 19:35 ` Matt Corallo
2026-02-12 19:43 ` Matt Corallo
2026-02-14 12:39 ` waxwing/ AdamISZ
2026-02-15 12:12 ` Matt Corallo
2026-02-10 21:51 ` 'Brandon Black' via Bitcoin Development Mailing List
2026-02-10 22:19 ` Ethan Heilman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1ee30c09-ca46-404f-a9f4-2ff8ff6a2c0b@mattcorallo.com \
--to=lf-lists@mattcorallo.com \
--cc=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--cc=erik@q32.com \
--cc=eth3rs@gmail.com \
--cc=garlonicon@gmail.com \
--cc=jonasd.nick@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox