On August 15, 2026, Fortune put a number on a fear that crypto holders had mostly waved off for years: more than $2 trillion in digital assets, nearly the entire value of the crypto market, sits exposed to a future quantum computer that can break the math behind Bitcoin’s signatures. Google has floated 2029 as the target date for cryptocurrency systems to finish migrating away from that math. Galaxy Digital says roughly 7 million BTC, worth about $470 billion when it published the estimate in March 2026, already sit in addresses with a public key visible on-chain, the exact condition a quantum attacker would need. None of this means your coins vanish tomorrow. It does mean the migration window just got a deadline, and waiting for “someday” is no longer a plan. This tutorial walks you through checking your own exposure, moving funds off risky addresses, and setting up ongoing monitoring, using free tools and about 45 minutes.

Why This Matters in August 2026, Not Just in Theory

Bitcoin secures ownership with elliptic curve digital signatures (ECDSA) on the secp256k1 curve. A large enough quantum computer running Shor’s algorithm could, in principle, derive a private key from a public key. Bitcoin’s other pillar, SHA-256 hashing, is not in the same danger: Grover’s algorithm only gives a quadratic speedup against hash functions, so a 256-bit hash still holds roughly 128 bits of effective security even against a quantum adversary. The Motley Fool made exactly this distinction in its August 2, 2026 coverage of Galaxy Digital’s research, noting Bitcoin’s ledger and mining rely on SHA-256, which quantum computers cannot efficiently break. The real pressure point is ECDSA, and specifically any address that has already revealed its public key on-chain.

Two data points explain why the clock suddenly feels shorter. Google Quantum AI published a paper in March 2026 estimating that breaking Bitcoin’s elliptic curve cryptography could take fewer than 500,000 physical qubits, a roughly 20x reduction from prior estimates, according to reporting from Forbes. And on August 12, 2026, Stanford cryptographer Dan Boneh pushed back on the panic in comments covered by CryptoRank, saying today’s quantum machines are “far too small and error-prone” to threaten Bitcoin, and that a fault-tolerant machine capable of the job is likely still a decade away. Boneh’s more useful point for this tutorial: NIST finalized its post-quantum algorithms in 2024, so Bitcoin already has concrete cryptographic primitives to adopt once a migration path is agreed on, most likely through a soft fork to post-quantum addresses.

Prerequisites: What You Need Before You Start

You do not need to be a cryptographer to run this migration. You need a working terminal, some patience with transaction fees, and the following:

  • Python 3.11 or newer, with pip available
  • The requests library (2.32 or newer)
  • A list of the Bitcoin addresses you control, pulled from your wallet’s transaction history or xpub
  • A wallet you can send from: a hardware wallet such as a Coldcard Mk4/Q, Trezor Safe 5, or Ledger Flex, or a Bitcoin Core 29.0 node with a descriptor wallet
  • Free access to the mempool.space public API (no signup or key required)
  • A rough sense of current network fees, since consolidating UTXOs costs sats
  • 45 to 60 minutes, plus a follow-up session once your migration transactions confirm

If you manage funds for a team or hold coins across multiple wallets, budget extra time for step 7. Consolidating dozens of exposed UTXOs into a handful of fresh addresses is the slowest part of this process, not the scripting.

Step 1: Understand How Quantum Computers Actually Threaten ECDSA

Every Bitcoin address is derived from a public key, which is itself derived from a private key you control. Under normal circumstances, nobody sees your public key until you spend from an address, because the address itself is a hash of the public key, not the key. Once you broadcast a transaction, the scriptSig (for legacy P2PKH addresses) or the witness data (for SegWit P2WPKH addresses) includes the raw public key so the network can verify your signature. From that moment on, the public key is permanently recorded on the blockchain.

Shor’s algorithm, run on a large enough fault-tolerant quantum computer, can solve the elliptic curve discrete logarithm problem and recover a private key from a public key in a feasible amount of time. That’s the scenario Google’s March 2026 paper made suddenly less remote by cutting the qubit estimate 20-fold. It’s also why Taproot addresses (bc1p…) carry a slightly different nuance: because Taproot’s output key is itself a tweaked public key, some argue exposure begins at address creation rather than at first spend. For this tutorial, treat any address that has sent a transaction as exposed, and treat Taproot addresses as exposed by default until the community reaches consensus on that distinction.

