Mentioned in This Article
1. Quantum computing and Bitcoin wallets: the trade-off Trezor faces
Hardware wallet maker Trezor is weighing how to support SHRINCS, the post-quantum signature scheme that has emerged as the Bitcoin community's leading candidate, and its chief technology officer, Tomáš Sušánka, said in comments published on November 12 that the design pushes difficult trade-offs onto wallet developers. The core tension in quantum computing and Bitcoin security, he explained, is between signatures that are compact and signatures that are safe to reuse.
Trezor builds offline signing devices whose job is to keep private keys isolated from internet-connected computers. That mission does not change in a world with capable quantum computers, but the tools needed to fulfil it do. According to Sušánka, preparing for that era involves more than waiting for Bitcoin's protocol to adopt new cryptography. It also requires rethinking how wallets track their own usage, how devices authenticate their firmware, and how quickly millions of people can be moved onto safer setups.
His comments offer a rare look at the engineering questions that sit behind the broader debate over quantum resistance. Much of that debate concerns which signature scheme Bitcoin should eventually adopt. Sušánka's perspective is that of a builder who will have to ship whatever the network chooses, and who will be responsible if users lose funds because a design leaves room for error.
2. What is SHRINCS?
SHRINCS is a proposed post-quantum signature scheme for Bitcoin that combines two kinds of hash-based signatures, letting users choose between a stateful mode and a stateless mode. It was put forward late last year by Jonas Nick, research director at Blockstream Research, and cryptographer Mikhail Kudinov.
The scheme belongs to the family of hash-based signatures, which derive their security from the properties of cryptographic hash functions rather than from mathematical problems such as the elliptic curve discrete logarithm. That distinction matters because the elliptic curve signatures Bitcoin uses today, both ECDSA and Schnorr, are the kind of cryptography a sufficiently powerful quantum computer running Shor's algorithm is expected to break. Hash functions are not known to be vulnerable in the same way, which is why hash-based schemes are widely regarded as a cautious option.
SHRINCS uses what its designers describe as a composite construction. Rather than forcing a single approach on every user, it packages two signing methods together. One is stateful, meaning the signer must keep a reliable record of which one-time keys have already been consumed. The other is stateless, meaning no such record is required. Each has strengths that the other lacks, and that is precisely where the difficulty for wallet makers begins.
Sušánka describes SHRINCS as the conservative choice among the available options. In his view, its main appeal is that it rests on the same security assumptions as SHA-256, the hash function that already underpins Bitcoin's proof-of-work mining and much of its wider design. If SHA-256 were to fail, Bitcoin would face far larger problems than signature security, so tying signatures to the same foundation adds little new risk.
3. Small signatures versus safe signatures
The two halves of SHRINCS sit at opposite ends of a familiar engineering spectrum. Stateless signatures can be reused safely, but they are large. Bigger signatures take up more space in a block, which translates into higher transaction fees and slower processing. Stateful signatures are far more compact and efficient, but they are only safe as long as each one-time key is used exactly once and the overall signing budget is respected.
Sušánka put the size difference at roughly ten to one in favour of stateful signatures. On a network where every byte of block space carries a cost, that gap is meaningful. It affects what users pay to move their coins and how many transactions can fit into each block. For that reason, he said he does not want to dismiss stateful signatures altogether, even though they introduce risks he takes seriously.
He framed the decision as a matter of balancing competing priorities rather than finding a perfect answer. A scheme that is maximally safe but expensive to use may push people toward shortcuts. A scheme that is cheap but unforgiving may expose ordinary users to catastrophic mistakes. The goal is to find a default that protects most people while leaving room for those who understand the risks to optimise.
4. How can a reused key lead to stolen funds?
A reused key in the stateful mode can leak enough information for an attacker to forge valid signatures and drain the wallet. The stateful component of SHRINCS is built as a tree of one-time signatures, and each leaf in that tree is meant to authorise a single transaction.
One-time signature schemes work by revealing part of a secret each time a message is signed. Revealing that information once is safe by design. Revealing it twice, for two different messages, can give an observer enough material to construct signatures the owner never approved. In a Bitcoin context, that means an attacker watching the blockchain could potentially take coins from an address whose key had been used beyond its intended limit.
This is why the stateful mode demands strict bookkeeping. The wallet must always know which leaves of the tree have been spent and must never return to one of them. Under normal conditions, a single device can track that information without much trouble. The danger lies in the many situations where conditions are not normal.
Sušánka warned that if Bitcoin adopts SHRINCS, developers will need to be meticulous about state management, and that there are numerous edge cases where a lapse could open a security hole. Each of those edge cases represents a path by which a user who did nothing obviously wrong could end up exposed.
5. The shared seed problem
One scenario Sušánka raised illustrates how quickly state tracking becomes complicated. Many Bitcoin holders keep more than one hardware wallet restored from the same recovery seed, often as a backup or for convenience in different locations. Under today's cryptography, that practice is harmless. Both devices derive the same keys, and using either one to sign carries no special risk.
With stateful post-quantum signatures, the picture changes. If two devices hold the same seed, each needs to know which one-time keys the other has already used. Otherwise, both could sign with the same leaf of the signature tree, recreating exactly the reuse that the scheme forbids. Sušánka asked how state could be shared between two such devices and concluded that, in practice, it cannot.
Offline hardware wallets are deliberately isolated. They do not sync with each other over the internet, and building such a channel would undermine the very separation that makes them secure. The shared seed example therefore points to a broader challenge. Practices that users have relied on for years may need to change, or wallets will need safeguards that prevent dangerous combinations from arising in the first place.
6. Trezor's approach: stateless by default
Sušánka's guiding principle is that responsibility for safety should rest with developers, not users. He said a design that gives people the opportunity to make mistakes places a burden on the engineers building wallets, and that it is their job to make the system secure rather than expecting users to understand the cryptography.
To that end, Trezor is considering making stateless signatures the default for everyone. Those signatures are larger and slower, but they remove the risk of catastrophic key reuse. Stateful signatures would remain available, tucked away in advanced settings for users who understand the trade-off and want the efficiency gains.
The approach reflects a common pattern in security engineering, in which the safest option is the one people get without making any choices, and riskier optimisations require deliberate action. It also acknowledges that the majority of hardware wallet owners are unlikely to track the internal state of a signature tree, nor should they need to.
Sušánka said he remains torn on the question. The efficiency of stateful signatures is a real benefit, and the burden of maintaining state is a real cost. Making stateless the default is a way of managing that tension rather than resolving it.
7. The hardware itself needs an upgrade
Quantum resistance for hardware wallets does not depend only on Bitcoin's signature scheme. Sušánka noted that most signing devices still rely on quantum-vulnerable cryptography for tasks such as verifying firmware updates and authenticating that a device is genuine. Those functions protect users against tampered hardware and malicious software, and they too would be exposed to a capable quantum attacker.
For a device to be considered quantum-ready, he said, it needs post-quantum cryptography in those internal processes as well. Trezor already sells the Trezor Safe 7, which supports post-quantum wallet authentication. That puts part of the hardware stack ahead of the protocol it serves.
Even so, Sušánka was clear that transactions will only become quantum-secure once Bitcoin itself upgrades. A wallet can authenticate its firmware with post-quantum methods, but it still has to sign transactions using whatever schemes the network accepts. Until the protocol supports a post-quantum signature type, coins remain protected by elliptic curve cryptography regardless of the device holding them.
8. Why migration timing matters
A recurring theme in Sušánka's remarks was urgency around migration. He cautioned developers against delaying the moment when users are given options to move to quantum-resistant setups, arguing that shifting potentially millions of people will take considerable time.
Migration in Bitcoin is not automatic. Even after a new signature type becomes available, each holder must actively move funds to addresses that use it. That requires updated wallet software, updated hardware, clear guidance and, in many cases, transaction fees. Large numbers of users rarely act quickly, and some coins belong to people who may not act at all. The earlier tools are available, the longer the runway for an orderly transition.
Sušánka also argued that the community will have to accept compromises. In his view, insisting on perfection about what should or should not be permitted risks stalling progress entirely. A workable scheme with known trade-offs, deployed in time, may serve users better than an ideal design that arrives too late.
9. What comes next for quantum-resistant Bitcoin wallets
SHRINCS remains a proposal, and Bitcoin has not committed to any post-quantum signature scheme. Any change of that kind would need broad agreement among developers, node operators and users before it could be activated. Until then, wallet makers like Trezor are preparing in the areas they control: hardware authentication, default settings and the user experience of eventual migration.
Sušánka's comments suggest the hardest problems may not be purely cryptographic. Choosing a secure algorithm is only the first step. Designing products that prevent ordinary people from misusing it, handling backups and duplicate devices, and moving a large user base in time are challenges that fall largely on the companies building wallets. For Trezor, the working answer is to keep the safest option as the default, keep the efficient option within reach, and start giving users choices sooner rather than later.