From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 26 Dec 2025 16:53:12 -0800 Received: from mail-qv1-f62.google.com ([209.85.219.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vZIYR-0003Lz-5z for bitcoindev@gnusha.org; Fri, 26 Dec 2025 16:53:12 -0800 Received: by mail-qv1-f62.google.com with SMTP id 6a1803df08f44-88883a2cabbsf276178856d6.0 for ; Fri, 26 Dec 2025 16:53:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1766796780; x=1767401580; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=lI5KfWVXCwmUf3oULLeh3OwuOza4GhrY2IncZjmTxpI=; b=f6VTxO+tK+TILJCqZdkFXY3VR8KlDCJVF0zPDW5L794BFXBLTK/GhOl6QHEF5AVQFB FKMnO/8guLO72V7/U2Z0mPLB1ZcumDVygUdqO7+tZElAJ2C9B7IEPoaQ0FJaR2pUcGQ2 e3MR784jWWy3NbbAbwHUARVa06Z/IT1wePIy7aNZ98/SQ7z3eDGJYzZxQwJ1Xr4RdB3V 7H1oXGghArmGmCkSx/x2pvG2FRUCu1bdAaoLUyihcXTUDjWmkjel3WrHNP0mG9AbnR4R LyLz/luOvjZDpGOawMhZyB24MKIDMLzaM96cpx5e8Uw+SzkabF/HJ9FVSiSXe3Wsl365 E1gw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766796780; x=1767401580; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=lI5KfWVXCwmUf3oULLeh3OwuOza4GhrY2IncZjmTxpI=; b=aT0xrrV58rxc+XFchYBtxOO+sNWUrndcufvqSoqQnFEcimzJffmHTmIaJacnzJvT4v vCCMlEfJ20Q/czUBqLXUx6r9c4Pluq4zCSKkMO86luNiTi8kJcJksoaUiAI4BGcgWRJl Rv7H126NSSuhRt5GqQp6NYbY3eCOSVtFqOgEOruJoW5G2QQl7mJH6AVDfJkY5DdtZsBI /+/E5EFkMrvH/wFTjrH7KrM9nNW5i/AyjAeWRouQ8/dNMclllCSmYQDDUIBneQfwZCCz FZL6SYKEQ8mtrLB0/vodktHCrRXfteXQsrXTghztSikpE5z3eHmy6Jsa5IXcPsuIs6tG xuFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766796780; x=1767401580; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=lI5KfWVXCwmUf3oULLeh3OwuOza4GhrY2IncZjmTxpI=; b=S6/gDoKkabTd658mJQpHT6/FqpCQno/mDr/cb3iqO0TlJxGEZbgUyzM5zChWW8BIfH bM00Vmw+UTBx+jun3dpOpveDrbLUeMPCk6XidKSiH2/ePecgzXCKEweX7BNc7auOZrLo bVFTPbQ28FIxQm5vF6tHp9zWoQP7oQd0NBDC8sNPHL4V1t7PiFZmizg2g53DTuC3/BqR E6nWu1vt4LwjtHJSz9I6udWgBzrPXjQkQhs8WUodiA86Fv2gSFh1oasiBA0LMC01e0aA Hjpc/4FYKUq+FT3TcnW5wvVPI40Gx1YO7H2h7cx7OvCHwH8nUogSo7hwy3+3HasMTM1Z DH4Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVkHgJNDV9CEPhgeuxNjSpvRYKtGc/Ie/FIf36fzHQ3ZoWoUEa1TShxWXqJ69qScb4VgX8yF6kDX60m@gnusha.org X-Gm-Message-State: AOJu0Yystzz/BrHmDtdoJ3dGPJHrV5iFAN/y0RIIJaMMkFVZpsYfDjKv vviwDaVKTDYdqK3T75mCOUAaCq3AWnKJ40+pu67NEUyX8yq9M/TW5O7J X-Google-Smtp-Source: AGHT+IEIaJj41AT8WKoMZ8EXIUmJD+FOH0R0EfW9tkI7NAbduVUtVufBIl9RPOZ22wfxm59f/2I2NA== X-Received: by 2002:a05:6214:c4a:b0:880:4c2d:dc8c with SMTP id 6a1803df08f44-88d857cf921mr513354486d6.18.1766796780078; Fri, 26 Dec 2025 16:53:00 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWYe5hPQ4KmJAFjLfjvPnJ7JaB0KuOz/qRrjcTEHdue8ww==" Received: by 2002:a05:6214:c46:b0:882:63fc:f004 with SMTP id 6a1803df08f44-89012a0f06fls2131126d6.2.-pod-prod-03-us; Fri, 26 Dec 2025 16:52:53 -0800 (PST) X-Received: by 2002:a05:620a:4620:b0:8b2:ec00:7846 with SMTP id af79cd13be357-8c08fd02fdcmr3411005285a.28.1766796773650; Fri, 26 Dec 2025 16:52:53 -0800 (PST) Received: by 2002:a05:690c:688c:b0:786:8d90:70d8 with SMTP id 00721157ae682-78fb3c672f8ms7b3; Wed, 24 Dec 2025 07:02:22 -0800 (PST) X-Received: by 2002:a05:690e:128f:b0:644:60d9:7527 with SMTP id 956f58d0204a3-6466a8de0c5mr14669089d50.89.1766588541611; Wed, 24 Dec 2025 07:02:21 -0800 (PST) Date: Wed, 24 Dec 2025 07:02:21 -0800 (PST) From: david torrealba To: Bitcoin Development Mailing List Message-Id: <769f97ee-7874-44cd-acdd-a9d283f79430n@googlegroups.com> In-Reply-To: References: <3e815d03-5e21-41ed-ba1a-4f9b2120a986n@googlegroups.com> <60d61084-f1aa-4911-a615-77d8597645c0n@googlegroups.com> Subject: Re: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_17124_2043481857.1766588541283" X-Original-Sender: davidtorrealba123@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_17124_2043481857.1766588541283 Content-Type: multipart/alternative; boundary="----=_Part_17125_1294813974.1766588541283" ------=_Part_17125_1294813974.1766588541283 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, I've been following the discussion regarding the trade-offs of Post-Quantum= =20 signature sizes and their performance impacts on low-power devices. I wanted to share some practical insights from the *Cellframe* project that= =20 might be relevant to these benchmarks. We have been running a C-based=20 blockchain implementation that natively supports multiple NIST-candidate=20 post-quantum algorithms (including *Crystal-Dilithium/ML-DSA* and others=20 discussed here) for several years. Since our core is written in C with a focus on hardware optimization=20 (specifically targeting low-end embedded devices alongside high-performance= =20 nodes), we have gathered significant real-world data regarding: 1.=20 =20 Memory Footprint: The actual dynamic RAM usage differences between=20 Lattice-based vs. Hash-based signatures on constrained hardware. 2.=20 =20 Verification Time*:* Concrete signing/verification times on low-power=20 ARM architectures when the code is highly optimized in C. =20 If the working group is interested, we would be happy to share our=20 benchmarks and optimization techniques to help validate the theoretical=20 constraints currently being discussed for Bitcoin's PQ transition. We=20 believe our experience dealing with the signature size overhead in a live= =20 production environment could provide a useful reference point. Best regards, El s=C3=A1bado, 20 de diciembre de 2025 a las 8:04:18 UTC-4, Erik Aronesty= =20 escribi=C3=B3: > this scheme has no mitm attack or replay attack because of the use of=20 > covenants to secure each step in the chain > > The best part about starting with something like this is that we can have= =20 > a safe quantum vault, too useful covenants that are broadly helpful for= =20 > other vaulting schemes, while we develop a proper library that is both=20 > performant and efficient for quantum signatures. =20 > > secp256k1 has been optimized to the point where timing attacks are=20 > challenging, and I wouldn't want to use some sort of quantum library that= =20 > hasn't had that level of optimization.=20 > > simple commit reveal schemes use hashes that are well known to be quantum= =20 > resistant. I consider that a lot safer at first step forward. especially= =20 > because we can take that step sooner than later without too much discussi= on=20 > over implementation since the underlying covenants have been well studied= .=20 > (txhash and ctv) > > we can't say that about any signature schemes. > > > > On Fri, Dec 19, 2025, 3:34=E2=80=AFAM Jonas Nick wro= te: > >> This appears to be a variant of a commit-reveal scheme, a design that ha= s=20 >> been >> discussed a few times on this mailing list. Commit-reveal schemes come= =20 >> with >> their own set of trade-offs. >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/b6df02a0-8d69-4882-a13c-411= bc90adfa1%40gmail.com >> . >> > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 769f97ee-7874-44cd-acdd-a9d283f79430n%40googlegroups.com. ------=_Part_17125_1294813974.1766588541283 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi everyone,

I've been following the discussion regarding the trad= e-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 mul= tiple NIST-candidate post-quantum algorithms (including Crystal-Dilithiu= m/ML-DSA and others discussed here) for several years.

Since our = core is written in C with a focus on hardware optimization (specifically ta= rgeting 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. Ver= ification Time: Concrete signing/verification times on low-power ARM= architectures when the code is highly optimized in C.

If t= he working group is interested, we would be happy to share our benchmarks a= nd optimization techniques to help validate the theoretical constraints cur= rently being discussed for Bitcoin's PQ transition. We believe our experien= ce dealing with the signature size overhead in a live production environmen= t could provide a useful reference point.

Best regards,


El s=C3=A1bad= o, 20 de diciembre de 2025 a las 8:04:18 UTC-4, Erik Aronesty escribi=C3=B3= :
this scheme has no mitm attack or replay attack because of the use o= f covenants to secure each step in the chain

The best part about starting with something like this is tha= t we can have a safe quantum vault, too useful covenants that are broadly h= elpful for other vaulting schemes, while we develop a proper library that i= s both performant and efficient for quantum signatures.=C2=A0=C2=A0

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 optimiz= ation.=C2=A0

simple comm= it 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 implemen= tation since the underlying covenants have been well studied. (txhash and c= tv)

we can't say tha= t about any signature schemes.



On Fri, Dec 19, 2025, 3:3= 4=E2=80=AFAM Jonas Nick <jona= s...@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 &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+..= .@googlegroups.com.
To view this discussion visit https://= groups.google.com/d/msgid/bitcoindev/b6df02a0-8d69-4882-a13c-411bc90adfa1%4= 0gmail.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/769f97ee-7874-44cd-acdd-a9d283f79430n%40googlegroups.com.
------=_Part_17125_1294813974.1766588541283-- ------=_Part_17124_2043481857.1766588541283--