Q-Day Doesn’t Negotiate: The Migration Floor Bitcoin Can’t Ignore

INDUSTRY CONTEXT — QSHA256 is not alone in raising this concern. On April 6, 2026, Grayscale Investments — one of the world’s largest crypto asset managers — published a formal analysis identifying quantum risk as a systemic issue for the entire digital asset ecosystem, not just Bitcoin. Their research independently identifies P2PK and P2TR addresses as carrying elevated quantum exposure due to on-chain public key visibility, and recommends institutional preparation well ahead of any hardware threshold. Google set a 2029 internal migration deadline in the same period. This article uses QSHA256’s granular live UTXO data to quantify what that preparation actually requires at the engineering level.

Bitcoin currently secures 170,669,431 unspent transaction outputs (UTXOs) across seven address types, as tracked by the QSHA256 vulnerability platform. Every one of those outputs is secured by ECDSA over the secp256k1 curve — a 256-bit elliptic curve cryptosystem that Shor’s algorithm can break efficiently on a cryptographically relevant quantum computer (CRQC). Moving every UTXO to a post-quantum signature scheme is not a protocol upgrade that can be phased in gradually like SegWit or Taproot. It is a hard deadline with a hard floor.

That floor: a minimum of 69.6 days of fully dedicated block space, assuming Bitcoin stops processing all other transactions during that window and every block is used exclusively for migration transactions. At a maximum throughput of 17,020 SegWit UTXOs upgradeable per block within Bitcoin’s 4 MB block weight limit, 10,028 blocks are required at minimum. At one block every ten minutes — and that number assumes a best case that will never exist in practice.

Everything above that floor is a negotiation between migration speed and Bitcoin’s ability to function as a payment network. If 50% of block space is reserved for migration and 50% for normal transactions, the migration takes approximately 139 days. At 25% reservation, it stretches past 278 days. At 10%, you are looking at over 1.9 years — and the quantum clock does not pause while you negotiate.

Data source: QSHA256 blockchain analytics pipeline — 170,669,431 UTXOs tracked at block #947,284. All migration calculations use QSHA256 data, not third-party estimates.

The 170,669,431 UTXOs are not distributed evenly across address types. Each type carries a different vulnerability profile — some are inherently exposed (the public key is visible on-chain by design), others become vulnerable only if an address is reused. QSHA256 tracks all seven types in real time:

Address Type	UTXO Count	Total BTC Pool	At-Risk BTC	Exposure Mode	Risk
P2TR	59,231,314	148,851	199,077	Inherent	CRITICAL
P2PKH	49,878,968	5,358,619	1,198,140	Address reuse	HIGH
P2WPKH	45,895,578	6,549,423	1,815,249	Address reuse	HIGH
P2SH	14,100,000	4,167,815	1,304,488	Script reuse	HIGH
P2WSH	1,510,577	654,942	713,028	Script reuse	HIGH
P2PK	51,957	1,726,666	1,716,863	Inherent	CRITICAL
P2MS	1,037	57	57	Inherent	CRITICAL

The Grayscale chart above illustrates what this looks like historically. P2PKH dominated from 2010 through 2017, then P2SH took a growing share as multisig and wrapped SegWit became standard. P2WPKH has become the current dominant type. Throughout the entire history of the network, P2PK — Satoshi-era outputs — has sat near the bottom as a thin but enormous-value band that has never moved. The migration challenge is not just today’s snapshot. It is the accumulated product of sixteen years of address-type evolution, all of which must eventually converge on a quantum-resistant output type before a CRQC makes the question moot.

The intuitive response to a 69.6-day minimum is to ask whether partial migration is good enough — move the high-value UTXOs first, let the dust settle. This intuition is wrong, and the reason why defines the entire problem.

When a Bitcoin user spends a UTXO, they must broadcast a transaction to the mempool before it can be mined into a block. At the moment of broadcast, the user’s ECDSA public key is exposed to every node on the network. Under normal conditions this is not a vulnerability, because deriving the private key from the public key is computationally infeasible for classical computers.

It is not infeasible for a CRQC running Shor’s algorithm. A sufficiently powerful quantum computer could observe a transaction entering the mempool, recover the private key in the time between broadcast and the next mined block — approximately ten minutes — construct a competing transaction with a higher fee sending the funds to an adversary-controlled address, and have that transaction confirmed first. This is the Just-In-Time (JIT) quantum attack.

