A group of Bitcoin developers and cryptographers published a draft specification for SHRINCS, an experimental signature scheme designed to remain secure against attacks from quantum computers.

The document turns an earlier research concept into defined key-generation, signing, and verification algorithms supported by a reference implementation.

It has not received an official Bitcoin Improvement Proposal number, and its authors warn that it is not ready for production.

SHRINCS, short for “Shrunken SPHINCS,” is based on SHA-256, a hash function already central to Bitcoin. 

According to the draft specification, its parameters target approximately 128 bits of classical security and 64 bits of post-quantum security. A complete security proof remains under development.

The proposal combines two signing methods under a 48-byte public key. Its primary stateful method produces signatures ranging from 548 to 4,619 bytes. A stateless fallback produces a larger 5,777-byte signature.

The stateful method is intended to reduce the amount of block space required by hash-based signatures. 

Wallet developers could choose between tree structures optimized for a small number of compact signatures or for more frequent key reuse. 

The stateless method could be used when a wallet is restored from a seed or its signing state is lost or uncertain.

State management represents the proposal’s main security risk. Wallet software must keep an accurate counter and ensure that each one-time signing key is never reused. 

Signing two different messages with the same state could allow someone who sees both signatures to forge another one.

That requirement could complicate backups, wallet recovery, concurrent signing, and the use of the same wallet on multiple devices. 

A wallet unable to confirm its current state would need to abandon the compact signing path and use the larger stateless fallback.

The developers report that SHRINCS signatures require fewer verification operations per byte than Bitcoin’s current BIP-340 Schnorr signatures. 

Those figures are based on the project’s own benchmarks and have not yet been broadly tested. 

SHRINCS signatures would also remain substantially larger overall than the 64-byte Schnorr signatures used in Taproot transactions.

The scheme lacks some features supported by Schnorr cryptography, including direct equivalents of BIP32 extended public keys and compact MuSig-style multisignatures. 

Key generation and signing can also be computationally expensive, although the authors say parallel processing, hardware acceleration, and caching could improve performance.

The draft covers only the cryptography. Separate proposals would be needed to define how SHRINCS works with Bitcoin Script, introduce a compatible output type, and establish consensus validation rules. 

Any proposed activation would then require further review and agreement among Bitcoin network participants.

Outstanding work includes test vectors, unit tests, optimized implementations, wallet design, and a security proof covering the complete scheme. 

A related prototype, libshrincs, contains machine-checked work for one SHRINCS component but does not yet establish a complete post-quantum security bound for the full proposal.

“SHRINCS is not intended to be Bitcoin's ‘final’ signature scheme, and it is not optimal along every axis,” Blockstream researcher Jonas Nick said. 

“I do think it is a very good trade-off among the options we have now.”