No quantum computer can break Bitcoin today. That line shows up in nearly every serious paper on the subject, and it is still true in October 2026. But “not yet” is doing a lot of work in that sentence, and a growing body of research says the gap between “not yet” and “someday” is smaller than most holders assume. A 2026 study published on arXiv puts the core attack at roughly 1,200 to 2,330 logical qubits, while the biggest machines running today top out around 100 logical qubits. That sounds comfortable. It is not an excuse to wait, because migrating a wallet takes minutes and migrating an entire protocol takes years.

There is also a timing problem that qubit counts alone do not capture. A quantum-capable adversary does not need a working machine today to start profiting from your wallet tomorrow. Anyone can record a public key the moment it appears on-chain and simply wait, a pattern security researchers call harvest-now, decrypt-later. That means the relevant question is not “will a quantum computer exist before I retire,” it is “is my public key already sitting in a permanent, unchangeable record, waiting for the day one does.” For a meaningful share of circulating Bitcoin, the honest answer is yes, right now, and no amount of waiting makes that answer better.

This tutorial walks through a concrete, repeatable process: audit which of your Bitcoin addresses actually expose a public key on-chain, rank that exposure by severity, then migrate the risky balances into a safer structure without creating new exposure along the way. You will write and run a real Python script against a live block explorer API, generate a fresh wallet, build a consolidation transaction, and set up ongoing monitoring. Budget 60 to 90 minutes for a modest wallet, longer if you are auditing exchange-scale holdings or coordinating a multisig setup across several hardware devices and household members.

Prerequisites: Tools, Versions, and Time You’ll Need

You do not need to run a full Bitcoin node to complete this audit, but having one gives you independent verification instead of trusting a third-party API for every lookup. Here is what this guide assumes you have installed or can install in the next few minutes.

  • Bitcoin Core v31.1 or newer, synced or syncing (optional but recommended for independent verification)
  • Sparrow Wallet 2.5.5 or newer, for descriptor export and PSBT signing
  • Electrum, latest version from electrum.org, as an alternative if you already hold coins there
  • Python 3.10 or newer, with pip install requests run once
  • A hardware wallet with its latest manufacturer firmware installed, if you use one for signing
  • A text file listing every address you control, one per line (you will build this in Step 2)
  • 60 to 90 minutes of uninterrupted time, plus a small amount of BTC for the migration transaction fee

None of this requires exotic software. The audit script talks to a public block explorer over HTTPS, and the migration steps use wallet features that have shipped in Sparrow and Bitcoin Core for years. What is new is the lens you are applying to a wallet you probably already have.

One more thing worth deciding up front: whether you are auditing a single personal wallet or something larger, like a small business treasury or a family trust spread across several hardware devices. The steps are identical either way, but a larger holding usually means more addresses to inventory in Step 2, more coordination required for the multisig setup in Step 8, and a stronger case for the timelock and documentation approach covered in the advanced tips near the end of this guide.

How Bitcoin’s Public-Key Exposure Actually Works

Bitcoin’s signatures rely on ECDSA and Schnorr, both built on the secp256k1 elliptic curve. A quantum computer running Shor’s algorithm could, in theory, recover a private key from a known public key by solving the elliptic-curve discrete-log problem underneath that curve. The catch, and the one detail that most headlines skip, is the word known. An attacker needs the actual public key, not just your address, which is normally a hash of that key.

That distinction is why address type matters so much. A standard P2PKH or native SegWit (P2WPKH) address only reveals its public key the moment you spend from it. Before that first spend, an attacker only has a hash, and reversing a hash with a quantum computer is a different, far harder problem, one that current post-quantum research does not treat as practically solvable even under generous assumptions. Once you spend, though, the public key is permanently stamped into the blockchain, and if you ever send funds back to that same address, those new funds inherit the exposure immediately, with no way to undo it short of moving the coins again.