One number worth stating directly: Google’s March 2026 whitepaper estimates the probability of a successful JIT attack within a single 10-minute block window at just under 41%. This is not a certainty — a CRQC does not guarantee theft on every transaction. But a 41% chance of losing your funds on any given spend is not a risk any holder should consider acceptable, and the probability compounds with every additional block the attacker has available. The attack does not need to succeed on the first attempt to be catastrophic at scale.

It also means that long-term holders who have already exposed their public keys through prior spends face a different and more immediate risk. For reused P2PKH addresses or any P2PK output, the public key is permanently on-chain. Those UTXOs are vulnerable to offline key recovery even without the mempool attack vector. They do not need to be actively spent to be stolen once a CRQC crosses the threshold.

To understand the scale, it helps to work through the mathematics step by step. Bitcoin’s block weight limit is 4 megaweight units (MWU). A SegWit-to-post-quantum migration transaction for a single UTXO, using an optimistically sized post-quantum signature, consumes approximately 235 weight units. That gives a maximum of roughly 17,020 migration transactions per block — assuming the entire block is given over to migration and no other transactions compete for space.

The block-space throughput model used here was originally developed by Joseph Kearney in his 2024 Bitcoin Quantum Safety Calculator, working from a UTXO snapshot of 186.7 million outputs as of 2024. QSHA256 applies the same methodology to its own live-tracked UTXO count — currently 170,669,431 outputs at block #947,284 — which is why the figures here differ from Kearney’s published numbers. The underlying calculation is his; the data is ours.

