Bitcoin quantum exposure
Total BTC currently held at addresses whose pubkey has been revealed
on-chain — the supply that a sufficiently powerful quantum
attacker could steal by inverting ECDSA/Schnorr signatures. Updated
weekly from a full UTXO-set walk joined against our
revealed_addresses registry.
revealed_addresses registry is being built by a
chronological chain walk on cq-index
(tools/backfill_quantum_exposure.py). Every input in
every block is inspected; we record an address as exposed only
when its pubkey was actually revealed on-chain — P2PK and
P2TR outputs (always exposed), and P2PKH/P2WPKH/P2SH/P2WSH inputs
whose spend revealed a pubkey + CHECKSIG. Aggregates populate the
chart below as snapshots accumulate.
What's actually at risk
A quantum computer with enough qubit-stability to run Shor's algorithm against secp256k1 could derive a private key from any publicly-visible pubkey. Bitcoin's hash-based address types (P2PKH, P2WPKH, P2SH, P2WSH) protect the pubkey behind a SHA256 + RIPEMD160 hash until you spend — once you do, the pubkey is permanently in the witness data for anyone to harvest, and every subsequent UTXO at the same address is just as exposed as the moment of first spend.
P2PK and bare-multisig outputs (mostly pre-2013 coinbase and ancient fund-flows) carry the pubkey directly in the output script — they were always exposed. P2TR (taproot) outputs use the x-only pubkey as the address by design, also always exposed. Address reuse on hashed types is the largest single contributor; the Satoshi-era P2PK supply is the most symbolically significant.
Why our number is honest
BIP-361 reports 34% of all BTC as quantum-exposed
as of March 2026. We expect to land near that figure but slightly
lower because we apply STRICT redeem-script parsing
on P2SH and P2WSH spends: an address gets marked exposed only when
the actually-revealed redeem script contains a pubkey push followed
by OP_CHECKSIG/OP_CHECKSIGVERIFY, or
contains OP_CHECKMULTISIG/OP_CHECKMULTISIGVERIFY.
Timelock-only redeem scripts
(OP_CHECKLOCKTIMEVERIFY OP_DROP OP_TRUE),
hash-preimage scripts, and OP_RETURN-shaped wrappers don't leak
pubkeys on spend and are correctly excluded. Conservative
tooling treats every spent P2SH/P2WSH as exposed and over-counts.
Methodology
- Source: our own bitcoind 28 node, queried via
getblockverbosity 3 (returns each input's prevout + scriptPubKey + witness inline). - Walker:
tools/backfill_quantum_exposure.pywalks blocks 0→tip chronologically, building a masterrevealed_addressesregistry keyed on address. - Exposure rules (mirrors BIP-361 threat enumeration):
- P2PK / bare multisig / P2TR — always exposed at output-create time.
- P2PKH / P2WPKH — reuse-exposed on first spend
(witness contains
<sig> <pubkey>). - P2SH / P2WSH — reuse-exposed on first spend iff the revealed redeem script contains a pubkey + CHECKSIG-family opcode.
- Aggregate: weekly UTXO-set walk via
dumptxoutset; each UTXO's value is summed into its exposure slice if the address appears inrevealed_addresses. Same pass as /lists/rich-list and /reports/distribution. - References: BIP-361 (Lopp et al.), P2PKH on bitcoin.it, our top exposed addresses by current balance.