Legacy P2PK outputs, common in Bitcoin’s earliest years before address hashing became the default, skip that protection entirely: the raw public key sits in the output from the moment coins arrive, whether or not anyone ever spends from it. Taproot (P2TR) output keys are visible on-chain even before spending, because the output commits directly to a 32-byte key, though the practical quantum math differs slightly since Taproot uses Schnorr rather than plain ECDSA. The upshot for anyone auditing their own wallet is that address type is not a minor technical footnote, it is the single biggest variable in how exposed a given balance actually is, and it is something you can check in seconds with the script in Step 3.

Address TypePrefixKey Visible Unspent?Key Visible After Spend?Exposure Level
P2PK (legacy)none, raw scriptYesYesStructural, always exposed
P2PKH1…No (hash only)YesExposed only after first spend
P2SH3…No (script hash only)Depends on redeem scriptVaries, multisig can reveal several keys
P2WPKH (native SegWit)bc1q…No (hash only)YesExposed only after first spend
P2TR (Taproot)bc1p…Yes (x-only key in output)YesStructural, exposed even unspent

Researchers at Spark Research, citing Glassnode on-chain data, put total exposed Bitcoin at roughly 6.04 million BTC, about 30.2% of circulating supply. Of that, around 1.92 million BTC comes from structural exposure (legacy P2PK and similar formats) and about 4.12 million BTC comes purely from address reuse, the single most avoidable cause on this entire list. Chaincode Labs produced a broader 2025 estimate of 4 million to 10 million BTC across all vulnerability categories, a wider range that reflects how much the methodology changes the answer, and separate analysis from Galaxy Research frames the industry’s current posture as actively preparing rather than panicking. An Ethereum researcher named Gutkin, in commentary later picked up by Yahoo Finance, put the number at 6.7 million to 7.0 million BTC, worth roughly $550 billion to $580 billion at a BTC price of $82,462. These figures are not interchangeable: “exposed” generally means a public key is visible somewhere on-chain, while a separate 2026 arXiv paper on quantum risk to Bitcoin estimates that around 2.3 million BTC is irreducibly at risk, meaning those coins are dormant, lost, or tied to Satoshi-era wallets whose owners may never move them regardless of warnings.

Step 1: Set Up a Synced Node and Pick Your Wallet Software

If you already run Bitcoin Core, confirm it is current and fully synced before you trust anything it tells you about your addresses.

bitcoin-cli -version
# Bitcoin Core RPC client version v31.1.0

bitcoin-cli getblockchaininfo | grep -E "blocks|headers|verificationprogress"
# "blocks": 872341,
# "headers": 872341,
# "verificationprogress": 0.9999998

If verificationprogress is not close to 1.0, wait before relying on local RPC calls for address history, and use the public API path in Step 4 in the meantime. If you do not run a node, install Sparrow Wallet 2.5.5 and point it at a public Electrum server for now. You can switch to your own node later without touching your keys.

Deciding between Sparrow and Electrum at this stage comes down to what you value more. Sparrow leans toward a visual, descriptor-first workflow that makes multisig and PSBT coordination easier to follow on screen, which is why this guide uses it for the migration steps later on. Electrum has a longer track record and a larger plugin ecosystem, and if your existing coins already live there, there is no requirement to switch wallets just to run this audit. The audit script itself in Step 3 does not care which wallet software you use, since it only reads addresses, not wallet files.

Step 2: Export Every Address You Control Into One Inventory

This is the step people skip and regret. Most holders can list their “main” addresses from memory, then forget the change addresses their wallet generates automatically on every outgoing transaction. Those change addresses sit on the same keychain and carry the same exposure math, yet they rarely show up anywhere you would naturally look, since most wallet interfaces hide them behind a “show change addresses” toggle you have probably never clicked.

If you have used more than one wallet over the years, perhaps an early Electrum install, a mobile wallet you abandoned, or a hardware wallet you later replaced, each of those has its own address set and its own exposure history. Treat this step as an inventory of your entire Bitcoin history, not just your current daily wallet.