It helps to separate two different quantum algorithms people often lump together. Shor’s algorithm targets the mathematical structure behind public-key cryptography, ECDSA included, and offers an exponential speedup that could eventually make key recovery practical. Grover’s algorithm, by contrast, targets brute-force search problems like reversing a hash function, and only offers a quadratic speedup, meaning it doubles the effective attack cost reduction rather than collapsing it entirely. That gap is the whole reason this tutorial focuses on signatures and addresses rather than on mining or block hashes.

Bitcoin Address Types and Why Some Are More Exposed Than Others

Not every Bitcoin address behaves the same way under this threat model, and knowing the difference changes how urgently you should treat each one. Legacy P2PKH addresses (the ones starting with “1”) and SegWit P2WPKH addresses (“bc1q…”) both hide the public key behind a hash until you spend from them. Once spent, the key is exposed for good, even if the address never receives funds again. Taproot addresses (“bc1p…”) work differently: the output itself is built from a tweaked public key, so some researchers argue the exposure clock starts at receipt rather than at spend. That distinction hasn’t been fully settled in the community, which is why this tutorial treats Taproot addresses as exposed by default rather than waiting for consensus.

Then there’s the oldest category: pay-to-pubkey (P2PK) outputs, used in Bitcoin’s earliest years before P2PKH became standard. A P2PK output places the raw public key directly in the transaction script, with no hash layer in between. Coins sitting in P2PK outputs have never hidden their public key at all, which is part of why early, dormant Bitcoin holdings get singled out so often in quantum-risk discussions. If your wallet holds coins that trace back to Bitcoin’s first few years, run the exposure checker on them first.

Step 2: Identify Which of Your Addresses Have Exposed Public Keys

This is the step most guides skip, and it’s the one that actually matters. An address that has only ever received funds, and never sent any, has not revealed its public key. Only the hash is public. An address that has sent at least one outgoing transaction has revealed its public key permanently. Galaxy Digital’s March 2026 research pegged the scale of this problem at roughly 7 million BTC sitting in addresses with an exposed public key, worth about $470 billion at the time of the estimate, largely from reused legacy addresses and coins that moved at some point in Bitcoin’s history.

Checking this by hand, address by address, on a block explorer works for a handful of addresses but breaks down fast if you hold more than a dozen. That’s what the script in the next step automates. If you’ve used the same wallet for years, expect the manual approach to take longer than the scripted one by an order of magnitude, especially once you factor in change addresses your wallet generated automatically and never showed you directly.

Step 3: Install the Exposure-Checker Script

Install the one dependency you need, then save the script below as exposure_checker.py. It queries the free mempool.space API for each address you give it and reports whether that address has ever sent a transaction, which is the signal for public key exposure.

pip install requests==2.32.3
import requests
import json
import sys
import time

MEMPOOL_API = "https://mempool.space/api/address/"

def check_address(address):
    url = f"{MEMPOOL_API}{address}"
    resp = requests.get(url, timeout=10)
    resp.raise_for_status()
    data = resp.json()
    chain_stats = data.get("chain_stats", {})
    spent = chain_stats.get("spent_txo_count", 0)
    funded = chain_stats.get("funded_txo_count", 0)
    balance_sats = chain_stats.get("funded_txo_sum", 0) - chain_stats.get("spent_txo_sum", 0)
    return {
        "address": address,
        "exposed_pubkey": spent > 0,
        "outgoing_tx_count": spent,
        "incoming_tx_count": funded,
        "balance_sats": balance_sats,
    }

def scan_wallet(addresses):
    report = []
    for addr in addresses:
        try:
            report.append(check_address(addr))
        except requests.RequestException as e:
            report.append({"address": addr, "error": str(e)})
        time.sleep(0.3)
    return report

if __name__ == "__main__":
    with open(sys.argv[1]) as f:
        addresses = [line.strip() for line in f if line.strip()]
    results = scan_wallet(addresses)
    exposed = sum(1 for r in results if r.get("exposed_pubkey"))
    print(json.dumps(results, indent=2))
    print(f"\n{exposed} of {len(results)} addresses have exposed public keys", file=sys.stderr)

