Is Bitcoin Cash Quantum Safe?
Is Bitcoin Cash quantum safe? It's a question that deserves a serious, mechanism-level answer rather than vague reassurance. BCH inherits Bitcoin's secp256k1 elliptic-curve cryptography, meaning every address secured by ECDSA faces the same theoretical vulnerability to sufficiently powerful quantum computers as Bitcoin, Ethereum, or virtually any other major chain. This article walks through exactly how BCH's cryptography works, what a quantum attacker could do at Q-day, where BCH's migration options stand, and how lattice-based post-quantum wallets represent a structurally different approach to the problem.
How Bitcoin Cash Secures Transactions Today
Bitcoin Cash uses the same cryptographic stack that Bitcoin launched with in 2009. Understanding why that matters for quantum risk requires a brief look at what each layer does.
ECDSA on secp256k1
Every BCH wallet keypair is generated using the Elliptic Curve Digital Signature Algorithm (ECDSA) over the secp256k1 curve. When you send BCH, your wallet:
- Takes the transaction data.
- Signs it with your 256-bit private key using ECDSA.
- Broadcasts the signed transaction, exposing your public key on-chain.
The security assumption is that deriving a private key from a public key requires solving the Elliptic Curve Discrete Logarithm Problem (ECDLP), which classical computers cannot do in any practical timeframe for 256-bit curves.
SHA-256 and RIPEMD-160 Address Hashing
Before a public key is ever exposed, BCH addresses are protected by a double-hash: `RIPEMD-160(SHA-256(pubkey))`. This means an unspent, never-used address has an extra layer of protection because the public key has never been broadcast. The attacker would first need to invert SHA-256 and RIPEMD-160, which quantum computers are far less efficient at than breaking ECDLP.
Grover's algorithm, the primary quantum threat to hash functions, offers only a quadratic speedup. That effectively halves the bit-security of SHA-256 from 256 bits to 128 bits. 128-bit security remains extremely robust by most analyst standards for the foreseeable future.
The critical exposure, therefore, is not the address hash. It is ECDSA itself, specifically at the moment a public key becomes visible on-chain during spending.
---
What Q-Day Actually Means for BCH Holders
"Q-day" refers to the point at which a cryptographically relevant quantum computer (CRQC) can run Shor's algorithm on secp256k1 at practical speed, deriving private keys from exposed public keys.
The Two Categories of BCH Address Risk
| Address Type | Public Key Exposed? | Quantum Risk Level | Rationale |
|---|---|---|---|
| Fresh P2PKH / P2SH (never spent) | No | Lower | Attacker must break RIPEMD-160(SHA-256) via Grover — costly but not catastrophic |
| Reused or previously spent address | Yes (on-chain) | High | Public key is permanently on-chain; Shor's algorithm can target it |
| Pay-to-Public-Key (P2PK) outputs | Yes (by design) | High | Older output format exposes pubkey directly in scriptPubKey |
Key takeaway: any BCH output where the public key is already visible in the blockchain is fully exposed at Q-day. Researchers at the University of Sussex estimated in 2022 that roughly 4 million BTC sat in exposed-pubkey addresses; BCH, sharing Bitcoin's UTXO history up to August 2017, carries a proportional legacy of such outputs.
How Fast Could a Quantum Attack Happen?
Current quantum hardware from IBM, Google, and others operates in the range of hundreds to a few thousand physical qubits with high error rates. Breaking secp256k1 via Shor's algorithm is estimated to require ~2,330 logical qubits (Mark Webber et al., 2022), which translates to millions of error-corrected physical qubits given current noise levels.
Most credible analyst timelines place a CRQC capable of breaking 256-bit elliptic curves somewhere between 2030 and 2050, though the range is wide and contested. The uncertainty itself is the risk management problem. Infrastructure changes to a live blockchain take years of community consensus, development, and deployment.
---
Does Bitcoin Cash Have a Quantum-Resistance Roadmap?
This is where BCH's situation becomes nuanced. Bitcoin Cash does not have a formally published, community-endorsed post-quantum migration roadmap as of mid-2025.
BCH's Development Governance
Bitcoin Cash operates through a loosely coordinated set of development teams, including Bitcoin ABC, BCHN, and others, that reach rough consensus on protocol upgrades through annual hard forks. This governance model has produced meaningful technical improvements, including CashTokens (CHIP-2022-02) enabling native tokens and NFTs, and ongoing work on the BCH Virtual Machine (BCHVM).
However, the post-quantum question requires changes that are far more disruptive than adding opcodes or expanding script limits. Migrating away from ECDSA involves:
- Choosing a replacement signature scheme (see below).
- Defining a migration period and sunset date for ECDSA outputs.
- Handling coins in addresses whose owners are unreachable or deceased.
- Increasing transaction sizes, which affects block throughput.
None of these have a concrete BCH implementation plan in public repositories as of the time of writing.
Bitcoin Core's Parallel Situation
Bitcoin Core faces identical constraints. The Bitcoin developer community has had exploratory discussions around NIST PQC-selected algorithms (CRYSTALS-Dilithium for signatures, CRYSTALS-Kyber for key encapsulation), but nothing has been merged or formally proposed as a BIP that would govern a migration timeline. BCH, as a fork, inherits both the technical debt and the absence of a roadmap.
---
Post-Quantum Signature Schemes: What Migration Could Look Like
If BCH or Bitcoin were to add post-quantum signature support, the leading candidates are the algorithms NIST finalized in its Post-Quantum Cryptography standardization process in 2024.
CRYSTALS-Dilithium (ML-DSA)
- Type: Lattice-based (Module Learning With Errors, MLWE)
- Security assumption: Hardness of MLWE, which no known quantum algorithm solves efficiently
- Signature size: ~2,420 bytes (Dilithium2) vs. ~71 bytes for ECDSA
- Public key size: ~1,312 bytes vs. ~33 bytes (compressed secp256k1)
- NIST standard: FIPS 204
The size overhead is the practical obstacle for a UTXO chain. A BCH block filled with Dilithium signatures instead of ECDSA signatures would carry roughly 34 times fewer transactions at equivalent block size. Either block sizes must increase substantially, or a second-layer scheme must isolate PQC signatures from the base layer.
FALCON (FN-DSA)
- Type: Lattice-based (NTRU lattices)
- Security assumption: Hardness of NTRU lattice problems
- Signature size: ~690 bytes (FALCON-512)
- Public key size: ~897 bytes
- NIST standard: FIPS 206
FALCON offers a better size profile than Dilithium and is a more plausible fit for a UTXO chain, though its signing algorithm requires careful constant-time implementation to avoid side-channel attacks, which adds engineering complexity.
SPHINCS+ (SLH-DSA)
- Type: Hash-based (stateless)
- Security assumption: Collision resistance of hash functions only
- Signature size: ~8,080 bytes (SPHINCS+-SHA2-128f)
- NIST standard: FIPS 205
Hash-based schemes are the most conservatively secure option because they rely only on hash functions, not new algebraic assumptions. But the signature size overhead makes them impractical for on-chain UTXO use without radical block-size changes.
Summary Comparison
| Scheme | Type | Sig Size | PQ Secure | NIST Standard | UTXO Practicality |
|---|---|---|---|---|---|
| ECDSA (secp256k1) | Elliptic curve | ~71 B | No | — (classical) | High (current) |
| ML-DSA / Dilithium | Lattice (MLWE) | ~2,420 B | Yes | FIPS 204 | Low without changes |
| FN-DSA / FALCON | Lattice (NTRU) | ~690 B | Yes | FIPS 206 | Medium |
| SLH-DSA / SPHINCS+ | Hash-based | ~8,080 B | Yes | FIPS 205 | Very low |
---
How Lattice-Based Wallets Differ From ECDSA Wallets
The distinction is not merely algorithmic. It reflects a fundamentally different security model at every layer of key generation and signing.
Key Generation
ECDSA private keys are 256-bit integers. Their security rests on the presumed intractability of ECDLP for classical and, critically, not quantum computers. Lattice-based keys are generated from high-dimensional vector spaces where the hard problem is finding short vectors in a lattice. Both quantum and classical algorithms for this problem scale poorly, meaning lattice security survives Q-day.
Wallet Architecture
A post-quantum wallet must:
- Generate keys from a lattice-based construction (e.g., MLWE or NTRU).
- Store and manage significantly larger key material securely.
- Produce and broadcast larger signatures without degrading user experience.
- Remain backward-compatible with or clearly separated from ECDSA-based chains until those chains migrate.
Projects building in this space today are operating ahead of the blockchain layer, providing holders with quantum-resistant custody before the underlying chains have completed any migration. BMIC.ai, for example, is a wallet and token built explicitly around NIST PQC-aligned, lattice-based cryptography, designed to address exactly this custody gap before Q-day arrives.
---
Practical Steps BCH Holders Can Take Now
Waiting for a BCH protocol-level migration may mean waiting a decade or more. In the interim, there are concrete risk-reduction steps any BCH holder can take:
- Avoid address reuse. Generate a fresh address for every transaction. This keeps your public key off-chain until the moment you spend, maximising the time window before any quantum threat becomes relevant.
- Move funds out of P2PK outputs. Legacy Pay-to-Public-Key outputs expose the public key directly. Consolidating these into fresh P2PKH addresses under your control removes one category of exposure.
- Monitor NIST and IETF standards development. FIPS 204, 205, and 206 are finalized. Watch for BIPs, CHIPs (BCH improvement proposals), or protocol discussions that reference these standards, as these will be the earliest signal of formal migration planning.
- Use hardware wallets with strong physical security. A quantum attack on ECDSA requires the public key to already be on-chain. Until Q-day, robust physical security remains the primary threat vector.
- Diversify custody solutions. Consider holding a portion of crypto assets in wallets built on post-quantum cryptography, particularly for long-horizon holdings.
---
The Broader Context: Is Any Major Chain Quantum Safe?
Honestly, no, not fully. Bitcoin, Ethereum, Litecoin, Dogecoin, XRP, and virtually every other proof-of-work or proof-of-stake chain in widespread use today relies on ECDSA or EdDSA, both of which are vulnerable to Shor's algorithm. The Ethereum Foundation has referenced a potential post-quantum migration path involving account abstraction and STARKs, but no production-ready timeline exists. The entire crypto industry is in a race between quantum hardware maturity and protocol migration velocity.
BCH's situation is neither uniquely bad nor uniquely prepared. It shares the structural exposure of virtually every chain launched before the NIST PQC standards were finalized, and it faces the same governance and engineering challenges in responding. The differentiating factor for holders is not which chain they hold, but whether their custody layer is protected by quantum-resistant cryptography.
Frequently Asked Questions
Is Bitcoin Cash quantum safe right now?
No. Bitcoin Cash uses ECDSA on the secp256k1 curve, which is vulnerable to Shor's algorithm running on a sufficiently powerful quantum computer. Unspent addresses where the public key has never been broadcast have a secondary layer of protection via SHA-256 and RIPEMD-160 hashing, but any address with an exposed public key is directly at risk at Q-day.
When could a quantum computer actually break BCH's cryptography?
Most analyst estimates place a cryptographically relevant quantum computer (CRQC) capable of breaking 256-bit elliptic curves between 2030 and 2050, though the range is highly uncertain. Current hardware requires millions of error-corrected physical qubits to execute Shor's algorithm at that scale, and error-correction overhead remains a major engineering obstacle.
Does Bitcoin Cash have a post-quantum upgrade plan?
Not formally. As of mid-2025, there is no community-endorsed CHIP or development roadmap specifying a post-quantum signature migration for BCH. The development community has focused on CashTokens and VM improvements. A PQC migration would require selecting a NIST-approved scheme, handling legacy UTXO outputs, and managing the transaction-size overhead of lattice-based signatures.
Which post-quantum signature schemes are most likely to be used in a BCH migration?
FALCON (FN-DSA / FIPS 206) is considered a relatively practical candidate for UTXO chains because its signature size (~690 bytes) is smaller than Dilithium (~2,420 bytes) or SPHINCS+ (~8,080 bytes). All three are NIST-standardized, lattice-based or hash-based schemes that resist known quantum attacks. Final selection would depend on BCH's block-size tolerance and community consensus.
Can I protect my BCH holdings against quantum risk today?
Partially. Avoiding address reuse keeps your public key off-chain until the moment of spending, reducing quantum exposure. Moving funds out of legacy P2PK outputs removes a direct vulnerability. For stronger protection, some holders are also using custody solutions built on post-quantum cryptography to secure long-horizon holdings while waiting for protocol-level migrations.
Is Bitcoin equally exposed to quantum risk as Bitcoin Cash?
Yes, functionally. Both use ECDSA on secp256k1 and the same address-hashing structure. Bitcoin also has no finalized post-quantum migration roadmap as of mid-2025. The quantum risk profile is essentially identical between BTC and BCH at the base protocol layer.