From: david torrealba <davidtorrealba123@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future
Date: Wed, 24 Dec 2025 07:02:21 -0800 (PST) [thread overview]
Message-ID: <769f97ee-7874-44cd-acdd-a9d283f79430n@googlegroups.com> (raw)
In-Reply-To: <CAJowKgL-VBTgbacpbPStGMqe6u6Y7wB6fWNiGy28zWfkCODp=A@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3570 bytes --]
Hi everyone,
I've been following the discussion regarding the trade-offs of Post-Quantum
signature sizes and their performance impacts on low-power devices.
I wanted to share some practical insights from the *Cellframe* project that
might be relevant to these benchmarks. We have been running a C-based
blockchain implementation that natively supports multiple NIST-candidate
post-quantum algorithms (including *Crystal-Dilithium/ML-DSA* and others
discussed here) for several years.
Since our core is written in C with a focus on hardware optimization
(specifically targeting low-end embedded devices alongside high-performance
nodes), we have gathered significant real-world data regarding:
1.
Memory Footprint: The actual dynamic RAM usage differences between
Lattice-based vs. Hash-based signatures on constrained hardware.
2.
Verification Time*:* Concrete signing/verification times on low-power
ARM architectures when the code is highly optimized in C.
If the working group is interested, we would be happy to share our
benchmarks and optimization techniques to help validate the theoretical
constraints currently being discussed for Bitcoin's PQ transition. We
believe our experience dealing with the signature size overhead in a live
production environment could provide a useful reference point.
Best regards,
El sábado, 20 de diciembre de 2025 a las 8:04:18 UTC-4, Erik Aronesty
escribió:
> this scheme has no mitm attack or replay attack because of the use of
> covenants to secure each step in the chain
>
> The best part about starting with something like this is that we can have
> a safe quantum vault, too useful covenants that are broadly helpful for
> other vaulting schemes, while we develop a proper library that is both
> performant and efficient for quantum signatures.
>
> secp256k1 has been optimized to the point where timing attacks are
> challenging, and I wouldn't want to use some sort of quantum library that
> hasn't had that level of optimization.
>
> simple commit reveal schemes use hashes that are well known to be quantum
> resistant. I consider that a lot safer at first step forward. especially
> because we can take that step sooner than later without too much discussion
> over implementation since the underlying covenants have been well studied.
> (txhash and ctv)
>
> we can't say that about any signature schemes.
>
>
>
> On Fri, Dec 19, 2025, 3:34 AM Jonas Nick <jonas...@gmail.com> wrote:
>
>> This appears to be a variant of a commit-reveal scheme, a design that has
>> been
>> discussed a few times on this mailing list. Commit-reveal schemes come
>> with
>> their own set of trade-offs.
>>
>> --
>> 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/b6df02a0-8d69-4882-a13c-411bc90adfa1%40gmail.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/769f97ee-7874-44cd-acdd-a9d283f79430n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 5276 bytes --]
prev parent reply other threads:[~2025-12-27 0:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-08 20:28 [bitcoindev] " 'Mikhail Kudinov' via Bitcoin Development Mailing List
2025-12-08 21:50 ` Greg Maxwell
2025-12-09 5:08 ` 'conduition' via Bitcoin Development Mailing List
2025-12-10 0:41 ` Olaoluwa Osuntokun
2025-12-09 8:06 ` [bitcoindev] " Boris Nagaev
2025-12-09 22:48 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2025-12-09 23:06 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2025-12-10 0:01 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2025-12-10 0:14 ` 'conduition' via Bitcoin Development Mailing List
2025-12-10 15:55 ` Jonas Nick
2025-12-10 0:53 ` Olaoluwa Osuntokun
2025-12-16 7:25 ` Jonas Nick
2026-01-19 1:12 ` 'conduition' via Bitcoin Development Mailing List
2025-12-18 18:45 ` Erik Aronesty
2025-12-19 8:36 ` Jonas Nick
2025-12-20 1:14 ` Erik Aronesty
2025-12-24 15:02 ` david torrealba [this message]
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=769f97ee-7874-44cd-acdd-a9d283f79430n@googlegroups.com \
--to=davidtorrealba123@gmail.com \
--cc=bitcoindev@googlegroups.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