The 0.3-second delay between requests keeps you well under mempool.space’s public rate limits. If you’re scanning hundreds of addresses, raise that delay or run your own node with the mempool.space backend to avoid throttling.

Step 4: Run a Full Wallet Exposure Scan

Create a plain text file named wallet_addresses.txt, one address per line, pulled from your wallet’s receive history or exported from your xpub. Then run the script:

python3 exposure_checker.py wallet_addresses.txt > report.json

Here’s what the output looks like on a small test wallet with 12 addresses:

[
  {
    "address": "bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq",
    "exposed_pubkey": true,
    "outgoing_tx_count": 3,
    "incoming_tx_count": 5,
    "balance_sats": 1240000
  },
  {
    "address": "bc1q9d9dt3xh6mzlt3v0z8t5ne5wxg9zj4h8trh0lm",
    "exposed_pubkey": false,
    "outgoing_tx_count": 0,
    "incoming_tx_count": 1,
    "balance_sats": 500000
  }
]

3 of 12 addresses have exposed public keys

The stderr line at the bottom is your headline number. That’s the count you act on first.

Step 5: Read and Prioritize Your Exposure Report

Not every exposed address deserves the same urgency. Sort your report by balance, then bucket each address into a risk tier. This table is the one I hand to anyone who asks where to start:

Risk TierConditionBalance ThresholdAction Priority
CriticalExposed pubkey + high balanceOver 0.5 BTCMigrate this week
HighExposed pubkey + moderate balance0.05-0.5 BTCMigrate this month
ModerateExposed pubkey + small balanceUnder 0.05 BTCBatch with next consolidation
LowNever spent, pubkey hiddenAnyMonitor only, no action needed
WatchTaproot address, any historyAnyTrack BIP-360/361 guidance

If your critical and high tiers together hold more than half your net worth in one exposed address, stop reading and go straight to step 7. The rest of this tutorial will still be here. If your report comes back mostly in the “Low” tier, don’t skip the rest of the migration entirely. Set a monitoring cadence from step 11 anyway, since a coin you receive today and forget about could easily be spent from years from now, well after this news cycle fades and the sense of urgency with it.

Step 6: Generate Fresh, Unexposed Receiving Addresses

A brand-new address that has never received or sent a transaction has no exposed public key. That’s your migration target. If you’re running Bitcoin Core 29.0 with a descriptor wallet, generate one like this:

bitcoin-cli -named createwallet wallet_name="quantum-migration" descriptors=true
bitcoin-cli -rpcwallet=quantum-migration getnewaddress "" "bech32"
bitcoin-cli -rpcwallet=quantum-migration listdescriptors

On a hardware wallet, use the device’s native “receive” flow and confirm the address on the device screen rather than trusting the companion app. The principle that matters here: generate one fresh address per deposit rather than reusing a single address for every migrated batch. Reuse is what created this problem in the first place, and it’s a habit plenty of long-time Bitcoin holders picked up back when block explorers made a single, easy-to-bookmark address feel convenient.

Step 7: Migrate Funds Off High-Risk Addresses

Send from each critical and high tier address to a fresh address you generated in step 6. A few practical notes from doing this across real wallets:

  • Batch small UTXOs together in one transaction to save on fees, but don’t mix a critical-tier UTXO with unrelated coins if you care about avoiding chain analysis linking them
  • Check current fee rates before broadcasting. Consolidating dozens of small UTXOs during a fee spike can cost more than the UTXOs are worth
  • Wait for at least one confirmation before considering an address “migrated” in your tracking sheet
  • The moment you spend from the new address again, it becomes exposed too, so this isn’t a one-time fix, it’s a habit

That last point trips people up constantly. Migrating to a fresh address protects the coins sitting still. It does nothing to change how Bitcoin’s address scheme works. You’ve bought time, not immunity.

