<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:base="https://nickler.ninja/">
  <title>Category: post-quantum | nickler&#39;s</title>
  <link href="https://nickler.ninja/categories/post-quantum/atom.xml" rel="self"/>
  <link href="https://nickler.ninja/"/>
  <updated>2026-08-26T22:26:00+00:00</updated>
  <id>https://jonasnick.github.io/</id>
  <author>
    <name>Jonas Nick</name>
  </author>
  <generator uri="https://www.getzola.org/">Zola</generator>
  <entry>
    <title type="html">BIP SHRINCS</title>
    <link href="https://nickler.ninja/blog/2026/08/26/bip-shrincs/"/>
    <updated>2026-08-26T22:26:00+00:00</updated>
    <id>https://jonasnick.github.io/blog/2026/08/26/bip-shrincs</id>
    <content type="html">&lt;p&gt;We published &lt;a rel=&quot;external&quot; href=&quot;https://github.com/SHRINCS/shrincs-bip/blob/main/SHRINCS.md&quot;&gt;BIP SHRINCS&lt;/a&gt;, the first concrete proposal for a post-quantum signature scheme designed specifically for Bitcoin.
The draft BIP turns what began as a rough idea into exact algorithms with an executable reference implementation.
The discussion can now focus on analyzing, criticizing, and improving a concrete proposal.&lt;/p&gt;
&lt;p&gt;The BIP makes choices ranging from major design questions, such as whether to support flexible XMSS and how to balance signature size against verification time, to the many smaller decisions involved in saving a byte here or there.
All of these choices are up for debate.&lt;/p&gt;
&lt;p&gt;A lot more work lies ahead:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;The draft BIP specifies only the cryptography.
Using SHRINCS in Bitcoin Script will require a separate BIP.&lt;/li&gt;
&lt;li&gt;We are working on a security proof for the exact construction and parameters.&lt;/li&gt;
&lt;li&gt;Wallet integration and user experience, for example around backups and recovery after state loss, are still at an early stage.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;SHRINCS is not intended to be Bitcoin’s “final” signature scheme, and it is not optimal along every axis.
I do think it is a very good trade-off among the options we have now.&lt;/p&gt;
&lt;p&gt;Thanks to Mike Casey, conduition, Ethan Heilman, Mikhail Kudinov, Oleksandr Kurbatov, Boris Nagaev, and remix7531 for their contributions.
The announcement is on the &lt;a rel=&quot;external&quot; href=&quot;https://groups.google.com/g/bitcoindev/c/HbVboXIFiG8&quot;&gt;bitcoin-dev mailing list&lt;/a&gt;.&lt;/p&gt;
&lt;h2 id=&quot;background&quot;&gt;Background&lt;/h2&gt;
&lt;p&gt;SHRINCS combines a stateful and a stateless hash-based signature scheme.
The signer primarily uses the stateful scheme and falls back to the stateless scheme when the signing state is unavailable, for example after seed recovery.
In the current version of the draft BIP, stateful signatures are 548 to 4,619 bytes, depending on the shape of the signer’s tree and how often the key has signed, and stateless signatures are 5,777 bytes.
These numbers may still change.&lt;/p&gt;
&lt;p&gt;The stateful scheme is limited to a single device.
&lt;a rel=&quot;external&quot; href=&quot;https://delvingbitcoin.org/t/shrimps-2-5-kb-post-quantum-signatures-across-multiple-stateful-devices/2355&quot;&gt;SHRIMPS&lt;/a&gt; addresses multiple devices: assuming an upper bound on the number of devices initialized from the same seed (e.g., 1024), any of them creates signatures of about 2.5 KB, three times smaller than SLH-DSA.
Combined, the primary device signs with SHRINCS and backup devices with SHRIMPS, all from the same static seed backup.&lt;/p&gt;
&lt;p&gt;At OP_NEXT 2026, I presented a toy proposal for hash-based signatures in Bitcoin that includes SHRINCS (&lt;a rel=&quot;external&quot; href=&quot;https://www.youtube.com/watch?v=ed1K_1mp9mU&quot;&gt;video&lt;/a&gt;, &lt;a href=&quot;/slides/2026-opnext.pdf&quot;&gt;slides&lt;/a&gt;).
remix7531 and I also published &lt;a rel=&quot;external&quot; href=&quot;https://delvingbitcoin.org/t/libshrincs-a-c-implementation-with-a-machine-checked-security-proof/2795&quot;&gt;libshrincs&lt;/a&gt;, a proof-of-concept C implementation of WOTS+C, the one-time signature used by SHRINCS.
Its machine-checked proofs connect the C implementation to an unforgeability theorem, which does not yet give a full post-quantum security bound.&lt;/p&gt;
</content>
  </entry>
  <entry>
    <title type="html">Hash-Based Signatures for Bitcoin</title>
    <link href="https://nickler.ninja/blog/2025/12/09/hash-based-signatures-for-bitcoin/"/>
    <updated>2025-12-09T14:59:00+00:00</updated>
    <id>https://jonasnick.github.io/blog/2025/12/09/hash-based-signatures-for-bitcoin</id>
    <content type="html">&lt;p&gt;Mikhail Kudinov and I at Blockstream Research published &lt;a rel=&quot;external&quot; href=&quot;https://eprint.iacr.org/2025/2203.pdf&quot;&gt;Hash-based Signatures for Bitcoin&lt;/a&gt;, an analysis of post-quantum signature schemes.
The paper is a gentle introduction to hash-based schemes and explores how to optimize them for Bitcoin.&lt;/p&gt;
&lt;p&gt;Hash-based signatures are conceptually simple and rely solely on hash functions, a primitive Bitcoin already trusts.
NIST has standardized SLH-DSA (SPHINCS+), but the paper investigates alternatives that are better suited to Bitcoin’s needs.
It explores in detail how optimizations and parameter choices affect size and performance.
Signatures can be reduced to about 3–4 KB, which is comparable to the lattice-based ML-DSA.&lt;/p&gt;
&lt;p&gt;The paper also discusses:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;trade-offs between stateless and stateful schemes,&lt;/li&gt;
&lt;li&gt;compatibility with HD wallets,&lt;/li&gt;
&lt;li&gt;limitations of current approaches for multi- and threshold signatures,&lt;/li&gt;
&lt;li&gt;security targets.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;We welcome feedback, particularly on hardware performance requirements and standardization choices.
The scripts that generate the parameter analysis are on &lt;a rel=&quot;external&quot; href=&quot;https://github.com/BlockstreamResearch/SPHINCS-Parameters&quot;&gt;GitHub&lt;/a&gt;.&lt;/p&gt;
</content>
  </entry>
</feed>
