How to Check if Your Bitcoin Address Has an Exposed Public Key

The exposure audit: how to tell whether your Bitcoin output has published its public key, and what that does and doesn’t mean before Q-Day.

A block explorer · 6 output types · Check the spending history and other disclosure paths.

You don’t need a working quantum computer to check whether an address has published its public key. All you need is a block explorer and a methodical pass. This guide is the audit: the one mechanism to anchor on, the six output types and how to classify yours, the steps to check, and what to do if a key is already exposed. It also marks the limits, because an explorer can confirm a disclosure but can’t prove a key has never been disclosed.

1. The mechanism: the spend reveal

Every common single-key Bitcoin output is controlled by a public key, a point on the secp256k1 curve. Your private key lets you spend; the public key is the input a future quantum attacker needs, because Shor’s algorithm on a large enough quantum computer recovers the private key from the public key.

P2PKH and P2WPKH outputs contain HASH160 of the public key, which is RIPEMD-160 applied to its SHA-256 hash. Spending either type requires providing the public key alongside a signature, in the scriptSig for P2PKH or the witness for P2WPKH.

Broadcasting the spending transaction discloses the key, and confirmation records it on chain. P2SH and P2WSH instead commit to scripts, so their disclosure rules depend on the underlying arrangement. That first spend is the spend reveal: the public key leaves the vault and joins the public record, permanently.

Two states, two attack surfaces

Before any disclosure of the key:

A P2PKH or P2WPKH output contains its 160-bit hash rather than the public key. Hiding the key behind a hash means an attacker can’t apply Shor to it directly. Generic quantum preimage search has an idealized cost of around 2^80 queries for HASH160 and 2^128 for SHA-256, with substantial added implementation cost, and those figures don’t establish a date when such an attack becomes practical. Note that no spend refers to this address’s recorded history only; the same key can be disclosed elsewhere (Section 7).

After a spend reveals the key:

The public key becomes available to observers when the transaction is broadcast, and is recorded on chain if it confirms. A capable quantum computer could attack that key later. The continuing exposure affects other unspent outputs controlled by the same key, and the spent output itself has been consumed.

Two output types skip the hash layer entirely (Section 3), and one attack does not even wait for Q-Day (Section 7).

2. The stakes: what Q-Day means

Bitcoin signs with ECDSA, and with Schnorr since Taproot activated in November 2021. Both are elliptic-curve schemes on secp256k1, and both fall to Shor’s algorithm once a fault-tolerant quantum computer is large enough. Q-Day is the loose name for the day that capability exists at scale.

No publicly demonstrated quantum computer can recover a Bitcoin private key at this scale today. Published estimates and hardware roadmaps give different timelines, and none establishes a guaranteed date for a practical attack. As one data point, IonQ published a resource estimate in September 2026 that ties a proposed attack architecture to its roughly 2028 hardware roadmap, which is a company projection rather than a demonstrated capability. Our timeline comparison lays the forecasts side by side. Two practical consequences follow:

• Migration needs preparation. Adding post-quantum spending authorization requires implementation review, agreement on consensus changes, and support across wallets and services, and moving existing holdings would add another stage. Those steps need planning before practical attacks become possible.
• An upgrade will not erase an exposed public key. Coins left under vulnerable spending rules stay at risk, but moving them into a suitable post-quantum output before any compromise can remove that exposure. The migration process and any deadlines will depend on the upgrade Bitcoin adopts, such as the legacy-signature restrictions proposed in draft BIP-361. This audit tells you which coins would be in that bucket.

3. Six output types, two exposure profiles

The prefixes below identify common mainnet output types. The table describes what each output contains and normally discloses when spent; keys or scripts may already have been revealed elsewhere.

Output type	Prefix / length	On chain while idle	Public key revealed	Long-term posture
P2PK (early raw script)	no address prefix; inspect the output script	the key itself	When the output script becomes available	Key on chain regardless of spending
P2TR (Taproot)	bc1p…	32-byte x-only key	Always, through the address itself	Key exposed independently of spending
P2PKH (Legacy)	1…	HASH160 of the key	At first spend (scriptSig)	Hidden on chain until spend
P2WPKH (SegWit)	bc1q… (42 chars)	HASH160 of the key	At first spend (witness)	Hidden on chain until spend
P2SH	3…	HASH160 of a script	At spend (whatever the script contains)	Depends on the script
P2WSH	bc1q… (62 chars)	SHA-256 of a script	At spend (whatever the script contains)	Depends on the script

P2PK

stores the public key directly in the output, with no hash and no buffer. It has no standard address format like 1… or bc1…, so you inspect the output script itself. A slice of 2009–2010 coinbase coins still sits in these.

Taproot (bc1p)

commits to a 32-byte x-only public key in the address itself, so the key is visible independently of whether the output has been spent, and the key-path spend remains a potential target even when the intended arrangement uses scripts. For reducing long-term key-recovery exposure, a hash-committed output avoids that.