Worth flagging for anyone new to on-chain privacy: moving funds also creates a visible link between your old, exposed address and your new one, since both appear in the same transaction. If chain analysis resistance matters to you as much as quantum exposure does, look into coin selection tools that avoid linking unrelated UTXOs in a single migration transaction, or space out your migrations over several days instead of moving everything at once.

Step 8: Update Wallet Firmware and Node Software

Firmware and node updates won’t add post-quantum signatures overnight, since that requires a coordinated protocol change, but outdated software is the more immediate risk in any migration. Before you move funds, confirm you’re running current releases: Coldcard firmware in the 6.x line, Trezor Suite’s latest desktop build, Ledger Live with up-to-date firmware on a Flex or Stax device, or Bitcoin Core 29.0 if you’re running a full node wallet. Check each vendor’s official release notes directly rather than trusting a link from a forum post, since fake “urgent quantum patch” downloads are exactly the kind of scam this news cycle invites.

This step matters more than it sounds like it should. A migration transaction is exactly the moment you’re most likely to interact with your hardware wallet’s screen, approve an address, and sign something, and that’s also the moment a compromised companion app or an outdated firmware build with a known bug can do the most damage. Treat the firmware check as a prerequisite for step 7, not an optional detour.

Step 9: Add Multisig as an Interim Hedge

A 2-of-3 multisig setup doesn’t make your keys quantum-resistant, but it does mean an attacker needs to compromise two separate exposed public keys and craft two valid signatures instead of one, which meaningfully raises the bar and the cost. Tools like Sparrow Wallet or Specter Desktop can build a descriptor-based multisig wallet across two hardware devices and one backup key. A rough command-line equivalent using Bitcoin Core:

bitcoin-cli createmultisig 2 '["03a1e5...","03b2f6...","03c3a7..."]' bech32
bitcoin-cli -rpcwallet=quantum-migration importdescriptors \
  '[{"desc":"wsh(multi(2,[fingerprint/48h/0h/0h/2h]xpub.../0/*,...))","active":true,"timestamp":"now"}]'

Treat this as a bridge strategy, not a destination. It buys defense in depth while the protocol-level fix works through the standards process. Keep in mind that every public key in a multisig setup is still individually exposed once any co-signer spends, so the protection comes from the attacker needing to break multiple keys and produce multiple valid signatures within the same transaction, not from any single key becoming harder to break on its own. For large holdings shared across a family or a company, a 3-of-5 setup spreads that requirement even further, at the cost of more coordination overhead when you actually need to sign something.

Step 10: Track BIP-360, BIP-361 and Post-Quantum Address Proposals

The real fix has to happen at the protocol layer, and it’s already being drafted. Coverage from CryptoRank in early August 2026 described BIP-361 as putting Bitcoin on a five-year coordination clock: roughly three years after activation, the network would stop allowing new quantum-vulnerable outputs, with stricter verification of legacy ECDSA and Schnorr spending paths tightening around year five. A related proposal, BIP-360, defines a new pay-to-quantum-resistant-hash output type built on NIST’s finalized algorithms. You can track both proposals directly in the official Bitcoin Improvement Proposals repository rather than relying on secondhand summaries.

Bitcoin isn’t the only chain moving. On August 14, 2026, a post-quantum-safe proof verifier went live on the Bitcoin Cash chipnet test network, a 9,930-byte on-chain program built to check mathematical proofs under a post-quantum-safe scheme, according to a report on TradingView. It’s an early proof of concept rather than a production deployment, but it shows the migration path from theory to working code is already underway across Bitcoin-derived chains.

Where NIST’s Post-Quantum Algorithms Fit Into Bitcoin’s Future

Any protocol-level fix for Bitcoin has to pick from the algorithm families NIST already standardized. In 2024, NIST finalized three post-quantum standards under formal FIPS numbers, and each one solves a different piece of the puzzle. Understanding which one actually matters for a Bitcoin address helps cut through vague “quantum-safe” marketing you’ll see attached to unrelated altcoins.

AlgorithmNIST StandardTypeRelevance to Bitcoin
ML-DSA (Dilithium)FIPS 204Digital signatureLeading candidate for signing transactions in a post-quantum output type
SLH-DSA (SPHINCS+)FIPS 205Hash-based signatureLarger signatures but relies only on hash-function security, a more conservative fallback
ML-KEM (Kyber)FIPS 203Key encapsulationBuilt for encrypting network traffic, less relevant to how a wallet signs a spend

