SHRINCS, and why a post-quantum key would have to count its signatures

Updated September 2026

SHRINCS, short for "Shrunken SPHINCS", is a post-quantum signature scheme built only from SHA256. The draft specifies a 48-byte public key and signatures from 548 bytes, far smaller than the standardized hash-based option, in exchange for one new rule for self-custody: the wallet has to keep count of how many times each key has signed, and that count can never be restored from a backup.

What was published, and by whom

The Bitcoin Optech newsletter of September 4, 2026 reported that conduition had posted a first draft BIP for SHRINCS on behalf of a working group. The draft itself lists six authors, conduition, Ethan Heilman, Mikhail Kudinov, Oleksandr Kurbatov, Jonas Nick and remix7531, with the status "Draft" and no BIP number assigned. The idea was first discussed on Delving Bitcoin in December 2025.

Two limits matter before anything else. The draft says plainly that "a security proof is TODO." And it specifies a signature scheme, not a change to Bitcoin: key generation, signing and verification. It does not define an opcode, an address type or a soft fork. Wiring a scheme like this into Bitcoin would be a separate proposal, with its own review and its own activation debate.

Optech's summary confirms the scope: "The draft specifies only a signature scheme; deployment of the new signatures per new opcodes or a new output type would be subject of a separate proposal." The same issue notes that Jonas Nick and remix7531 separately released libshrincs, a C library with machine-checked proofs for the one-time signature part.

Why a hash-based signature at all

Bitcoin signatures today rest on the secp256k1 curve. A large enough quantum computer running Shor's algorithm could recover a private key from a published public key. That is why this site cares whether the key is still in the box.

Replacing the curve means picking new math. The post-quantum standards NIST published in 2024 include lattice-based ML-DSA and hash-based SLH-DSA. SHRINCS takes the hash-based road. Its motivation section explains why: it "relies solely on the security of its underlying hash function," and that function is SHA256, "which is already fundamental to Bitcoin's security." Lattice schemes add a separate assumption about hard lattice problems. The draft adds that "Bitcoin outputs may remain unspent for long periods, making conservative cryptographic assumptions particularly valuable."

The catch with hash-based signatures has always been size. That is the problem SHRINCS is built to shrink.

How big are the signatures?

The draft gives these sizes. For comparison, a Schnorr signature of the kind Taproot uses today is 64 bytes, with a 32-byte public key.

By the draft's own figures, the smallest combined public key and stateful signature is about 13 times smaller than SLH-DSA-SHA2-128s, the compact standardized hash-based option, and about 6 times smaller than the lattice scheme ML-DSA-44. It targets NIST security category 1, which the draft describes as 128 bits of classical and 64 bits of quantum security, chosen to match the classical level of today's Schnorr signatures.

Even the small path is several hundred bytes, and the fallback is several kilobytes. Optech reports that Antoine Riard put the 5,777-byte stateless signatures at roughly 90 times the on-chain cost of today's transactions, unless those bytes are discounted. How block space would be priced for signatures like these is one of the open questions around every post-quantum proposal, and this site covers the address side of it in what a later, harder lock might look like.

Why the small signatures need a counter

The compact path is built from one-time signatures. A one-time signature key can safely sign exactly one message. Sign two different messages with it and you leak enough for someone else to forge a third. To get a key that signs more than once, the scheme builds many one-time keys, hashes them into a Merkle tree, and publishes the root as the public key. Each signature uses one leaf and includes the path from that leaf up to the root. The draft calls its version FXMSS, a flexible variant of the XMSS design.

Think of it as a stack of cards. Each card can seal one envelope. The public key is a fingerprint of the whole stack. The only thing that keeps you from using a card twice is a counter that says which card is next, and the draft is strict about it: the counter "increments once for every stateful FXMSS signature created, and must never decrement." Reusing a counter value, it warns, "can enable anyone who observes the resulting signatures to produce forgeries."

Anyone who has worked with today's wallets will see the problem straight away. Current Bitcoin keys have no memory. A seed phrase written on paper in 2017 restores exactly the same signing ability today. A stateful key has a history, and the history matters.

What it means for your seed backup

This is where the draft touches self-custody directly. Its section on managing state lists practices that must be avoided, and the first one is the one every backup habit runs into:

• "State counters must not be backed up and restored by any mechanism."
• They must not live in unprotected storage such as a shared folder.
• They must not be exported and imported into other software.
• Implementations must not allow concurrent signing.
• The signer must save the new counter value before handing back a signature.

