From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 08 Dec 2025 12:47:56 -0800 Received: from mail-oo1-f64.google.com ([209.85.161.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vSi9D-0003Lm-KR for bitcoindev@gnusha.org; Mon, 08 Dec 2025 12:47:56 -0800 Received: by mail-oo1-f64.google.com with SMTP id 006d021491bc7-6597c514eddsf2252498eaf.1 for ; Mon, 08 Dec 2025 12:47:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765226869; x=1765831669; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:message-id:to:from:date:from:to:cc:subject :date:message-id:reply-to; bh=GWNDw6anDM2WsD+DkKPuGVPfsXfa+q8izthVSAcWptY=; b=WgT/4HMzBxmvALYlA4RTijE1E2PbfMgm2S6ya6/rzBOA5yG7v13oJlccUazDuXNQYg CIovZPdHcvE5A0ABEYBk4SWz76smI8ebNtPBYq3Eukn4WPeV4k0Ln+HUNjK6vAR15b9U MIjtNM167kRrr/tAWz8FQYY/zhyi1vZHuz/Q/qnRPJlv8NOVxlCqn+ysU5aI7h1FKCHg yrkpCjU6MVyjH6kuF6GA89vH2NEIlS7VGKGeh1OWOMb9hiKgWuz7VV4of9C1i8MMHGpF Clsd+HnGsZorkRyaCn40Mg+eYs9wzCnnPODCxWmC2pt1gb5nJ9RGidlMlWvzm+KdGsTH +Lig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765226869; x=1765831669; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:message-id:to:from:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GWNDw6anDM2WsD+DkKPuGVPfsXfa+q8izthVSAcWptY=; b=FGIcMb+3x/t/7GnhZuA9Krrr7GkAGPU8tnZRg4mFXu+iXLfGoW5QaCdotR16nPAI6P sKvagfzvWL11JCRqMZaTR/sVTUnk5gJegyUP6GzebqMZpcPAk3DUsyegG53JbcZoU+Al Sk3E6d5UwELS3epuwt3dPE5cZUfNGdPNX8jUCJXYbW9zZxMKluigH3HEWxjxxSxMWIKJ pZJOT7X4CFiOcIrCv+ZPw438ye1TgV97MGCgvOjeg/HosRmyCV4tODJ5Csv+eWZe1obK ojGvtK2XlIbE80vjtB6vhH6oBw44CZBe/aGAqYxqMtVjjiXa/P8uiNNLUp5VYyTtMX3L V2bA== X-Forwarded-Encrypted: i=1; AJvYcCWMdYpP9wCr3j6rd80Wu1tZYOZy+Rt9P9aCP8N+Q6fTuMf7103iIRqnmhFa6PKXAm9J4JP2kRmG7mLE@gnusha.org X-Gm-Message-State: AOJu0Ywx/wk/pDWfbO6dqwoI78ZJ7ux5Ng+o+0vQQo14jdmgKhiy0rws TYi7yWtSFk4paduqXOY4uEi78hHKZPj9jHo4SlX8twpjlCjOKOG1gUqk X-Google-Smtp-Source: AGHT+IFCcqsLtj52I5AXFW82gJkSbaPpXzlDNU8pb4uHPCvL3VQWuVa9eqYoz105qB9FTJOcTDvfvA== X-Received: by 2002:a05:6820:1c89:b0:654:18f9:10f4 with SMTP id 006d021491bc7-6599a7b921bmr3539934eaf.0.1765226868887; Mon, 08 Dec 2025 12:47:48 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWYKRrKHruKQ9m3rgxdk+dG8/KbbxLIsimiXEoCjFp3fog==" Received: by 2002:a05:6820:1606:b0:656:cb78:53d0 with SMTP id 006d021491bc7-6597cfe5ed3ls238240eaf.0.-pod-delta-03-us; Mon, 08 Dec 2025 12:47:43 -0800 (PST) X-Received: by 2002:a05:6808:1304:b0:44f:dfdc:71b2 with SMTP id 5614622812f47-4539e06c07bmr2879323b6e.4.1765226863628; Mon, 08 Dec 2025 12:47:43 -0800 (PST) Received: by 2002:a05:690c:c36b:b0:780:f7eb:fdf with SMTP id 00721157ae682-78c23b71cfdms7b3; Mon, 8 Dec 2025 12:28:57 -0800 (PST) X-Received: by 2002:a05:690c:e3ec:b0:78c:2f4a:b694 with SMTP id 00721157ae682-78c339ef3bamr74624797b3.0.1765225736464; Mon, 08 Dec 2025 12:28:56 -0800 (PST) Date: Mon, 8 Dec 2025 12:28:55 -0800 (PST) From: "'Mikhail Kudinov' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <3e815d03-5e21-41ed-ba1a-4f9b2120a986n@googlegroups.com> Subject: [bitcoindev] Hash-Based Signatures for Bitcoin's Post-Quantum Future MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_175848_1432732483.1765225735834" X-Original-Sender: mkudinov@blockstream.com X-Original-From: Mikhail Kudinov Reply-To: Mikhail Kudinov 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: -1.0 (-) ------=_Part_175848_1432732483.1765225735834 Content-Type: multipart/alternative; boundary="----=_Part_175849_336877375.1765225735834" ------=_Part_175849_336877375.1765225735834 Content-Type: text/plain; charset="UTF-8" Hi everyone, We'd like to share our analysis of post-quantum options for Bitcoin, focusing specifically on hash-based schemes. The Bitcoin community has already discussed SPHINCS+ adoption in previous mailing list threads. We also looked at this option. A detailed technical report exploring these schemes, parameter selections, security analysis, and implementation considerations is available at https://eprint.iacr.org/2025/2203.pdf. This report can also serve as a gentle introduction into hash-based schemes, covering the recent optimization techniques. The scripts that support this report are available at https://github.com/BlockstreamResearch/SPHINCS-Parameters . Below, we give a quick summary of our findings. We find hash-based signatures to be a compelling post-quantum solution for several reasons. They rely solely on the security of hash functions (Bitcoin already depends on the collision resistance of SHA-256) and are conceptually simple. Moreover, these schemes have undergone extensive cryptanalysis during the NIST post-quantum standardization process, adding confidence in their robustness. One of the biggest drawbacks is the signature sizes. Standard SPHINCS+ signatures are almost 8KB. An important observation is that SPHINCS+ is designed to support up to 2^64 signatures. We argue that this bound can be set lower for Bitcoin use-cases. Moreover, there are several different optimizations (like WOTS+C, FORS+C, PORS+FP) to the standard SPHINCS+ scheme, that can reduce the signature size even more. For example, with these optimizations and a bound on 2^40 signatures we can get signatures of size 4036 bytes. For 2^30 signatures, we can achieve 3440 bytes, and for 2^20, one can get 3128 bytes, while keeping the signing time reasonable. We should not forget that for Bitcoin, it is important that the size of the public key plus the size of the signature remains small. Hash-based schemes have one of the smallest sizes of public keys, which can be around 256 bits. For comparison, ML-DSA pk+sig size is at least 3732 bytes. Verification cost per byte is comparable to current Schnorr signatures, alleviating concerns about blockchain validation overhead. As for security targets, we argue that NIST Level 1 (128-bit security) provides sufficient protection. Quantum attacks require not just O(2^64) operations but approximately 2^78 Toffoli depth operations in practice, with limited parallelization benefits. One of the key design decisions for Bitcoin is whether to rely exclusively on stateless schemes (where the secret key need not be updated for each signature) or whether stateful schemes could be viable. Stateful schemes introduce operational complexity in key management but can offer better performance. We explored the possibilities of using hash-based schemes with Hierarchical Deterministic Wallets. The public child key derivation does not seem to be efficiently achievable. The hardened derivation is naturally possible for hash-based schemes. If we look at multi/distributed/threshold-signatures, we find that current approaches either don't give much gains compared to plain usage of multiple signatures, or require a trusted dealer, which drastically limits the use-cases. We welcome community feedback on this approach and hope to contribute to the broader discourse on ensuring Bitcoin's long-term security in the post-quantum era. In particular, we are interested in your thoughts on the following questions: 1) What are the concrete performance requirements across various hardware, including low-power devices? 2) Should multiple schemes with different signature limits be standardized? 3) Is there value in supporting stateful schemes alongside stateless ones? Best regards, Mikhail Kudinov and Jonas Nick Blockstream Research -- 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/3e815d03-5e21-41ed-ba1a-4f9b2120a986n%40googlegroups.com. ------=_Part_175849_336877375.1765225735834 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone,

We'd like to share our analysis of post-quantum opt= ions for Bitcoin, focusing specifically on hash-based schemes. The Bitcoin = community has already discussed SPHINCS+ adoption in previous mailing list = threads. We also looked at this option. A detailed technical report explori= ng these schemes, parameter selections, security analysis, and implementati= on considerations is available at https://eprint.iacr.org/2025/2203.pdf. Th= is report can also serve as a gentle introduction into hash-based schemes, = covering the recent optimization techniques. The scripts that support this = report are available at https://github.com/BlockstreamResearch/SPHINCS-Para= meters .
Below, we give a quick summary of our findings.

We= find hash-based signatures to be a compelling post-quantum solution for se= veral reasons. They rely solely on the security of hash functions (Bitcoin = already depends on the collision resistance of SHA-256) and are conceptuall= y simple. Moreover, these schemes have undergone extensive cryptanalysis du= ring the NIST post-quantum standardization process, adding confidence in th= eir robustness.

One of the biggest drawbacks is the signature si= zes. Standard SPHINCS+ signatures are almost 8KB. An important observation = is that SPHINCS+ is designed to support up to 2^64 signatures. We argue tha= t this bound can be set lower for Bitcoin use-cases. Moreover, there are se= veral different optimizations (like WOTS+C, FORS+C, PORS+FP) to the standar= d SPHINCS+ scheme, that can reduce the signature size even more.
For = example, with these optimizations and a bound on 2^40 signatures we can get= signatures of size 4036 bytes. For 2^30 signatures, we can achieve 3440 by= tes, and for 2^20, one can get 3128 bytes, while keeping the signing time r= easonable.

We should not forget that for Bitcoin, it is importa= nt that the size of the public key plus the size of the signature remains s= mall. Hash-based schemes have one of the smallest sizes of public keys, whi= ch can be around 256 bits. For comparison, ML-DSA pk+sig size is at least 3= 732 bytes.

Verification cost per byte is comparable to current S= chnorr signatures, alleviating concerns about blockchain validation overhea= d.

As for security targets, we argue that NIST Level 1 (128-bit= security) provides sufficient protection. Quantum attacks require not just= O(2^64) operations but approximately 2^78 Toffoli depth operations in prac= tice, with limited parallelization benefits.

One of the key desi= gn decisions for Bitcoin is whether to rely exclusively on stateless scheme= s (where the secret key need not be updated for each signature) or whether = stateful schemes could be viable. Stateful schemes introduce operational co= mplexity in key management but can offer better performance.

We = explored the possibilities of using hash-based schemes with Hierarchical De= terministic Wallets. The public child key derivation does not seem to be ef= ficiently achievable. The hardened derivation is naturally possible for has= h-based schemes.

If we look at multi/distributed/threshold-sign= atures, we find that current approaches either don't give much gains compar= ed to plain usage of multiple signatures, or require a trusted dealer, whic= h drastically limits the use-cases.

We welcome community feedba= ck on this approach and hope to contribute to the broader discourse on ensu= ring Bitcoin's long-term security in the post-quantum era. In particular, w= e are interested in your thoughts on the following questions:
1) What = are the concrete performance requirements across various hardware, includin= g low-power devices?
2) Should multiple schemes with different signatu= re limits be standardized?
3) Is there value in supporting stateful sc= hemes alongside stateless ones?

Best regards,
Mikhail Kudin= ov and Jonas Nick
Blockstream Research

--
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/3e815d03-5e21-41ed-ba1a-4f9b2120a986n%40googlegroups.com.
------=_Part_175849_336877375.1765225735834-- ------=_Part_175848_1432732483.1765225735834--