Signature size is the practical constraint that will shape whatever Bitcoin ships. ECDSA signatures on secp256k1 run around 64-72 bytes. Post-quantum signature schemes run considerably larger, which is exactly why BIP-360’s pay-to-quantum-resistant-hash design and the broader debate over which algorithm to standardize on remain unsettled. Our deeper technical breakdown of how ML-KEM and ML-DSA compare on key and signature size covers the tradeoffs in more depth than fits here, but the short version for Bitcoin holders is this: whichever algorithm wins, transactions from post-quantum addresses will take up more block space than today’s transactions do, and fees for that output type will likely run higher until the network adapts.

Step 11: Automate Ongoing Exposure Monitoring

Run the exposure checker on a schedule so new exposure doesn’t sneak up on you between now and whenever a protocol-level fix ships. A weekly cron job that diffs this week’s report against last week’s and flags you when something changes is enough for most personal wallets:

#!/bin/bash
# quantum-monitor.sh - re-run the exposure scan weekly and flag changes
cd /home/user/quantum-check
python3 exposure_checker.py wallet_addresses.txt > "reports/$(date +%F).json"
diff "reports/last-week.json" "reports/$(date +%F).json" > /tmp/exposure_diff.txt
if [ -s /tmp/exposure_diff.txt ]; then
  mail -s "Bitcoin exposure report changed" [email protected] < /tmp/exposure_diff.txt
fi
cp "reports/$(date +%F).json" reports/last-week.json
0 9 * * 1 /home/user/quantum-check/quantum-monitor.sh

That crontab entry runs the check every Monday at 9am. Adjust the schedule to match how actively you transact. A wallet that never moves needs a monthly check at most, while an active trading wallet benefits from running the scan after every batch of transactions.

Step 12: Document Your Migration Plan and Set Review Dates

Write down what you did, when, and why, even if it's just a plain text file next to your seed phrase backup (in a separate secure location, never the same one). Include the date of your last exposure scan, your current risk tier breakdown, and a calendar reminder tied to Google's proposed 2029 migration target. Set at least one review checkpoint per year between now and then. Protocol proposals like BIP-360 and BIP-361 will change as they move through review, and your plan needs to track them, not freeze at today's draft language.

If you hold Bitcoin as part of an estate plan, add this migration plan to whatever documentation your heirs or executor would need. A quantum-exposure checklist means nothing to someone who inherits your seed phrase without context on which addresses were already migrated and which still need attention. Treat this document the same way you'd treat any other piece of critical financial paperwork, reviewed on a schedule and stored somewhere your family can actually find it.

Common Pitfalls When Quantum-Proofing a Bitcoin Wallet

  • Treating address reuse as a one-time fix. Every time you spend from an address, even a "fresh" one, it becomes exposed. Migration is a habit, not an event.
  • Panic-selling based on headlines alone. Boneh's assessment that fault-tolerant quantum machines are roughly a decade out matters as much as the alarming dollar figures in the same news cycle.
  • Falling for fake "quantum patch" firmware. No hardware wallet vendor has shipped a quantum-signature firmware update as of August 2026. Anything claiming otherwise is a scam.
  • Ignoring change addresses. Wallets often generate hidden change addresses that also get spent from and exposed. Scan your full derivation path, not just addresses you remember.
  • Consolidating everything into one giant transaction. A single high-value transaction during a migration draws more chain-analysis attention than several smaller, spaced-out transfers.
  • Skipping exchange-held balances. If your coins sit on an exchange, this tutorial's script can't see them, and your exposure depends entirely on the exchange's own custody practices.
  • Forgetting old, imported private keys. Addresses imported from an old paper wallet or an early software wallet often carry a spend history you've forgotten about, which means an exposed public key you're not tracking. Pull your full transaction history, not just the addresses currently visible in your active wallet app.

