Why Bitcoin Wallet Makers Face a Difficult Road to Quantum-Resistant Security

Table of Contents

• You might want to know


• Main Topic


• Key Insights Table


• Afterwards...

You might want to know

• Why could a smaller, more efficient post-quantum signature create new risks for Bitcoin users?


• Why might quantum-resistant Bitcoin require changes to hardware wallets as well as to the Bitcoin network?

Main Topic

Bitcoin custody has always required users and developers to manage security risks. Hardware wallets such as Trezor are designed to keep private keys offline, but the prospect of quantum computing introduces challenges that extend beyond protecting those keys. Wallet makers are considering how users will create transactions, how devices will authenticate their software, and how to make complicated security rules manageable in everyday use.

A leading candidate for post-quantum Bitcoin signatures is SHRINCS, a scheme proposed late last year by Blockstream Research Director Jonas Nick and cryptographer Mikhail Kudinov. It uses a composite, hash-based approach and can support two kinds of signatures: stateful and stateless. Each offers a different balance between size, efficiency, and the effort required to protect funds.

Stateless signatures can be reused safely, making them easier to manage from the perspective of tracking which signing keys have already been used. Their main drawback is size. Larger signatures may affect transaction fees, signing speed, and other efficiency measures. Stateful signatures, by contrast, are smaller and more efficient, but they require strict tracking of the wallet’s signing state.

The stateful part of SHRINCS relies on a tree of one-time signatures. These keys are intended for limited use. If a key is used more than once, cryptographic information can be exposed that could allow another party to forge the user’s signature and potentially take funds. The danger is not simply that the technology is unfamiliar; it is that a mistake in state tracking can have direct security consequences.

That requirement would make wallet software responsible for carefully recording how much of a signing budget has been used and preventing accidental reuse. Developers would also need to account for less common situations, such as restoring a wallet, moving between devices, or using multiple devices associated with the same recovery seed. Any gap between the recorded state and the actual signing history could create a vulnerability.

Trezor Chief Technology Officer Tomáš Sušánka has described this as a user-experience problem as much as a cryptographic one. If users are given a feature whose safe operation depends on understanding and maintaining precise state, the wallet may be shifting too much responsibility onto them. As he put it, “You’re giving them an option to mess up.” He argues that wallet developers should build the feature in a way that keeps it secure, rather than expecting ordinary users to handle every technical detail correctly.

One approach Trezor is considering is to make the larger, slower stateless signatures the default. The more efficient but riskier stateful option could be available through advanced settings, rather than presented as the ordinary choice. This design would favor safety and simplicity for most users while retaining the option for those willing to understand and manage the additional requirements.

The central design challenge is not choosing the fastest signature in isolation; it is ensuring that the most convenient option is also difficult to misuse. A default setting can shape security across a large number of wallets, while an advanced option can preserve flexibility for users who value efficiency and understand its conditions.

SHRINCS has a potential advantage in its conservative cryptographic basis: it relies on the same cryptographic assumptions as SHA-256. However, confidence in those assumptions does not eliminate practical concerns about implementing stateful signatures. Sušánka has expressed mixed feelings because maintaining state can become a burden, especially when users expect their wallets to work consistently across devices.

For example, a user might have two Trezor devices backed by the same recovery seed. If both devices can sign transactions, their signing histories would need to remain coordinated to avoid reusing one-time keys. Sharing and updating that state reliably is not straightforward. A wallet maker must consider whether the devices can communicate, how state is recovered after a failure, and what should happen when a user restores a wallet from a backup.

At the same time, the efficiency difference matters. Sušánka noted that stateful signatures are 10 times smaller. That reduction could make a meaningful difference to transaction data and system efficiency. Consequently, simply rejecting stateful signatures would set aside a significant benefit. The choice is a trade-off between smaller signatures and the operational and security demands of maintaining their state.

Quantum readiness also reaches beyond the signature format used for Bitcoin transactions. Many hardware wallets rely on quantum-vulnerable cryptography for device-specific security functions, including firmware verification and device authentication. Even if Bitcoin adopts post-quantum transaction signatures, a device whose software or identity checks remain vulnerable would not be fully protected against quantum-era threats.

For a hardware wallet to be considered quantum-ready, its own security mechanisms must use post-quantum cryptography. This includes checking that firmware is authentic and establishing trust in the device itself. Trezor is already shipping products such as Trezor Safe 7 that support post-quantum cryptography for wallet authentication processes. That support is an important step for device security, but it does not by itself make Bitcoin transactions quantum-secure.

Transactions created with such a device will become quantum-secure only when Bitcoin itself adopts and activates post-quantum protections. This distinction matters: a capable wallet cannot independently change the rules of the network, and a network upgrade cannot automatically replace vulnerable security functions inside every device. Coordinating these layers will require developers, wallet manufacturers, and users to prepare for a gradual transition.

Sušánka has cautioned developers against waiting too long to provide users with migration options. Moving potentially millions of users to new security practices will take time. Wallet software, devices, recovery procedures, and user education all have to support the transition. A technically ideal solution that arrives without practical migration paths may be difficult to adopt at scale.

There will also be choices about how strict the transition should be. Restricting every feature or insisting that every user adopt one uncompromising approach could slow progress. On the other hand, prioritizing convenience without explaining security conditions could leave users exposed. The challenge is to make reasonable compromises while keeping the consequences of each option clear.

In practical terms, preparation for post-quantum Bitcoin is a shared responsibility. Researchers must assess candidate signature schemes; protocol developers must work through network-level changes; wallet makers must design reliable signing and recovery experiences; and device manufacturers must update authentication and firmware protections. Users, in turn, need clear information about when an upgrade is required and how to migrate without losing access to funds.

The debate around SHRINCS therefore reflects a broader lesson about security engineering. Strong cryptographic tools are only one part of a secure system. How those tools are implemented, what defaults are selected, how devices handle failures, and whether users can follow the intended process all influence real-world safety. A balanced design will need to address technical strength and human behavior together.

Key Insights Table

Afterwards...

The path to quantum-resistant Bitcoin will depend on progress across several connected areas. Researchers and developers will need to evaluate post-quantum signature schemes, test their performance, and identify how they can be introduced without creating unacceptable risks for users. Protocol-level planning should be paired with wallet designs that make safe behavior the easiest behavior.

Hardware security deserves equal attention. Future work should examine how post-quantum cryptography can protect firmware updates, device authentication, and recovery processes, while ensuring these mechanisms remain dependable in ordinary use. Products that support post-quantum authentication are useful preparation, but their value must be understood as part of a broader system transition.

Migration research should also focus on real-world conditions: users may have multiple devices, use backups, or need to restore wallets years after setup. Clear procedures for managing signing state, replacing devices, and responding to mistakes will be central to reducing risks. The most durable approach will combine sound cryptography with careful defaults, resilient recovery, and accessible guidance.

Ultimately, quantum readiness is not a single switch that can be turned on by one company or one software update. It is an extended coordination effort involving research, network development, hardware, wallet interfaces, and user education. Exploring these areas together can help the Bitcoin ecosystem adopt stronger protections without overlooking the practical details that determine whether security works in everyday life.