The reason is easy to see once you picture a restore. You back up a wallet at counter 10, sign five more transactions, lose the device and restore the backup. The restored wallet thinks card 11 is next, but cards 11 to 15 are already on the chain. The next signature would reuse a card, and anyone watching could forge.

So SHRINCS keeps a second, larger way to sign. The stateless path is SLH-DSA, the NIST-standardized form of SPHINCS+, with a non-standard parameter set. It needs no counter. The draft makes it the mandatory escape route: if correct state is not available for any reason, "such as when restoring from a static backup," an implementation "MUST refuse to sign with the stateful path" and sign only through the stateless one. Either kind of signature is valid against the same public key.

In practice that means seed words would still work. A wallet restored from a seed could still spend. It would just pay for 5,777-byte signatures instead of a few hundred bytes, for as long as that key is in use. Moving the coins to a fresh key would restart the counter cleanly. None of this exists in any wallet today, but it is the first post-quantum draft in Bitcoin that puts a price on "restore from backup."

Few signatures or many: two tree shapes

The draft lets the signer choose the shape of the tree, and the choice follows how the key will be used.

• Unbalanced trees make the first few signatures very small, with each later one a little larger. The draft lists personal wallets and cooperative signing as the use cases. Key generation is fast.
• Balanced trees give every signature the same, larger size and support far more of them. The draft lists address reuse, layer 2 protocols and persistent identity. Key generation is slow, because every leaf must be built before the public key exists.

The numbers show the trade. The draft works through an optimistic example: a fast GPU spending one minute on key generation would produce about 115 million one-time keys. That is "far more signatures than would ever be needed" for a consumer wallet. A busy Lightning channel signing five commitments a second, though, would run through them in about 266 days, and would then fall back to the stateless path, whose budget of 2⁴⁰ signatures the draft says could run a 1,000-transaction-per-second channel for over 30 years.

For a cold-storage holder the lesson is the same one this site gives about address reuse. A key used a handful of times is the easy case. Keys used over and over are where every design gets expensive.

What about hardware wallets?

Hash-based signing is heavy work for a small chip. The draft counts it in SHA256 compressions. A stateful signature from an unbalanced tree of depth 255 averages about 133,000 of them, and much of that can be done up front at key generation. A stateless signature averages about 1.7 million.

For low-power devices the draft describes a trade called hypertree pruning, which lowers the stateless signature budget from 2⁴⁰ to a smaller bound in exchange for much faster signing and key generation. It then adds a warning worth reading twice: keys generated this way "are not compatible with SHRINCS implementations which do not support hypertree pruning," and importing such a key into incompatible software "may result in lost funds."

That is a new kind of problem for anyone who moves a seed between wallets from different makers. Today the device only holds the key, as we explain in the device is not the box. In a stateful, pruned world the device would also hold a counter and a set of parameters that other software has to respect.

Where it would fit, and what it would close

BIP-360 proposes P2MR, an output type with no key path, so no public key sits on the chain at rest. BIP-360 itself says P2MR "does not, by itself, protect against short exposure quantum attacks," because today every script leaf is still satisfied with a secp256k1 signature and key, published in the mempool at spend time.

A scheme like SHRINCS is the missing piece. A leaf that checks a hash-based signature publishes no elliptic-curve key at all. That is the only way an output could ever reach the NOT_EXPOSED level in the new exposure classification draft, a level the draft says no deployed output type reaches today.

The route there is not decided. The same Optech issue records an ongoing debate on Delving Bitcoin about which post-quantum output type Bitcoin should add. Optech summarized Pieter Wuille as still preferring "P2TRv2 as a default for casual users and P2MR for more sophisticated users who want to hide EC points," and noted his view that hash-based signatures after a quantum breakthrough would likely need a new witness costing rule that "weighs CPU more and serialized size less." None of this has a timeline.

What to do now

Nothing, in any urgent sense. SHRINCS is a draft signature scheme without a finished security proof, with no BIP number, and with no opcode or address type that uses it. No quantum computer that exists can derive a key from a published secp256k1 public key.

A few habits carry over well to whatever comes next:

• Keep the box closed where you can. A never-spent 1, 3 or bc1q address keeps its key off the chain. Check an address if you are not sure.
• Spend from each address once, then move on. That is the pattern stateful schemes reward too.
• Be wary of any wallet sold today as "quantum-safe". The signature schemes a Bitcoin wallet could use for that are still drafts, and the network does not enforce any of them.
• Keep your seed backup as it is. If a stateful scheme ever reaches Bitcoin, expect wallets to explain which part of your wallet can be restored and which part cannot.