Troubleshooting Your Exposure Scan and Migration

  • Script returns a 429 error: You're hitting mempool.space's rate limit. Increase the time.sleep() delay to 1 second or run your own mempool.space instance.
  • "chain_stats" key missing from the response: You likely passed a malformed or testnet address to a mainnet API endpoint. Double-check the address prefix.
  • All addresses show as exposed, including ones you never spent from: Check whether you accidentally exported change addresses your wallet already used internally without your direct action.
  • Migration transaction stuck unconfirmed for hours: Fee rate was too low for current network conditions. Use replace-by-fee (RBF) if you enabled it, or wait out the mempool backlog.
  • Hardware wallet won't display the new address for confirmation: Update the companion app first. A version mismatch between firmware and desktop software is the most common cause.
  • bitcoin-cli commands return "wallet not found": You need to create or load the descriptor wallet first with createwallet or loadwallet before running address commands against it.
  • Multisig descriptor import fails silently: Verify every xpub fingerprint and derivation path matches exactly. One mismatched character breaks the whole descriptor.
  • Cron job never runs: Confirm the script has execute permission (chmod +x quantum-monitor.sh) and that the cron daemon has access to your Python environment's PATH.
  • Report shows a balance that doesn't match your wallet app: Your wallet may be displaying a total across change addresses the exposure checker treated as separate entries. Cross-reference the sum of all addresses in your report against your wallet's total before assuming something's wrong with the script.

How the Wider Crypto Market Is Reacting

Bitcoin gets most of the attention in this story because it's the largest single pool of value sitting on vulnerable signature math, but Fortune's August 15, 2026 reporting framed the $2 trillion figure as covering nearly the entire crypto market, not Bitcoin alone. Ethereum and most other major chains rely on similar elliptic curve signature schemes, so the same underlying math problem applies across the board. What differs chain to chain is governance speed. Bitcoin's conservative, consensus-driven upgrade process, the same one behind the multi-year BIP-360 and BIP-361 timelines, tends to move slower than smaller chains willing to hard fork more aggressively.

Institutional money is already responding. Galaxy Digital's $5 million pledge toward Bitcoin quantum-resistance research, announced alongside its August 2, 2026 exposure estimate, is one of the first concrete signs that firms managing large Bitcoin positions are treating this as a funding priority rather than a distant hypothetical. Public commentary has amplified the story too. The Quantum Insider examined how IBM's own quantum computing roadmap fed into market anxiety after CNBC's Jim Cramer said in early August 2026 that he planned to sell his Bitcoin over quantum concerns. Expect more custodians and exchanges to publish their own exposure audits over the next year, following the same public-key-exposure methodology this tutorial's script uses on a smaller scale.

Advanced Tips for Long-Term Quantum Resilience

Once the basics are done, a few deeper moves are worth the extra effort. Run your own mempool.space or Esplora backend against your own Bitcoin Core node so exposure scans never touch a third-party API, which also removes any privacy leak from repeatedly querying a public service with your real addresses. Consider timelocked or CSV-based spending conditions for large, rarely-touched holdings, since they add friction against any attacker, quantum or otherwise. If you're technical enough to follow the BIP process directly, subscribe to the bitcoin-dev mailing list rather than secondhand summaries, because migration guidance will get more specific as BIP-360 and BIP-361 move through review. And resist the urge to move everything into a single exotic "quantum-safe" altcoin marketed around this news cycle. None of them have the security track record, liquidity, or miner support Bitcoin has, and most post-quantum blockchain claims as of August 2026 remain unaudited.

Consider building a simple dashboard on top of the exposure checker rather than reading raw JSON every week. A small script that plots your exposed-versus-unexposed balance ratio over time turns a one-off scan into something you can glance at in five seconds. If you manage keys for a business or a DAO treasury, extend the script to pull addresses directly from your multisig coordinator's watch-only wallet instead of maintaining a separate text file, so the report always reflects your actual current holdings rather than a snapshot you forgot to update.

One more habit worth building: whenever you set up a new wallet, hardware device, or exchange account going forward, ask what the provider's actual post-quantum roadmap looks like, not just whether they've published a blog post using the words "quantum-safe." A real answer references specific NIST algorithms, a specific target output type like BIP-360's proposal, and a specific testing timeline. A vague answer is marketing.