P2PKH (1…) and P2WPKH (bc1q, 42 chars)

both store HASH160 of a single key and share one profile: hidden on chain until spend, published after. For public-key disclosure, the relevant difference is where the key appears, the scriptSig for P2PKH and the witness for P2WPKH.

P2SH (3…) and P2WSH (bc1q, 62 chars)

store a hash of a script, so exposure depends on the script and its spending paths. A spend reveals the redeem or witness script, which may or may not contain public keys; a P2SH-wrapped P2WPKH reveals one key, a 2-of-3 multisig reveals three. SHA-256 raises the idealized preimage-search cost to about 2^128 queries, against about 2^80 for HASH160.

Telling the bc1q forms apart:

the bech32 length encodes the program. 42 characters is P2WPKH, 62 characters is P2WSH.

Ranked for a long hold

P2PK and P2TR: the key is on chain regardless of spending. P2PKH and P2WPKH: the key is hidden on chain until the first spend, then published. P2SH and P2WSH: depends on the script; inspect the spending paths. None of these six output types, by itself, guarantees post-quantum spending authorization.

Keeping a public key hidden reduces long-term exposure but does not replace suitable post-quantum spending rules. For reducing long-term key-recovery exposure, a fresh P2WPKH under an undisclosed key avoids Taproot’s always-visible key (fresh P2PKH also keeps its key behind a hash). This is one security consideration, not a verdict on the best overall custody setup. Which addresses are vulnerable has the full breakdown.

4. The lifecycle, in one view

Always-on-chain keys (P2PK, Taproot): coins received → public key is in the output or address, no hash → exposed regardless of spending → at Q-Day, Shor could recover the private key.

Hash-committed single-key outputs (P2PKH, P2WPKH): coins received → only a hash on chain → key remains hidden provided it has not been disclosed elsewhere → first spend is the spend reveal → public key on chain → at Q-Day, Shor could recover the private key.

Script outputs (P2SH, P2WSH): the hash commits to a script; a spend reveals that script, and what it discloses (which keys, which conditions) depends on the script.

For P2PKH and P2WPKH, no recorded spend means no public-key disclosure was found through this address’s spending history. The same key may already be visible elsewhere, including on chain. Broadcasting a spend discloses the key; confirmation records it on chain.

5. How to check

Step 1. Identify the output type.

Open each address holding a non-trivial balance in a block explorer (mempool.space, blockstream.info, blockchain.com). The header shows the type, and the prefix is a fast filter:

1… -> P2PKH (hash-committed single key)

3… -> P2SH (script-hash: inspect the script)

bc1q… 42 chars -> P2WPKH (hash-committed single key)

bc1q… 62 chars -> P2WSH (script-hash: inspect the script)

bc1p… -> P2TR (key visible from the address itself)

Step 2. Check the address’s spending history.

For P2PKH and P2WPKH, look for any transaction that spent an output paying to this address, including transactions currently in the mempool.

• No spends found: this address’s available transaction history shows no spending disclosure. The key may still have been disclosed elsewhere (Section 7).
• A spend found: inspect the spending input for the public key. A confirmed spend records it on chain; an unconfirmed broadcast can already disclose it.

Receiving into P2PKH or P2WPKH does not itself publish the public key. P2PK and Taproot expose a public key independently of spending.

Step 3. Verify by hand (optional).

For a transaction currently in your node’s mempool, getrawtransaction works without transaction indexing. Where a confirmed transaction is concerned, use a node with transaction indexing enabled, or supply the hash of a block that the node still has available. For a transaction known to your wallet, use gettransaction with verbose output. An input identifies the previous output by transaction ID and output index, so match those to your target output before reading the spending data.

Then read the spending input. For P2PKH, parse the scriptSig and read the public key it pushes (a 33-byte compressed or 65-byte uncompressed key), rather than assuming a fixed character count. In terms of P2WPKH, the key is the second txinwitness item. For a P2SH-wrapped P2WPKH the key is in the witness, not the redeem script. For P2SH and P2WSH generally, inspect the underlying script and all spending paths and identify which keys or conditions are disclosed. A P2WPKH spending input has exactly two witness items:

Schematic example: the second item contains the public key. These placeholders are not transaction data.

Inspecting a transaction confirms a disclosure; it cannot prove a key was never disclosed elsewhere. For an unspent P2SH or P2WSH arrangement whose script has never been disclosed, get the script or descriptor from your own wallet, since an explorer shows only the hash commitment, not the hidden script. Inspect the complete spending conditions from that information, and do not upload a private descriptor or seed phrase to a public service.

Step 4. Interpret.