# Sparrow Wallet 2.5.5: open your wallet, go to Addresses tab,
# select All (receive + change), then Export to CSV.

# From Bitcoin Core with a loaded watch-only wallet:
bitcoin-cli listdescriptors true
bitcoin-cli getaddressesbylabel ""

Paste every address, from every wallet you hold, into a plain text file named addresses.txt, one per line. Include exchange withdrawal addresses you have reused and any paper-wallet or old-wallet addresses you still control. The goal is a complete inventory, not a tidy one.

Step 3: Build the Quantum Exposure Audit Script

With your address list ready, the next step is a small Python script that classifies each address by type, checks its on-chain history against the mempool.space public API, and flags whether a public key has actually been revealed. Save this as quantum_audit.py.

#!/usr/bin/env python3
import sys
import time
import requests

API = "https://mempool.space/api/address/{}"

def classify_address(addr):
    if addr.startswith("1"):
        return "P2PKH"
    if addr.startswith("3"):
        return "P2SH"
    if addr.startswith("bc1q"):
        return "P2WPKH/P2WSH"
    if addr.startswith("bc1p"):
        return "P2TR"
    return "UNKNOWN"

def fetch_stats(addr):
    r = requests.get(API.format(addr), timeout=15)
    r.raise_for_status()
    return r.json()

def risk_level(addr_type, spent_count):
    if addr_type == "P2TR":
        return "STRUCTURAL"   # output key visible even unspent
    if spent_count > 0:
        return "EXPOSED"      # key revealed on a prior spend
    return "SAFE"             # unspent, key not yet revealed

def audit(addresses):
    report = []
    for addr in addresses:
        addr_type = classify_address(addr)
        stats = fetch_stats(addr)
        chain = stats.get("chain_stats", {})
        funded = chain.get("funded_txo_sum", 0)
        spent = chain.get("spent_txo_sum", 0)
        spent_count = chain.get("spent_txo_count", 0)
        balance = funded - spent
        report.append({
            "address": addr,
            "type": addr_type,
            "balance_sats": balance,
            "spent_tx_count": spent_count,
            "risk": risk_level(addr_type, spent_count),
        })
        time.sleep(0.3)  # stay inside the API's rate limit
    return report

if __name__ == "__main__":
    with open(sys.argv[1]) as f:
        addrs = [line.strip() for line in f if line.strip()]
    results = audit(addrs)
    exposed = sum(r["balance_sats"] for r in results if r["risk"] != "SAFE") / 1e8
    for r in results:
        print(f"{r['address']}  {r['type']:<13} {r['risk']:<10} "
              f"{r['balance_sats']/1e8:.8f} BTC")
    print(f"\nTotal exposed balance: {exposed:.8f} BTC")

This script deliberately treats Taproot as structurally exposed regardless of spend history, matching the research above, and treats P2PKH and native SegWit addresses as safe only until they have been spent from at least once. It does not touch private keys or request signing of anything, it only reads public blockchain data. That matters for a second reason beyond safety: because the script never needs your seed or any signing capability, you can safely run it on a laptop, a cloud VM, or even a phone, anywhere you can install Python and reach the internet, without ever bringing your actual wallet software into the same environment.

If you would rather not depend on a third-party API at all, the same logic can run against your own Bitcoin Core node using bitcoin-cli getaddressinfo combined with bitcoin-cli scantxoutset, trading a bit more setup complexity for complete independence from mempool.space's infrastructure and rate limits.

Step 4: Run the Audit and Read Your Exposure Report

Run the script against your address inventory from Step 2.

$ python3 quantum_audit.py addresses.txt
bc1qf8x...4zk2  P2WPKH/P2WSH  SAFE       0.05000000 BTC
1A1zP1eP...fNa  P2PKH         EXPOSED    0.00140000 BTC
bc1p3x9...k7m1  P2TR          STRUCTURAL 1.20000000 BTC
3F2k9j...q7Bz   P2SH          SAFE       0.00000000 BTC