QSHA256 currently tracks 170,669,431 UTXOs across all seven address types (block #947,284). With a ceiling of 17,020 upgrades per block, 10,028 blocks are required at minimum. At Bitcoin’s 10-minute block interval, that is 100,280 minutes — or 69.6 days — and that number assumes a best case that will never exist in practice.

But Bitcoin cannot stop processing transactions during migration. Commerce, settlement, and exchange activity continues. The real question becomes: what percentage of every block must be reserved for migration transactions to hit a given deadline?

Block Space Reserved for Migration	Migration Duration	Normal Transaction Capacity	Assessment
100%	69.6 days	0%	Theoretical floor — Bitcoin halts entirely
50%	~139 days	50%	5 months, severe fee pressure
25%	~278 days	75%	9 months, significant congestion
10%	~696 days	90%	Over 1.9 years — almost certainly too slow

The block space trade-off is not a technical problem that engineers will solve. It is a coordination problem that the Bitcoin governance process must solve under time pressure — and it must be solved before the answer becomes irrelevant.

The migration window might feel abstract without external anchors. The anchors are now public and well-sourced.

IonQ projects approximately 1,600 logical qubits by 2028 — but a precision note is warranted here. Shor’s algorithm for breaking ECDLP-256 requires fault-tolerant logical qubits operating under full quantum error correction, a significantly higher engineering bar than general-purpose logical qubits with partial error correction. IonQ’s projection covers the latter category; whether their error-correction architecture matures alongside the qubit count determines direct relevance to the attack threshold. IBM’s roadmap targets 100,000+ physical qubits by 2026–2027. These are real engineering commitments with track records behind them, not academic projections.

In March 2026 Google Quantum AI published a whitepaper demonstrating that ECDLP-256 — the discrete logarithm problem underlying Bitcoin’s secp256k1 curve — can be broken with fewer than 500,000 physical qubits, executable in approximately nine minutes. This is described as a 20-fold reduction from prior leading estimates — specifically Litinski’s 2023 photonic architecture analysis, which used a fundamentally different hardware model (linear optical qubits). The reduction reflects both algorithmic improvements to Shor’s circuit and a shift to a more efficient superconducting hardware model; it is not a single algorithmic breakthrough in isolation, and comparison across hardware architectures requires care. The operative result is still striking: 500,000 superconducting physical qubits, in nine minutes, for a live private key recovery.

To be direct about the current state of hardware: the best quantum computers today are orders of magnitude short of the 500,000 physical qubit threshold, and scaling to that level involves unsolved engineering challenges in error correction, qubit connectivity, and cryogenic infrastructure. The reason to act now is not that a CRQC will exist next year. It is that completing Bitcoin’s migration requires years of governance, protocol development, and user coordination — and those years must begin before the hardware arrives, not after.

Google has stated its own internal goal of completing cryptographic migration of its systems by 2029. That is a company that builds quantum computers setting its own deadline for when those computers become dangerous. If your planning horizon extends past that date without a migration strategy, you are making a bet against the team that wrote the whitepaper.

Assume the migration succeeds. Bitcoin’s ECDSA signatures are replaced with a NIST-standardized post-quantum scheme. The threat is neutralized. What does Bitcoin look like on the other side?

It looks permanently more expensive to use. Post-quantum signatures are dramatically larger than ECDSA’s 64-byte output, and the size difference is not a matter of implementation efficiency — it is fundamental to the mathematical security of the schemes.

Signature Scheme	Signature Size	Multiple vs ECDSA-256	Security Basis
ECDSA-256 (current)	64 bytes	1.0×	Elliptic curve discrete log (quantum-vulnerable)
FALCON (NIST 2024)	666 bytes	10.4×	NTRU lattice hardness
ML-DSA / CRYSTALS-Dilithium	2,420 bytes	37.8×	Module lattice hardness
SLH-DSA / SPHINCS+	7,856 bytes	122.8×	Hash-based (stateless)

Fewer transactions fit in every block, permanently. If Bitcoin adopts FALCON — the most compact of the NIST finalists — block capacity for payment transactions falls by roughly 90% relative to current SegWit throughput. If the community adopts CRYSTALS-Dilithium for conservatism reasons, the reduction is even more severe. This throughput cost does not diminish over time. It is the mathematical price of quantum resistance, and every migration plan must account for it alongside the short-term coordination challenge.

One important framing from Grayscale’s April 6, 2026 research: Bitcoin is not uniquely vulnerable. Every blockchain and L1 network that uses ECDSA or Schnorr signatures over elliptic curves faces the same underlying threat. Ethereum, Solana, Avalanche, Litecoin, Bitcoin Cash — any system whose security rests on the hardness of the elliptic curve discrete logarithm problem is in the same position as Bitcoin once a CRQC exists. The migration problem is a crypto-wide engineering challenge, not a Bitcoin-specific design flaw.

The reason Bitcoin gets specific attention is scale and governance difficulty. Bitcoin has more UTXOs than any other chain, a larger total value secured by classical cryptography, a deliberately slow and conservative governance process, and no central authority capable of mandating migration. Other chains with faster governance — notably those with on-chain upgrade mechanisms or foundation-controlled development — may be able to coordinate migration more rapidly. Bitcoin’s decentralization is both its core value proposition and its greatest migration liability.

Grayscale’s analysis also notes something that technical discussions often underemphasise: the threat is not symmetrical across address types. Their research singles out P2PK (Satoshi-era) and P2TR (Taproot) as carrying elevated quantum exposure because both output types place the public key directly on-chain — P2PK by design, P2TR when the key-path is used for spending. The Grayscale supply chart (reproduced earlier in this article) quantifies how much Bitcoin supply sits in each category. The practical implication is that not all Bitcoin holders face the same urgency: a P2PK holder with coins from 2010 is in a fundamentally different risk position than a P2WPKH holder who has never reused an address.

For institutional investors and custodians specifically, Grayscale’s recommendation is to begin exposure analysis now — mapping their UTXO holdings by address type, identifying the proportion sitting in high-exposure categories (P2PK, reused P2PKH), and modelling migration timelines against the 2029–2030 CRQC window. QSHA256’s live tracking dashboard provides this breakdown updated block-by-block. The data exists. The question is whether the governance and planning process can keep pace with the hardware.

The technical foundation for Bitcoin’s post-quantum migration exists in draft form. BIP-360 proposes P2QRH — Pay to Quantum Resistant Hash — a new native SegWit output type that supports post-quantum signature verification without breaking backward compatibility. BIP-361 defines the associated validation semantics and the QREP (Quantum Resistant Extended Public Key) format. Together, they outline a staged, soft-fork migration path that does not require a hard fork or a flag day.

The NIST 2024 Post-Quantum Cryptography standards provide the signing algorithm candidates: ML-DSA (FIPS 204), based on CRYSTALS-Dilithium; SLH-DSA (FIPS 205), based on SPHINCS+; and FALCON, whose standardization is finalized as FIPS 206. Each has different trade-offs between signature size, signing speed, key generation cost, and implementation complexity.

The governance gap is significant, however. BIP-360 and BIP-361 are still in draft. The Bitcoin developer community has not reached consensus on which post-quantum scheme to adopt. The block size implications of larger signatures have not been resolved. The question of what to do about UTXOs whose owners are unreachable — lost wallets, deceased holders, early-miner outputs — has no answer yet. Activation thresholds, migration incentives, and the mechanism for handling non-cooperative UTXOs all remain open questions requiring broad coordination across a decentralised, adversarial governance process.

None of this means the problem is unsolvable. It means the clock is already running, and the governance process has not yet started in earnest.

Let us be direct about the consequence of inaction. If migration is incomplete when a CRQC becomes operational, the JIT attack becomes live. Every Bitcoin transaction broadcast after that moment exposes its sender to immediate fund theft by any adversary with access to quantum computing at sufficient scale. The stolen funds cannot be recovered. The transaction cannot be reversed. There is no emergency patch fast enough to respond to individual thefts in real time.

For unmigrated UTXOs whose public keys are already on-chain — particularly P2PK outputs, reused P2PKH addresses, and any address that has ever signed a transaction — the threat does not even require an active broadcast. An adversary with a CRQC can scan the blockchain, identify every exposed public key, recover the corresponding private key, and drain the funds without the owner doing anything. This is not a theoretical possibility reserved for nation-state actors. It is a mechanical consequence of what Shor’s algorithm does.

The current tracked exposure on the QSHA256 platform stands at 6,946,902 BTC across seven address types, updated block-by-block. This is not a projection. It is a live measurement of funds that are vulnerable today to an adversary with sufficient quantum capability — and the number grows every time a user reuses an address or moves funds without migrating.

Every analysis of the migration challenge eventually runs into the same wall: nobody can make UTXOs move. There is no central authority, no emergency lever, no consensus mechanism that can reach into a wallet and compel a signature. The migration must be voluntary, which means some UTXOs will not migrate — and the consequences of that are not abstract.

Satoshi’s coins. The most discussed category is also the most politically charged. Blockchain forensics — particularly the Patoshi pattern analysis by Sergio Demian Lerner — identifies approximately 1.1 million BTC held across roughly 22,000 early mining blocks attributed to Bitcoin’s pseudonymous creator. Every one of these outputs is in the P2PK format (Pay to Public Key), the earliest Bitcoin output type, in which the full public key is written directly into the scriptPubKey. These keys have been on-chain, permanently and publicly, since 2009 and 2010. They have never been spent.

Under a CRQC, this is not a locked vault. It is an open safe. An adversary with sufficient quantum capability does not need Satoshi’s cooperation, does not need to break encryption, and does not need to wait for any transaction to occur. They can read the public key from the blockchain, run Shor’s algorithm, derive the private key, and broadcast a spending transaction. If the migration is incomplete when a CRQC becomes operational, those 1.1 million BTC are not dormant — they are a target. At any price level where Bitcoin is meaningful, this is one of the single largest addressable theft targets in history, reachable by any actor who gets to CRQC capability first.

Permanently lost coins. Beyond Satoshi, there is a large population of UTXOs whose private keys are simply gone. Hardware failures, lost seed phrases, dead holders, and early-era wallets with no backups account for an estimated 3–4 million BTC that have not moved in over a decade and almost certainly never will. These coins present a different problem: they cannot migrate because there is no one alive who can sign the migration transaction. A CRQC makes these coins spendable again — not by their original owners, but by whoever controls the CRQC first.

Long-term holders and unreachable owners. The next layer is UTXOs belonging to holders who are alive but unreachable, disengaged, or unwilling to act in time. Wallets from 2011–2014 held in cold storage with no active monitoring, exchange accounts whose owners have lost credentials, and paper wallets stored in physical locations without digital infrastructure for recovery all fall into this category. The migration requires each holder to generate a new address, sign a migration transaction, and broadcast it — none of which happens automatically, and all of which require the holder to be both reachable and motivated before the deadline.

Category	Estimated BTC	Quantum Exposure	Migration Realistic?
Satoshi / Patoshi pattern (P2PK)	~1.1M BTC	Public key on-chain since 2009–2010	No owner reachable
Permanently lost wallets	~3–4M BTC (est.)	Mix of P2PK, P2PKH, P2WPKH	No — keys destroyed or inaccessible
Early miner outputs (other P2PK)	~500K–1M BTC (est.)	Public key permanently exposed	Partial — some owners reachable
Dormant long-term holders (>5 years)	Unknown	Depends on address reuse and type	Uncertain — requires active outreach
Active holders (recent spend activity)	Majority of circulating supply	Lower — private keys not on-chain	Yes — if protocol and wallets support it

The governance dilemma: protect or burn? The Bitcoin community will eventually have to confront a question with no comfortable answer. If a migration deadline is set — a block height after which unmigrated P2PK outputs are considered unspendable by consensus — that is effectively confiscating or burning coins belonging to people who either cannot or will not act. That includes Satoshi’s coins. Doing this by consensus requires a supermajority of the Bitcoin network to agree to invalidate existing outputs — a governance precedent that many in the community consider incompatible with Bitcoin’s property guarantees.

If no deadline is set, those outputs remain spendable by anyone who acquires the corresponding private key through any means, including CRQC-enabled key recovery. The coins do not disappear. They transfer to whoever moves fastest.

Neither outcome is clean. The stranded coins problem is not a technical issue that engineers can patch around. It is a values question about what Bitcoin’s property guarantees actually mean under conditions that did not exist when they were made — and it requires broad consensus before the hardware that makes it urgent exists, because after that point, the debate is moot.

The migration challenge exists at every level, and the actions available to you depend on who you are.

If you hold Bitcoin individually: Stop address reuse immediately. If your public key has ever been exposed on-chain through a prior spend from an address, move those funds to a fresh address now. This is a free action that requires no protocol change, no wallet upgrade, and no technical expertise beyond knowing how to generate a new address. It closes the pre-exposed public key vulnerability. It does not protect against the JIT attack once a CRQC exists, but it eliminates the trivially exploitable case today.

If you are a Bitcoin developer: Engage with BIP-360 and BIP-361. Read them, test them, critique them, improve them. The migration framework needs technical consensus urgently. The block size trade-offs need rigorous modelling. The validation semantics need implementation review. This is the work, and it needs people doing it now.

If you are an institution or exchange: Begin internal post-quantum migration planning aligned with Google’s 2029 target. Model your UTXO exposure by address type. Custodians holding funds in P2PK or reused P2PKH addresses face the highest structural risk and should prioritize those first. Audit your key management infrastructure for post-quantum readiness. NIST standards are finalized — there is no technical reason to wait for Bitcoin protocol consensus before auditing internal exposure.

For everyone: Understand that inaction is itself a choice — and the migration window narrows with every block mined. The mathematics does not care about governance timelines, development preferences, or market conditions. The 69.6-day floor is derived from 170,669,431 real, tracked UTXOs. The CRQC timeline is shortening. The distance between those two numbers is the entire margin for error Bitcoin has.

The most important thing to understand about Bitcoin’s quantum migration problem is that it is not a problem being solved by someone else on your behalf. There is no central authority that can mandate migration, absorb losses, or guarantee continuity of holdings. The decentralization that makes Bitcoin valuable is the same property that makes coordinating a mandatory network-wide cryptographic upgrade extraordinarily difficult. The urgency is real, the mathematics is settled, and the governance clock is ticking. What happens next depends on whether enough people understand the stakes clearly enough to act before the deadline becomes the outcome.

Live UTXO exposure data: Quantum Vulnerability Agent · ECDSA vs SHA-256 threat comparison: Bitcoin Risk · Post-quantum signature sizes: Size Matters · BIP-360 technical deep-dive: Bitcoin’s Post-Quantum Migration Path · Google’s March 2026 disclosure: Google Just Moved Q-Day

• [1] QSHA256 Vulnerability Platform. UTXO exposure data: 170,669,431 UTXOs across 7 address types, block #947,284. Derived from mempool.space UTXO set data and live QSHA256 agent scanning. qsha256.com/quantum-agent

• [2] QSHA256 Vulnerability Agent. Address-type breakdown: P2TR, P2PKH, P2WPKH, P2SH, P2WSH, P2PK, P2MS exposure and at-risk BTC. Live data dashboard

• [3] Babbush, R. & Neven, H. (2026). Safeguarding cryptocurrency by disclosing quantum vulnerabilities responsibly. Google Quantum AI. Whitepaper PDF

• [4] Google. (2026). Our 2029 timeline for completing our cryptography migration. blog.google

• [5] IonQ. (2025). IonQ Roadmap: CRQC targets and logical qubit projections. ionq.com

• [6] NIST. (2024). Post-Quantum Cryptography Standards: ML-DSA (FIPS 204), SLH-DSA (FIPS 205), FALCON (FIPS 206). csrc.nist.gov

• [7] Bitcoin BIP-360 (P2QRH). github.com/cryptoquick/bips

• [8] Shor, P. W. (1994). Algorithms for quantum computation: discrete logarithms and factoring. FOCS 1994.

• [9] Kearney, J. (2024). Bitcoin Quantum Safety Calculator — block-space throughput model for UTXO migration under post-quantum signature schemes. Based on a 2024 UTXO snapshot of 186.7M outputs. josephkearney.co.uk/bitcoin-quantum-safety

• [10] Grayscale Investments. (April 6, 2026). It’s Time to Get Ready for a Post-Quantum Future. Grayscale Research. Bitcoin supply by address type chart sourced from Glassnode; data as of March 5, 2026 (chart data date). Identifies P2PK and P2TR as highest-exposure address types due to on-chain public key visibility. Recommends institutional exposure analysis and migration planning aligned with the 2029–2030 CRQC window. grayscale.com