• Single-key hash type, no spend found: no disclosure in this address’s recorded history. Check the other disclosure paths in Section 7 before treating it as safe.
• P2PKH or P2WPKH with a confirmed spending history: the spending transaction has published the key. Check whether that key still controls any unspent outputs, and run Section 6 for those.
• bc1p or P2PK: the key is available regardless of spend count. Same remediation.
• P2SH or P2WSH: inspect the script and its spending paths; note which keys or conditions a spend discloses and what an attacker would need to satisfy.
• Conventional script-based multisig: disclosure of the script reveals all public keys listed in it, including those not used to sign that transaction. Check other outputs using those keys against their own signature thresholds and spending conditions.

6. What to do if a key is exposed

No publicly demonstrated quantum computer can exploit Bitcoin public keys at the required scale today, and published timelines vary. Moving coins in a hurry carries its own risk (a self-custody mistake), so weigh that against an exposure whose timing is uncertain. If you plan to hold for a decade or more, the steps are:

Move exposed holdings to a fresh P2WPKH address controlled by a new, undisclosed key.

Check that the key is not reused and cannot be derived from public-key information already shared with potential attackers, such as an xpub. This reduces exposure while the coins stay unspent; it does not provide post-quantum spending protection.

Generate a fresh address for every receive.

Modern wallets do this by default; leave the setting alone.

Favor a hash-committed output over Taproot for long holds.

Taproot’s output key is visible independently of spending, so a fresh P2WPKH exposes less at rest. This is one consideration, not a full custody recommendation. See hot wallets vs cold wallets.

Split large balances across several fresh addresses that use different, undisclosed keys

The goal is to lower the value behind any single key.

Weigh multisig for large vaults.

Conventional 2-of-3 multisig requires two valid signatures. Once its script is disclosed, all three public keys are visible, and a quantum attacker could spend by recovering any two of the corresponding private keys. Multisig does not make elliptic-curve signatures quantum-resistant.

Keep your backups verified.

A safer output you cannot recover is still lost; see seed phrases vs PQC.

The long-term fix is protocol-level. Draft BIP-360 proposes a new output type (Pay-to-Merkle-Root) to mitigate long-exposure attacks by removing Taproot’s exposed key-path spend; it is a draft, and it is not complete post-quantum spending protection on its own. Assume you may be asked to move coins again when the ecosystem upgrades, so knowing now how much would need to move makes that migration a known quantity. The broader action plan is in how to protect your crypto from quantum computers.

7. What this audit can’t tell you

• In-flight spends. For a spending path that reveals a public key, broadcasting the transaction exposes it before confirmation. If a quantum machine could recover the corresponding private key fast enough, an attacker could race a competing spend. Success would depend on how quickly the attacker recovers the key and whether miners confirm the forged transaction before the legitimate one; fees and wallet behavior affect the confirmation window but cannot guarantee protection.
• When Q-Day is. This audit tells you whether the math would break your output, not when the machine arrives.
• Disclosure elsewhere. A key can be published outside this output’s spending history: through key reuse across outputs, a shared xpub or descriptor, or a signed message. A leaked seed phrase or private key can enable theft today. Sharing an xpub exposes the public keys within its non-hardened derivation subtree, which is a privacy risk and a potential future quantum exposure even for addresses that have never spent. None of this is on chain in this output, and none of it is covered by the check above.

Treat address hygiene as part of your storage discipline, alongside seed-phrase backups and firmware updates.

8. Checklist: pre-Q-Day hygiene

The hygiene checklist

1. List every address holding a non-trivial balance.
2. Classify each by prefix: 1… / 3… / bc1q (42) / bc1q (62) / bc1p (and inspect P2PK output scripts).
3. bc1p or P2PK: key on chain regardless of spend count. Consider remediation.
4. P2PKH and P2WPKH: check the address’s confirmed and unconfirmed spending history for public-key disclosure, then check whether the same key has been disclosed elsewhere.
5. Script-hash types: decode a spending input, or if the arrangement has never spent, get the script or descriptor from your own wallet; note which keys and conditions appear across all spending paths.
6. Check for disclosure elsewhere: key reuse, shared xpub or descriptor, signed messages, unconfirmed broadcasts.
7. Move exposed balances to fresh P2WPKH addresses under new, undisclosed keys; fresh receive address for everything after.
8. Split large balances; weigh multisig for vaults.
9. Re-verify backups before and after any move.
10. Re-audit after any future spend, and again when the protocol upgrades.

Sources

• QNews, Which Bitcoin Addresses Are Quantum-Vulnerable?
• QNews, Grover’s Algorithm vs SHA-256 and Shor’s Algorithm Explained
• Bitcoin Core documentation, getrawtransaction RPC: bitcoincore.org
• BIP-360 (draft), Pay-to-Merkle-Root: github.com/bitcoin/bips
• BIP-361 (draft), Post-Quantum Migration and Legacy Signature Sunset: bips.dev/361

Keep going

New to the threat? Start with What Is Q-Day?

Continue the series:

• Which Bitcoin Addresses Are Quantum-Vulnerable?
• Is Bitcoin Safe From Quantum Computers?
• How to Protect Your Crypto From Quantum Computers

Browse all Q-Day guides.

This article is educational and does not constitute security or investment advice.