
Coinbase advances Bitcoin’s post-quantum readiness while holding about 5% of BTC
Summarizes Coinbase's blog post on preparing Bitcoin and custody infrastructure for post-quantum threats. It covers public-key exposure (an estimated 6.7–7M BTC behind already-exposed keys), BIP 360 (P2MR) and P2TRv2 outputs, 1-of-2 hybrid classical/post-quantum spending paths, and the state-reuse forgery risk of stateful signatures. It also covers candidate schemes (ML-DSA, SLH-DSA, FN-DSA, SHRINCS), MPC/HSM compatibility and side-channel tests, and separate handling of dormant, lost and exposed legacy funds.
What it is
A secondary report on Coinbase's blog post about post-quantum preparation for Bitcoin and custody. Coinbase says it holds about 5% of all BTC, and the post is framed as "technical considerations for discussion rather than a final position." The parts an engineer can act on today are the address-exposure rules and the custody constraints on stateful signatures.
How it works
Whether a quantum attacker can derive a private key depends on whether the public key is already visible onchain. The page, citing Fireblocks' Michael Gutkin, breaks this down by output type:
- Pay-to-public-key: the key is exposed immediately.
- P2PKH and native SegWit: the key is hidden until the first spend. Receiving more funds at an address that has already spent leaves those funds behind an exposed key.
- Taproot: output keys are visible from creation.
BIP 360's authors distinguish two attacks. One targets long-visible keys. The other is faster and runs in the window between a transaction revealing its key and its confirmation.
flowchart TD
A[Public key onchain?] -->|Yes: P2PK, Taproot, reused address| B[Exposed: long-term risk]
A -->|No: unspent P2PKH or SegWit| C[Hidden until spend]
C --> D[Spend reveals key]
D --> E[Confirmation-window attack]
B --> F[Needs migration path]
E --> G[Needs PQ signatures, not just BIP 360]What to do
- Use fresh deposit and change addresses (Gutkin's recommendation).
- Continuously track exposed balances.
- For custody design, require exclusive access to a stateful key and its state during signature generation. Plan for failed state updates and backup recovery, and give wallets clear guidance plus a stateless fallback.
- Evaluate candidates on Bitcoin-specific criteria:
- signature and key size, and verification speed
- security assumptions
- implementation maturity and MPC compatibility
- side-channel resistance and random-number dependence
- signing throughput, hardware support, block capacity, fees, validation load and migration cost
- For rescue proposals for legacy funds, check that the recovery path is quantum-safe and unusable by an attacker who knows only an exposed public key.
- If the chosen scheme cannot work with existing distributed-signing systems, Chief Cryptographer Yehuda Lindell describes exploring programmable HSMs (per a September 23, 2026 crypto.news report).
Caveats
- BIP 360 reduces long-term key exposure but is not complete quantum protection. Attacks before confirmation may still require post-quantum signatures.
- Blockchain history cannot reliably reconstruct stateful-signature state, because not every signature or update reaches the chain. Reusing state allows immediate forgery.
- The 6.7–7M BTC exposure figure is a public estimate relayed through crypto.news.
- FN-DSA is conditional on standardization. SHRINCS (stateful FXMSS paired with a stateless SLH-DSA-derived fallback) still has open questions about recovery and implementation reliability.
- Coinbase wants at least one promising MPC-compatible option, so MPC support is not yet established.
- The article is AI-assisted and secondhand. Check the Coinbase post itself before citing it.
Organisations named here
- BIP 360
- Bitcoin Security Consortium
- FXMSS
- Michael Gutkin
- ML-DSA
- P2MR
- P2TRv2
- Schnorr
- SHRINCS
- SLH-DSA
- Yehuda Lindell
Technologies named here
- BIP 360
- P2TRv2
- Bitcoin pay-to-public-key outputs
- ML-DSA
- Bitcoin pay-to-public-key-hash and native SegWit addresses
- SLH-DSA
- Bitcoin Taproot outputs
- Bitcoin ECDSA/Schnorr classical signatures
- SHRINCS
- Bitcoin Security Consortium
- Multi-party computation
- Coinbase blog post
- Bitcoin
- Coinbase
- FN-DSA
- ECDSA
- Fireblocks
Techniques named here
- Stateful signature state reuse allowing immediate forgery
- Hybrid 1-of-2 spending path
Related in Blockchain

THORChain Exploit Report #2 — GG20 root-cause disclosure

Black Thursday revisited: MakerDAO keeper exploited for $500K
.jpg)