Total exposed balance: 1.20140000 BTC

Every row with a status other than SAFE is a candidate for migration. Note that a SAFE result with a nonzero balance is not a reason to relax, it is a reason to make sure you never send a second payment to that same address before you have migrated the balance it already holds.

Step 5: Rank Your Addresses by Severity

Not every exposed address deserves the same urgency. Sort your report into three buckets before you touch a single transaction.

Exposure CategoryEstimated Network-Wide BTCSource
Total exposed public keys (Glassnode data)~6.04M BTC (30.2% of supply)Spark Research
Structural exposure (P2PK and similar)~1.92M BTCSpark Research
Address reuse~4.12M BTCSpark Research
Broader 2025 estimate, all categories~4M to 10M BTCChaincode Labs, via Spark Research
Dormant, lost, or Satoshi-era (irreducible)~2.3M BTCQuantum Horizon, arXiv 2026

For your own wallet, the priority order should be: legacy P2PK first (if you have any, these are the oldest and most exposed), then any address your script flagged EXPOSED due to a prior spend, then STRUCTURAL Taproot balances holding meaningful value, and last, SAFE addresses that you simply want to retire out of caution. There is no reason to rush a SAFE address with a small balance ahead of an EXPOSED address holding a year of savings.

It helps to think of this ranking the same way a security team triages a vulnerability list: severity first, blast radius second, and effort to fix last. A 0.001 BTC dust balance sitting in a reused address is a lower priority than a 2 BTC balance sitting in the same category, even though both technically carry the same EXPOSED label, because the dollar amount at stake changes how much urgency the situation actually deserves.

Step 6: Generate a Fresh Quantum-Aware Receiving Wallet

There is no quantum-resistant Bitcoin address format shipping on mainnet yet, so "quantum-aware" here means a wallet with a fresh seed, a modern descriptor, and a strict no-reuse policy going forward, not a cryptographic silver bullet.

# In Sparrow Wallet 2.5.5:
# File > New Wallet > choose a fresh BIP39 seed (never reuse an old one)
# Script Type: Native SegWit (P2WPKH) for everyday receiving
# Keep Taproot addresses for this wallet single-use only

Native SegWit is the pragmatic default here precisely because it only exposes a key after you spend, giving you more runway than Taproot's always-visible output key. Generate a new receiving address for every single incoming payment, no exceptions, and label addresses in your wallet software so you never have to guess which ones are fresh.

This does mean giving up some of Taproot's other benefits, like smaller multisig signatures and better privacy for complex spending conditions, in exchange for a narrower exposure window. That tradeoff will likely flip once a quantum-resistant output format actually ships and wallets support it by default, at which point the right move will be migrating again. Think of this new wallet as an interim step, not a permanent destination, and keep an eye on Step 12 for when that changes.

Step 7: Consolidate and Migrate Funds Without Re-Exposing Keys

Moving coins from an EXPOSED or STRUCTURAL address requires revealing one more signature from the old key, which is unavoidable, the goal is to make that the last time. Build one consolidation transaction per risk tier rather than one transaction per address, since each transaction has a fixed overhead cost regardless of how many inputs it carries.

# In Sparrow, select every input you want to migrate in the UTXO tab,
# right-click > Send Selected, and set the destination to your new
# Native SegWit wallet. Review the fee rate before signing.

# Estimate the virtual size and fee manually if you prefer:
# fee_sats = tx_vbytes * fee_rate_sat_per_vb

Check current network fee conditions before broadcasting. Batching ten exposed UTXOs into one transaction is almost always cheaper than ten separate transactions, but it also broadcasts all ten old public keys at once, which is fine since they are already on-chain and already exposed, it changes nothing about their risk status. What does matter is confirming the destination address one more time before you sign, since a consolidation transaction is usually your largest single transfer and the hardest one to reverse if you fat-finger the output.

