A proposed post-quantum signature scheme called SHRINCS aims to shrink Bitcoin spending signatures by requiring wallets to track signing state. But the available SHRINCS material does not support the headline figure of 5, 777 bytes or define “Counter Loss.” Its fallback for lost state is also not a proven recovery guarantee.
- 5, 777 bytes: Not confirmed by the available SHRINCS figures.
- Core trade-off: Smaller signatures, more demanding wallet-state management.
- State loss: A larger stateless fallback is described, but its recovery process is unclear.
- Bitcoin status: The material describes proposal and implementation work, not an activated base-layer upgrade.
Why explore post-quantum signatures?
Bitcoin’s current signature systems use elliptic-curve cryptography. A sufficiently capable, fault-tolerant quantum computer could threaten widely used public-key cryptography. That risk is why researchers are exploring alternatives. It’s a reason to plan and test, not evidence that a quantum attack on Bitcoin is imminent. Coinbase’s post-quantum requirements offer another perspective on preparing for that risk.
Material published by PostQuantum.com describes SHRINCS as a hash-based, post-quantum signature proposal. Its main pitch is smaller signatures than some stateless post-quantum alternatives, including SLH-DSA, in exchange for a more complicated signing process. Blockstream’s work on stateful SHRINCS also addresses this trade-off.
Smaller signatures require careful state management
SHRINCS is stateful, meaning the signer must track which one-time keys it has already used. In practice, that means keeping an accurate record of the next available signing key or counter. Reusing a one-time key can undermine the scheme’s security.
PostQuantum.com says the design would keep signing state on a dedicated device rather than export it, and check candidate signatures for state reuse before broadcast. These safeguards address a real engineering problem, but they also put more responsibility on wallet software. A seed phrase alone may not restore the latest signing state if it has changed since the backup was made.
That’s the trade-off: smaller signatures could reduce transaction data, while state tracking adds complexity to wallet design, backups and recovery. Saving bytes only helps if the signing process stays safe and understandable.
The reported sizes describe different paths
PostQuantum.com gives several figures for different constructions or signing paths. They do not represent one standard size for every SHRINCS signature:
- 324 bytes: A conditional first signature from a fresh key in an earlier construction. The material does not describe this as a typical or universal size.
- Roughly 580 bytes: A proposed primary-device path in an opcode sketch.
- About 3, 000 bytes: A backup-device path associated with SHRIMPS, described as a later extension for multiple devices initialized from the same seed.
- About 4, 336-4, 496 bytes: A range reported for stateless alternatives, depending on the variant.
The available material does not establish whether these figures count the same thing, such as a signature alone or a complete transaction witness. That distinction matters. A Bitcoin transaction’s witness carries signature and other spending data, and its size contributes to transaction weight. A signature-size figure alone does not show the full transaction cost.
None of the reported SHRINCS figures is 5, 777 bytes. That does not prove the number is wrong. It means the available material does not verify it or explain what it measures. The phrase “Counter Loss” is also undefined in the SHRINCS material, so it should not be treated as established terminology or a confirmed feature.
State-loss recovery remains a key question
PostQuantum.com describes a larger stateless signature path as a fallback if a device is lost or restored without its latest state. That’s a proposed design behavior, not proof that every SHRINCS wallet can recover safely. The description also does not explain exactly how a user would switch paths after losing a device.
The material does not establish what keys or other data a user would still need, how the fallback would be triggered, or how the SHRIMPS multi-device design prevents one-time-key reuse across devices initialized from the same seed. These details matter. A recovery path inspires confidence only when its requirements are clear and the implementation has been tested.
Proposal work is not Bitcoin deployment
PostQuantum.com describes a draft specification, a C++ implementation, a Simplicity verifier and parameter scripts. It also says the specification is not final and the code needs thorough auditing. The material does not establish an activated Bitcoin base-layer upgrade or a production-ready Bitcoin wallet implementation. Bitcoin development updates provide broader context on proposed protocol work.
The distinction matters: prototype code, a draft, a sidechain experiment and a change to Bitcoin’s consensus rules are separate milestones. A base-layer deployment would require a soft fork. The status described in the available material should not be mistaken for a completed or approved Bitcoin upgrade.
Capacity estimates are models, not network results
PostQuantum.com reports modeled effective throughput of 0.60 to 3.04 transactions per second across four proposed variants. The estimates assume an average transaction shape and Bitcoin’s 4-million-weight-unit block limit. They are not observed network throughput. Bitcoin holdings disclosed in a SpaceX IPO filing are a separate reminder that Bitcoin’s real-world footprint extends beyond protocol capacity.
Actual capacity would depend on the signature path, transaction design and wallet behavior. The reported range is a model of possible costs, not a forecast of how many transactions Bitcoin would process after a post-quantum change. Without the underlying calculations and consistent assumptions for comparison, a single throughput figure can suggest more certainty than the evidence supports.
Key questions and answers
-
Does SHRINCS specify a 5, 777-byte signature?
The available SHRINCS material does not support that figure. It reports several sizes for different paths but does not explain or verify 5, 777 bytes.
-
Why does SHRINCS need signing state?
The signer tracks which one-time keys have already been used. Reusing one can undermine security, so the wallet must preserve and update that record reliably.
-
Does losing signing state mean losing funds?
Not necessarily. PostQuantum.com describes a proposed fallback that uses a larger stateless signature path. The available description does not explain the recovery steps or show that every wallet implements this fallback.
-
Is SHRINCS active on Bitcoin?
The material describes proposal and implementation work, not an activated Bitcoin base-layer upgrade. A base-layer deployment would require a soft fork.
SHRINCS targets a real challenge: post-quantum signatures can increase transaction data, while stateful designs may offer smaller alternatives at the cost of stricter wallet safeguards. Whether that trade-off makes sense depends on cryptographic review, clearly specified recovery and measured transaction costs, not an unverified byte count. The same caution applies amid broader market optimism: a Bitcoin rebound still needs more proof, and bullish calls on Bitcoin do not replace technical evidence.