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:

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.

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.