Step 8: Layer In Multisig as Defense in Depth

Multisig does not make ECDSA or Schnorr quantum-resistant, every classical public key behind a multisig scheme could theoretically still be targeted. What it does is raise the number of keys an attacker would need to compromise simultaneously, and it protects against the more immediate threat of a single lost or stolen key.

bitcoin-cli createmultisig 2 '["03a1f2...pubkey1","03b4e9...pubkey2","03c7d1...pubkey3"]' bech32
bitcoin-cli addmultisigaddress 2 '["03a1f2...pubkey1","03b4e9...pubkey2","03c7d1...pubkey3"]' "migration-vault" bech32

Sparrow Wallet supports the same multisig setup through its wallet creation wizard, which is usually friendlier than raw RPC calls if you are coordinating keys across multiple hardware devices. A 2-of-3 setup spread across a hardware wallet, a second hardware wallet in a different location, and an air-gapped paper or steel backup is a reasonable baseline for meaningful holdings.

Step 9: Harden Seed and Backup Storage During Migration

A migration is exactly the moment when seeds and backups are most likely to end up somewhere insecure, written on a sticky note next to a laptop or photographed on a phone for "just a minute." Treat the new seed with the same discipline you would want for the old one.

  • Write the new seed on paper or stamp it into steel, never type it into a notes app or password manager that syncs to the cloud
  • Store the backup somewhere physically separate from the signing device
  • If you use a passphrase (BIP39 25th word), record it separately from the seed words themselves
  • Do not photograph, screenshot, or email any part of the seed at any point in this process

Step 10: Verify the Migration On-Chain and Retire Old Addresses

After broadcasting, confirm the funds landed where you expect and that the old addresses are now empty.

curl -s https://mempool.space/api/address/bc1p3x9...k7m1 | python3 -m json.tool

# Re-run the audit script on the old address list to confirm
# balances dropped to zero:
python3 quantum_audit.py addresses.txt

Mark the old addresses as retired in your records, but do not delete the old wallet seed itself until you are completely certain no further funds will ever arrive there. Exchanges, old invoices, and forgotten subscriptions have a habit of sending a stray payment to an address years after you thought you were done with it.

Step 11: Set Up Ongoing Exposure Monitoring

A one-time audit is a snapshot. Your exposure profile changes every time you receive or send a payment, so schedule the script to run automatically.

# crontab -e
0 */6 * * * /usr/bin/python3 /home/user/quantum_audit.py /home/user/addresses.txt >> /home/user/audit.log 2>&1

Add new addresses to addresses.txt as you generate them, and review audit.log weekly rather than waiting for a crisis to remind you. If a SAFE address ever flips to EXPOSED, you will know within hours instead of years.

If you manage this for a family or a small group, consider piping the cron job's output into a simple alert instead of a log file nobody checks, for example a local notification script or a message to a private channel you actually read. The goal is to make exposure visible the moment it happens, not to generate a file that quietly grows for a year before anyone opens it.

Step 12: Track BIP-360 and Future Protocol Changes

Everything above is mitigation at the individual-wallet level. The protocol-level fix is still in progress. BIP-360 provides a structural framework for quantum-resistant Bitcoin outputs, but as of October 2026 it deliberately leaves the specific post-quantum signature algorithm for later selection, according to analysis from postquantum.com's migration roadmap. It is a proposal, not an activated consensus change, and there is no finalized replacement for ECDSA or Schnorr signatures on Bitcoin today.

StandardFormer NameFIPS NumberBasis2026 Status
ML-DSACRYSTALS-DilithiumFIPS 204Lattice (Module-LWE)Finalized
SLH-DSASPHINCS+FIPS 205Hash-basedFinalized
FN-DSAFalconFIPS 206Lattice (NTRU)Draft, expected late 2026 or early 2027

NIST finalized ML-DSA and SLH-DSA as FIPS 204 and FIPS 205 respectively, giving Bitcoin developers two mature, standardized building blocks to choose from once consensus forms around which one (or which combination) fits a future address format. Watch the Bitcoin Core and Sparrow release notes, since whichever implementation ships that support first will likely define the practical migration path for everyone else.

Each of the three NIST standards trades off differently. ML-DSA produces relatively compact signatures and has already seen the most real-world adoption outside Bitcoin, including in TLS experiments. SLH-DSA is the most conservative choice because its security rests on well-understood hash functions rather than newer lattice assumptions, at the cost of noticeably larger signatures. FN-DSA aims for the smallest signatures and public keys of the three once finalized, which matters for a blockchain where every extra byte in every transaction adds up across millions of blocks. None of that engineering debate changes what you need to do this week, which is reduce your own exposure under the signature scheme Bitcoin actually uses today.

Common Pitfalls That Undermine a Quantum Migration

  • Assuming "unspent" means "safe" for every address type. It does for P2PKH and native SegWit, it does not for Taproot or legacy P2PK, which expose keys structurally.
  • Reusing the new "safe" address. Migrating funds into a fresh wallet and then reusing that fresh address for a second payment recreates the exact problem you just solved.
  • Forgetting change addresses. Your inventory in Step 2 is incomplete if it only covers addresses you remember receiving to directly.
  • Auditing from a hot, internet-connected machine with your seed loaded. The audit script only needs your public addresses, never your seed or private keys, keep them separate.
  • Ignoring small or dust balances. Old test transactions and forgotten dust outputs still carry exposed public keys and still count toward your total risk.
  • Treating one big consolidation transaction as "free." Batching many exposed UTXOs saves on fees, but it is still a real transaction with real fee costs, plan the fee rate and timing deliberately.

Troubleshooting Guide: 8 Problems and Fixes

  • mempool.space returns HTTP 429. You are hitting the public API's rate limit, add a longer delay between requests or run your own Electrum server for lookups.
  • Script reports "UNKNOWN" for an address. You likely have a testnet address, a bech32m edge case, or a very old non-standard script, check the address against a block explorer manually.
  • Bitcoin Core's verificationprogress never reaches 1.0. Check free disk space first, then check peer connectivity with bitcoin-cli getpeerinfo.
  • Sparrow Wallet has no CSV export option visible. Confirm you are on version 2.5.5 or newer and that the wallet is fully loaded, not just connected.
  • createmultisig returns an address format you did not expect. Pass the address type explicitly as the third argument, for example bech32, rather than relying on the default.
  • A PSBT will not finalize or sign. The descriptor attached to the PSBT likely does not match the HD path of the signing device, re-export the wallet descriptor and try again.
  • Your watch-only wallet balance does not match the audit script's output. The watch-only wallet's gap limit may be too low to have discovered every used address, increase it and rescan.
  • The fee estimate for your consolidation transaction is far higher than expected. You are likely combining too many inputs in one transaction, calculate the virtual size first or split the migration across two transactions during a lower-fee period.

Advanced Tips: Timelocks, Watch-Only Wallets, and Dormant Coin Strategy

For holdings you do not need to touch for years, an OP_CHECKLOCKTIMEVERIFY-based timelock can add a second layer that does not depend solely on key secrecy, forcing a minimum delay before any spend is possible even with a valid signature. This will not stop a sufficiently capable quantum attacker from eventually spending once the timelock expires, but it buys time, which is the one resource every mitigation strategy here is actually trading on. Combine a timelock with the multisig setup from Step 8 and you get two independent conditions that both need to fail before funds are at risk, which is a meaningfully different security posture than a single key behind a single signature scheme.

Keep a watch-only version of your new wallet on a separate, non-signing device so you can run the exposure audit and check balances without ever exposing the signing environment to a network connection. For genuinely dormant, long-term holdings such as inheritance plans, document the migration plan in writing (without recording seed words), so whoever eventually controls those coins understands the exposure math laid out in this guide rather than discovering it for the first time during an emergency.

Finally, resist the urge to treat every quantum-themed announcement as an emergency. The practical steps here (stop reusing addresses, know your exposure, migrate the worst cases first) remain the right response whether a capable quantum computer arrives in five years or fifty.

Migrating vs Doing Nothing: What You're Actually Trading Off

It is worth being honest about what this process costs you, since every mitigation here has a real tradeoff and skipping it has a real tradeoff too. Doing nothing costs you nothing today: no transaction fees, no time spent exporting descriptors, no risk of fat-fingering a destination address during a consolidation transaction. What it costs you is optionality. If a credible quantum threat does materialize on a shorter timeline than today's qubit estimates suggest, holders with exposed, reused, or legacy addresses will be racing everyone else in the network to migrate at the same moment, into a mempool that is almost certainly congested and fee rates that are almost certainly spiking.

ApproachUpfront CostOngoing EffortRisk If Timeline Accelerates
Do nothingNoneNoneHigh, must migrate under pressure during a potential panic
One-time audit only~15-20 minutesNoneMedium, you know the risk but have not reduced it
Audit plus full migration (this guide)60-90 minutes, one transaction feeA few minutes monthly to monitorLow, exposure already minimized ahead of time
Migration plus multisig plus timelock2-3 hours, coordination across devicesPeriodic backup verificationLowest, with added protection against key loss or theft too

Most individual holders land somewhere between the second and third row. A full audit plus migration is a weekend afternoon's worth of effort for most personal wallets, and it converts an open-ended, anxiety-inducing risk into a closed, understood one. The fourth row, full multisig with a timelock, makes the most sense for holdings you genuinely do not plan to touch for years, where the extra coordination overhead is a one-time cost rather than a recurring friction point every time you want to spend.

Frequently Asked Questions

Is my Bitcoin at risk from quantum computers right now?
No. Current machines have on the order of 100 logical qubits at most, far short of the 1,200 to 2,330 logical qubits a 2026 arXiv study estimates the attack requires. The risk is about preparation time, not an imminent threat.

What does running this audit actually cost?
Nothing beyond your time. The mempool.space API used in the script is free for reasonable personal use, and the only on-chain cost is the network fee for any migration transaction you choose to broadcast.

Does Taproot protect me from quantum attacks?
No, and it is a common misconception. Taproot's output commits to a public key that is visible on-chain even before you spend, which the research in this guide classifies as structural exposure, the same category as legacy P2PK.

What is BIP-360 and when will it ship?
BIP-360 is a proposed framework for quantum-resistant Bitcoin outputs. As of October 2026 it has not selected a specific signature algorithm and has not been activated on mainnet, so there is no date to plan around yet.

How often should I re-run the audit?
Set up the cron job in Step 11 to run every six hours, and review the log weekly. Any time you receive a payment to a new address, add it to your inventory file.

Can a hardware wallet alone fix this?
A hardware wallet protects your private key from theft and malware, which is valuable, but it does not change whether your public key has been revealed on-chain. Address hygiene and migration are still necessary on top of hardware security, and no current hardware wallet firmware claims to make ECDSA or Schnorr signatures quantum-resistant on its own.

Will this process work the same way for an exchange account instead of a self-custody wallet?
Not directly. If your coins sit on an exchange, the exchange controls the underlying addresses and their exposure, not you, so the audit script in this guide has nothing of yours to check. What you can still do is ask the exchange, in writing, what its own quantum-migration plan looks like, and treat a vague or nonexistent answer as a reason to move meaningful holdings into self-custody where you control the timeline.

What if I cannot find the private key for an old exposed address?
If you cannot sign a transaction from that address, you cannot migrate its funds, and they remain exposed indefinitely. This is one reason backups matter as much as the migration itself, a safer address format means nothing if you cannot produce a valid signature when you need one.