From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 18 Dec 2025 17:49:52 -0800 Received: from mail-qt1-f188.google.com ([209.85.160.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vWPcu-0008Ch-AX for bitcoindev@gnusha.org; Thu, 18 Dec 2025 17:49:52 -0800 Received: by mail-qt1-f188.google.com with SMTP id d75a77b69052e-4ee1b7293e7sf41167621cf.0 for ; Thu, 18 Dec 2025 17:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1766108986; x=1766713786; 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=nilXpmB9VqZOYXiq0hCa455QUJlBm/J4JRx92pqwxis=; b=kzgCxozAR92gWVbVPGLft++/48SEpN8LkoZ+RvCjLql68EX5TrnTqsmNRYrWacPb0Y PtJnA4qLfC3j7w/47xYAyoDz/K/R4wzvcJEjnnXXXUYRbFR9prOTanP/48ItFPwKmZgs lmbREv7SHNIV1jT2LzvD9+rXcn5QuQ3/0djH1607Rs8IuRQgMO0LxGLgnH1bZRNqFfZZ UmP0l0ycgcqNGNb94TnfywW6xuC5uoF1Ogg5tNg2RgSIfsNFqtednOZegn4SJ2/hWDkD 334hQwZfwe/jqzt9oq0idhMJrpboI8juqo0DijaT3MD8p83ZPYW+3HijDkNSFb2bTAEU 5nFA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766108986; x=1766713786; 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=nilXpmB9VqZOYXiq0hCa455QUJlBm/J4JRx92pqwxis=; b=E+uxouHwoY+k3GemgXBcZxgZmv93WR3ZiXfiMln6ZOE7iKAHrP4IyRSLswpTDz6KrC h/5cvNomqULaHqEVe2VLULFmKNhXTj0KXbjc8rhKWctA4oXORMwzUd0EGfNk2s9Gp2BL mYHYK43qPFwVy90fnvlZm2NFAByQMq966B0mtNQrqw8dhOwrpxjxBsq+leykiYhcaBUp eKWvIkeQRaIKM0R2i8vhPJuYGd1X5WXf36zN8e9sP3PFbaXUOCSL95+FooixVd/NcvdU hM/0TvrVl3xujSoyqcy4F92cptaLxKzd7q4v6BPlkvqZxKoE2vuoyBrNvI7WBLEGF1Wz gcHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766108986; x=1766713786; 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=nilXpmB9VqZOYXiq0hCa455QUJlBm/J4JRx92pqwxis=; b=lCOQUmGl2Ccd103nN6+L1DTApoufpQqYqPM7sB1hUfKws87Ij1kEVe/qM582SgXViK fzW7KJvgsSw7DDl/o/Me2gVDHi4yEMB1ObZ6kqD3rg37mgDWPva30mjM4n98rsxPuQ38 dzFCkb8b8lxO2k/SnTvz92xkrBZYpHDHVTedcuKqUUb3TldOH55zK1A9qnCsVCK3iEDt DUctsxA6iZKbnmp1U6tcq54TpEFJQIppO35KK4EEF3A+hU3NGEvgiyjCetrByVaHNhTA ch4+sRxXSoOCsxAFGIlH/WasuKt3t2EgXLL118t4XQ+qqsdvSxgRE1+zo9NeqGafikso WPUQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVFKEPwQ56Wgtl/UjxMs8zfXj8P+V6cps28cqsVyhbQgadffL902B++n53sUXmZip6lwpfKbjyIqdMo@gnusha.org X-Gm-Message-State: AOJu0YxBJJoQcZtMsFW+NwRLcIJNMmzlr37GHNTEurB1zIVV46IJRnlH 3PAvKCyuTN9MCDSu/YMpf+xYQ4+AErg14iDdqkNYETtbUOzqggVsVV3h X-Google-Smtp-Source: AGHT+IE7qvfZ9of8dpXm8vhuD5NI+o2Iy/ZHW79bkAXeDT0t6omE+jZa4hsl8KTDOTuGVZDGHkz70w== X-Received: by 2002:a05:622a:2c5:b0:4ef:db28:1f3b with SMTP id d75a77b69052e-4f4abcb8d0dmr22514021cf.16.1766108985729; Thu, 18 Dec 2025 17:49:45 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWa7Hc+NCGs+oWwFyQYjlwLbWKh020GMJzMAQW616br5uQ==" Received: by 2002:a05:622a:1654:b0:4ee:4220:d0b4 with SMTP id d75a77b69052e-4f1ced3ccbbls14629411cf.1.-pod-prod-02-us; Thu, 18 Dec 2025 17:49:37 -0800 (PST) X-Received: by 2002:a05:620a:470e:b0:8b2:f371:5601 with SMTP id af79cd13be357-8c08faaf09emr271039585a.50.1766108976834; Thu, 18 Dec 2025 17:49:36 -0800 (PST) Received: by 2002:a05:690c:7509:b0:78f:a59b:47c with SMTP id 00721157ae682-78fb3c3a601ms7b3; Thu, 18 Dec 2025 10:45:24 -0800 (PST) X-Received: by 2002:a05:690c:6388:b0:78c:64c1:c021 with SMTP id 00721157ae682-78fb400f955mr2448837b3.7.1766083523889; Thu, 18 Dec 2025 10:45:23 -0800 (PST) Date: Thu, 18 Dec 2025 10:45:23 -0800 (PST) From: Erik Aronesty To: Bitcoin Development Mailing List Message-Id: <60d61084-f1aa-4911-a615-77d8597645c0n@googlegroups.com> In-Reply-To: <3e815d03-5e21-41ed-ba1a-4f9b2120a986n@googlegroups.com> References: <3e815d03-5e21-41ed-ba1a-4f9b2120a986n@googlegroups.com> Subject: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2746_1872413402.1766083523349" X-Original-Sender: earonesty@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_2746_1872413402.1766083523349 Content-Type: multipart/alternative; boundary="----=_Part_2747_2117303172.1766083523349" ------=_Part_2747_2117303172.1766083523349 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable hi, check this out. two simple new opcodes without requiring massive=20 hash-based signatures and gets you all the quantum resistance you need. = =20 the trick is.. commit to a secret in one block, and reveal in a later=20 block. you use time-asymmetry to solve the information-asymmetry problem= =20 without needing a full signature. anchor-gated, template-bound spend using OP_CTV (BIP119) plus one new=20 opcode for on-chain anchor validation. =20 https://gist.github.com/earonesty/ea086aa995be1a860af093f93bd45bf2 two new opcodes needd: OP_CTV : commit to a spending template ( well tested already) OP_CHECKTXIDDEPTHVERIFY: check that a tx exists a given depth and contains= =20 an op_return with specific value: none of these are slow or expensive... and they are radically simpler than= =20 quantum signature schemes, while still giving the spending limitations=20 needed for bitcoin On Monday, December 8, 2025 at 12:47:49=E2=80=AFPM UTC-8 Mikhail Kudinov wr= ote: Hi everyone, We'd like to share our analysis of post-quantum options for Bitcoin,=20 focusing specifically on hash-based schemes. The Bitcoin community has=20 already discussed SPHINCS+ adoption in previous mailing list threads. We=20 also looked at this option. A detailed technical report exploring these=20 schemes, parameter selections, security analysis, and implementation=20 considerations is available at https://eprint.iacr.org/2025/2203.pdf. This= =20 report can also serve as a gentle introduction into hash-based schemes,=20 covering the recent optimization techniques. The scripts that support this= =20 report are available at=20 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= =20 several reasons. They rely solely on the security of hash functions=20 (Bitcoin already depends on the collision resistance of SHA-256) and are=20 conceptually simple. Moreover, these schemes have undergone extensive=20 cryptanalysis during the NIST post-quantum standardization process, adding= =20 confidence in their robustness. One of the biggest drawbacks is the signature sizes. Standard SPHINCS+=20 signatures are almost 8KB. An important observation is that SPHINCS+ is=20 designed to support up to 2^64 signatures. We argue that this bound can be= =20 set lower for Bitcoin use-cases. Moreover, there are several different=20 optimizations (like WOTS+C, FORS+C, PORS+FP) to the standard SPHINCS+=20 scheme, that can reduce the signature size even more.=20 For example, with these optimizations and a bound on 2^40 signatures we can= =20 get signatures of size 4036 bytes. For 2^30 signatures, we can achieve 3440= =20 bytes, and for 2^20, one can get 3128 bytes, while keeping the signing time= =20 reasonable.=20 We should not forget that for Bitcoin, it is important that the size of the= =20 public key plus the size of the signature remains small. Hash-based schemes= =20 have one of the smallest sizes of public keys, which can be around 256=20 bits. For comparison, ML-DSA pk+sig size is at least 3732 bytes. Verification cost per byte is comparable to current Schnorr signatures,=20 alleviating concerns about blockchain validation overhead.=20 As for security targets, we argue that NIST Level 1 (128-bit security)=20 provides sufficient protection. Quantum attacks require not just O(2^64)=20 operations but approximately 2^78 Toffoli depth operations in practice,=20 with limited parallelization benefits. One of the key design decisions for Bitcoin is whether to rely exclusively= =20 on stateless schemes (where the secret key need not be updated for each=20 signature) or whether stateful schemes could be viable. Stateful schemes=20 introduce operational complexity in key management but can offer better=20 performance. We explored the possibilities of using hash-based schemes with Hierarchical= =20 Deterministic Wallets. The public child key derivation does not seem to be= =20 efficiently achievable. The hardened derivation is naturally possible for= =20 hash-based schemes.=20 If we look at multi/distributed/threshold-signatures, we find that current= =20 approaches either don't give much gains compared to plain usage of multiple= =20 signatures, or require a trusted dealer, which drastically limits the=20 use-cases.=20 We welcome community feedback on this approach and hope to contribute to=20 the broader discourse on ensuring Bitcoin's long-term security in the=20 post-quantum era. In particular, we are interested in your thoughts on the= =20 following questions: 1) What are the concrete performance requirements across various hardware,= =20 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 --=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/= 60d61084-f1aa-4911-a615-77d8597645c0n%40googlegroups.com. ------=_Part_2747_2117303172.1766083523349 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable hi, check this out.=C2=A0 two simple new opcodes without requiring massive = hash-based signatures and gets you all the quantum resistance you need.=C2= =A0 =C2=A0

the trick is.. commit to a secret in one block, and r= eveal in a later block.=C2=A0 you use time-asymmetry to solve the informati= on-asymmetry problem without needing a full signature.

anchor-ga= ted, template-bound spend using OP_CTV (BIP119) plus one new opcode for on-= chain anchor validation.=C2=A0=C2=A0

https://gist.github.com/ear= onesty/ea086aa995be1a860af093f93bd45bf2

two new opcodes needd:
OP_CTV : commit to a spending template ( well tested already)
OP_CHECKTXIDDEPTHVERIFY: check that a tx exists a given depth and contain= s an op_return with specific value:

none of these are slow or ex= pensive... and they are radically simpler than quantum signature schemes, w= hile still giving the spending limitations needed for bitcoin

On Monday, December 8, 2025 at 12:47:49=E2=80=AFPM UTC= -8 Mikhail Kudinov wrote:
Hi= everyone,

We'd like to share our analysis of post-quantum optio= ns for Bitcoin, focusing specifically on hash-based schemes. The Bitcoin co= mmunity has already discussed SPHINCS+ adoption in previous mailing list th= reads. 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-bas= ed schemes, covering the recent optimization techniques. The scripts that s= upport this report are available at https://g= ithub.com/BlockstreamResearch/SPHINCS-Parameters .
Below, we give = a quick summary of our findings.

We find hash-based signatures t= o be a compelling post-quantum solution for several reasons. They rely sole= ly on the security of hash functions (Bitcoin already depends on the collis= ion resistance of SHA-256) and are conceptually simple. Moreover, these sch= emes have undergone extensive cryptanalysis during the NIST post-quantum st= andardization process, adding confidence in their robustness.

On= e of the biggest drawbacks is the signature sizes. Standard SPHINCS+ signat= ures 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 r= educe the signature size even more.
For example, with these optimizat= ions and a bound on 2^40 signatures we can get signatures of size 4036 byte= s. For 2^30 signatures, we can achieve 3440 bytes, and for 2^20, one can ge= t 3128 bytes, while keeping the signing time reasonable.

We sho= uld not forget that for Bitcoin, it is important that the size of the publi= c 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. Fo= r comparison, ML-DSA pk+sig size is at least 3732 bytes.

Verific= ation cost per byte is comparable to current Schnorr signatures, alleviatin= g concerns about blockchain validation overhead.

As for securit= y targets, we argue that NIST Level 1 (128-bit security) provides sufficien= t protection. Quantum attacks require not just O(2^64) operations but appro= ximately 2^78 Toffoli depth operations in practice, with limited paralleliz= ation benefits.

One of the key design decisions for Bitcoin is w= hether to rely exclusively on stateless schemes (where the secret key need = not be updated for each signature) or whether stateful schemes could be via= ble. Stateful schemes introduce operational complexity in key management bu= t can offer better performance.

We explored the possibilities of= using hash-based schemes with Hierarchical Deterministic Wallets. The publ= ic child key derivation does not seem to be efficiently achievable. The har= dened 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 secu= rity in the post-quantum era. In particular, we are interested in your thou= ghts 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 one= s?

Best regards,
Mikhail Kudinov and Jonas Nick
Blocks= tream 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/60d61084-f1aa-4911-a615-77d8597645c0n%40googlegroups.com.
------=_Part_2747_2117303172.1766083523349-- ------=_Part_2746_1872413402.1766083523349--