Post-Quantum Bitcoin Timeline: 2024 Through 2029

DateEventSource
2024NIST finalizes its post-quantum cryptography algorithm standardsNIST
March 2026Google Quantum AI estimates under 500,000 physical qubits needed to break Bitcoin's ECDSA, a 20x cut from earlier estimatesBitcoin.com
March 2026Galaxy Digital estimates ~7 million BTC (~$470B) sit in addresses with exposed public keysForbes
August 2, 2026Galaxy Digital pledges $5 million toward Bitcoin quantum-resistance researchThe Motley Fool
Early August 2026BIP-361 draft proposes a five-year quantum migration clock for BitcoinCryptoRank
August 12, 2026Stanford's Dan Boneh says fault-tolerant quantum machines are roughly a decade awayCryptoRank
August 14, 2026Post-quantum-safe proof verifier goes live on Bitcoin Cash chipnetTradingView
August 15, 2026Fortune reports $2 trillion in digital assets at risk industry-wide, Google proposes 2029 migration targetFortune
2029Proposed target date for cryptocurrency systems to complete migration away from quantum-vulnerable cryptographyFortune / Google

Frequently Asked Questions

Can a quantum computer break Bitcoin today?

No. Dan Boneh's August 12, 2026 assessment is blunt on this point: current quantum machines are too small and too error-prone, and a fault-tolerant machine capable of the job is likely at least a decade away. The 2029 date circulating is a proposed migration deadline, not a prediction of when an attack becomes possible.

Does a brand-new, never-used Bitcoin address protect me?

Yes, as long as you never spend from it. An address that has only received funds has revealed only a hash of its public key, not the key itself. The moment you send a transaction from it, the public key becomes permanently visible on-chain.

What's the difference between BIP-360 and BIP-361?

BIP-360 defines a new pay-to-quantum-resistant-hash output type built on NIST-standardized post-quantum algorithms. BIP-361, per CryptoRank's early August 2026 coverage, lays out the coordination timeline: roughly three years after activation to stop new quantum-vulnerable outputs, tightening further around year five. Both are drafts moving through the standard Bitcoin Improvement Proposal review process.

Should I move my Bitcoin off exchanges because of quantum risk?

Exchange custody risk and quantum risk are separate questions. This tutorial's exposure checker can't see exchange-held balances at all, since you don't control the underlying addresses. If you're already considering self-custody for other reasons, quantum exposure is one more argument for it, not the deciding one on its own. What you can do is ask your exchange directly whether they've published an exposure audit of their own hot and cold wallet addresses, and whether their post-quantum migration plan covers customer funds specifically or just their own corporate treasury.

Is SHA-256 mining also at risk from quantum computers?

Not in the same way. Grover's algorithm only offers a quadratic speedup against hash functions like SHA-256, which still leaves roughly 128 bits of effective security even against a quantum adversary. The urgent exposure is in ECDSA signatures, not in the proof-of-work hash.

Do any hardware wallets support post-quantum signatures yet?

No mainstream hardware wallet vendor had shipped post-quantum signature support as of August 2026. Support will follow whichever address format Bitcoin's protocol settles on through the BIP-360/361 process, not the other way around. Treat any product claiming otherwise with suspicion.

Will multisig actually stop a quantum attack?

Not on its own. Multisig raises the cost and complexity for an attacker, since they'd need to compromise multiple exposed public keys and forge multiple valid signatures instead of one, but it doesn't change the underlying cryptography. Treat it as a hedge that buys time, not a permanent fix.

What should I actually do this week?

Run the exposure scan from step 4, identify your critical and high tier addresses from step 5, and migrate the largest ones first. That's the highest-value hour you can spend on this before worrying about protocol timelines or multisig setups.

How much will migrating to a fresh address cost in fees?

It depends entirely on network conditions and how many UTXOs you're consolidating. A single input, single output transaction typically costs less than a dollar during normal fee conditions, while consolidating dozens of small UTXOs during a busy mempool period can cost meaningfully more. Check current fee estimates before broadcasting, and avoid migrating during a known high-traffic period like a major ordinals or inscription mint if you can wait a day or two.