From: Erik Aronesty <earonesty@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Hash-Based Signatures for Bitcoin's Post-Quantum Future
Date: Thu, 18 Dec 2025 10:45:23 -0800 (PST) [thread overview]
Message-ID: <60d61084-f1aa-4911-a615-77d8597645c0n@googlegroups.com> (raw)
In-Reply-To: <3e815d03-5e21-41ed-ba1a-4f9b2120a986n@googlegroups.com>
[-- Attachment #1.1: Type: text/plain, Size: 5271 bytes --]
hi, check this out. two simple new opcodes without requiring massive
hash-based signatures and gets you all the quantum resistance you need.
the trick is.. commit to a secret in one block, and reveal in a later
block. you use time-asymmetry to solve the information-asymmetry problem
without needing a full signature.
anchor-gated, template-bound spend using OP_CTV (BIP119) plus one new
opcode for on-chain anchor validation.
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
an op_return with specific value:
none of these are slow or expensive... and they are radically simpler than
quantum signature schemes, while still giving the spending limitations
needed for bitcoin
On Monday, December 8, 2025 at 12:47:49 PM UTC-8 Mikhail Kudinov wrote:
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/60d61084-f1aa-4911-a615-77d8597645c0n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 5953 bytes --]
next prev parent reply other threads:[~2025-12-19 1:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-08 20:28 [bitcoindev] " 'Mikhail Kudinov' via Bitcoin Development Mailing List
2025-12-08 21:50 ` Greg Maxwell
2025-12-09 5:08 ` 'conduition' via Bitcoin Development Mailing List
2025-12-10 0:41 ` Olaoluwa Osuntokun
2025-12-09 8:06 ` [bitcoindev] " Boris Nagaev
2025-12-09 22:48 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2025-12-09 23:06 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2025-12-10 0:01 ` 'Mikhail Kudinov' via Bitcoin Development Mailing List
2025-12-10 0:14 ` 'conduition' via Bitcoin Development Mailing List
2025-12-10 15:55 ` Jonas Nick
2025-12-10 0:53 ` Olaoluwa Osuntokun
2025-12-16 7:25 ` Jonas Nick
2026-01-19 1:12 ` 'conduition' via Bitcoin Development Mailing List
2025-12-18 18:45 ` Erik Aronesty [this message]
2025-12-19 8:36 ` Jonas Nick
2025-12-20 1:14 ` Erik Aronesty
2025-12-24 15:02 ` david torrealba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=60d61084-f1aa-4911-a615-77d8597645c0n@googlegroups.com \
--to=earonesty@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox