From: "'Mikhail Kudinov' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Ethan Heilman <eth3rs@gmail.com>, Erik Aronesty <erik@q32.com>,
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: Fri, 27 Feb 2026 16:18:46 +0100 [thread overview]
Message-ID: <CAPcK4uQvkjUAAvVxS2+gX8VBiXp5cnxvCURRtkJSOMU5wfRVHA@mail.gmail.com> (raw)
In-Reply-To: <1ee30c09-ca46-404f-a9f4-2ff8ff6a2c0b@mattcorallo.com>
[-- Attachment #1: Type: text/plain, Size: 4876 bytes --]
Speaking of Lattice-Based solutions. There has been significant progress in
adopting PQ solutions in the real world. Signatures are not as widely
deployed, but the work is going on. There is a recent update from Apple:
https://support.apple.com/guide/security/quantum-secure-cryptography-apple-devices-secc7c82e533/web
.
An interesting point is that it does not use level 1 security for lattice
schemes (it offers level 3 or level 5, both for ML-KEM and ML-DSA). A
similar approach was used in Cloudflare:
https://blog.cloudflare.com/pq-2025/. More specifically, see this part:
https://blog.cloudflare.com/pq-2025/#ml-kem-768-and-x25519. Let me cite Bas
here: "There is a lot of trust in the (non post-quantum) security of
X25519: matching AES-128 is more than enough. Although we are comfortable
in the security of ML-KEM-512 today, over the coming decades, cryptanalysis
could improve. Thus, we'd like to keep a margin for now."
Cloudflare settles for a smaller margin for ML-DSA, but the reasoning is
that they can upgrade later if needed:
"ML-DSA-44 as level 2 is comfortably above level 1. It's indeed below
ML-KEM-768. I'd be comfortable with level 2 ML-KEM, but that doesn't exist.
Anyway, ML-DSA requires less margin as it doesn't suffer
store-now/decrypt-later. We can roll ML-DSA certs if attacks improve, but
we can't roll captured data encrypted with ML-KEM."
In our setting, switching to a new set of parameters is more difficult.
So, it seems reasonable that, if we are discussing a lattice-based
construction, we should also include some margin. That said, if we exclude
level 1 security, the smallest size we get is 3073 bytes for Falcon level
5. See https://pqshield.github.io/nist-sigs-zoo/ for a quick comparison.
Level 3 ML-DSA requires 5,261 bytes.
Of course, lattice constructions have more to offer than just smaller
sizes. Different schemes may allow for public key derivation, maybe more
efficient multi/threshold signatures, and so on. We should keep in mind
that, if we want to include a security margin for possible future
improvements, the sizes will be larger.
Best,
Mike
On Thu, Feb 26, 2026 at 4:56 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:
>
>
> 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
> .
>
--
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/CAPcK4uQvkjUAAvVxS2%2BgX8VBiXp5cnxvCURRtkJSOMU5wfRVHA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 6213 bytes --]
next prev parent reply other threads:[~2026-02-27 16:39 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
2026-02-27 15:18 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List [this message]
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=CAPcK4uQvkjUAAvVxS2+gX8VBiXp5cnxvCURRtkJSOMU5wfRVHA@mail.gmail.com \
--to=bitcoindev@googlegroups.com \
--cc=conduition@proton.me \
--cc=erik@q32.com \
--cc=eth3rs@gmail.com \
--cc=garlonicon@gmail.com \
--cc=jonasd.nick@gmail.com \
--cc=lf-lists@mattcorallo.com \
--cc=mkudinov@blockstream.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