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.