The SHRINCS proposal could give Bitcoin a path toward quantum-resistant transactions while limiting the impact on block capacity compared with other post-quantum signature systems.

Blockstream researchers unveiled SHRINCS on Thursday as a Bitcoin-focused signing mechanism designed to defend against future quantum attacks without causing a severe reduction in transaction throughput.

Bitcoin currently secures transaction authorization through elliptic-curve cryptography. Digital signatures allow users to prove they control the private key associated with their BTC without exposing the key itself.

That protection could eventually be challenged by sufficiently powerful quantum computers. Shor’s algorithm could allow such machines to solve the mathematical problems behind Bitcoin’s existing cryptography far more efficiently than conventional computers.

An attacker with that capability could potentially work from an exposed public key to recover its corresponding private key. They could then generate a valid signature and move the affected bitcoin.

This issue already concerns some BTC held at addresses where public keys have been revealed, either through older address designs or previous transactions. More than 1.1 million BTC associated with Bitcoin’s pseudonymous creator, Satoshi Nakamoto, has been cited among the potentially exposed holdings.

SHRINCS Seeks to Reduce the Cost of Quantum-Resistant Signatures

A major obstacle to post-quantum Bitcoin security is the size of the signatures. Cryptographic schemes standardized by the U.S. National Institute of Standards and Technology can produce signatures far larger than the compact signatures currently used by Bitcoin.

Since each Bitcoin block has finite space, larger signatures would leave less room for ordinary transactions.

According to Blockstream’s estimates, Bitcoin could handle about 6.5 transactions per second if transactions continued using Schnorr signatures. Switching entirely to NIST’s hash-based SLH-DSA could reduce that capacity to roughly 0.36 transactions per second.

SHRINCS is intended to bring throughput back to around three transactions per second. Its signatures start at approximately 324 bytes, compared with 64 bytes for Schnorr signatures, and increase by about 16 bytes with each additional key use. The proposed configuration reaches roughly three transactions per second with signatures of about 580 bytes.

Bitcoin’s SegWit upgrade helps offset some of this additional size by applying a lower block-space weight to signature data. Consequently, a signature that is several times larger does not necessarily consume several times as much effective block capacity.

The proposal also relies on SHA-256, which Bitcoin already uses extensively, including in its proof-of-work mining system. This allows SHRINCS to build on a familiar hashing primitive instead of introducing a completely new cryptographic assumption.

Blockstream researchers Jonas Nick and Mikhail Kudinov developed the system. Nick described SHRINCS as the first concrete post-quantum signature proposal specifically tailored to Bitcoin.

Still, the researchers acknowledge that SHRINCS is not necessarily intended to become Bitcoin’s permanent signature solution. Other designs could perform better depending on the criteria being evaluated.

The scheme also introduces wallet-management requirements. Each transaction uses a new one-time key, meaning wallets must maintain an accurate record of previously used keys and prevent any accidental reuse.

Keeping that information synchronized across phones, hardware wallets and backups could prove challenging. Restoring an outdated backup or losing the relevant key history could complicate future transactions.

The technology is still experimental. Its formal security proof has yet to be completed, and the reference implementation has not undergone a formal security audit. It is therefore not currently designed for production use.

Blockstream demonstrated SHRINCS transactions on Liquid in March. The separate network, operated by Blockstream, enables faster and more private transfers of bitcoin and other assets.

Deploying the system on Bitcoin would require a soft fork to modify the network’s rules while maintaining backward compatibility. The change would also need sufficient support across the Bitcoin ecosystem before it could be activated.

The proposal follows similar work on Ethereum, where researchers have been examining changes to the validator deposit process that could eventually allow the network to support additional cryptographic key types.