Google’s Quantum Advance Exposes Bitcoin’s Hidden Upgrade Cost

Coinmama
Coinmama



All news is rigorously fact-checked and reviewed by leading blockchain experts and seasoned industry insiders.
  • Google’s Willow chip achieved a 40-fold reduction in magic-state preparation errors, but retained only 8% of attempts.
  • An illustrative ML-DSA-44 signature and public key require 3,732 bytes, compared with today’s 64-byte Schnorr signature.
  • Under current SegWit weight rules, that replacement could add 917 virtual bytes per spend before encoding overhead.
  • Protecting older Bitcoin outputs raises difficult questions about consensus, dormant coins and the rights of existing holders.

The hardest part of protecting Bitcoin from quantum computers may not be finding a secure replacement for its signatures. It may be fitting that replacement into a blockchain where every byte competes for limited capacity.

A standard Taproot key-path signature occupies 64 bytes. An illustrative replacement using NIST’s ML-DSA-44 would require a 2,420-byte signature and potentially another 1,312 bytes to reveal the public key. Combined, that is 3,732 bytes of cryptographic data, roughly 58 times the original signature payload.

Google’s latest quantum computing breakthrough makes this trade-off more relevant. On October 15, the company reported that its Willow processor had reduced errors in a specialized quantum operation by approximately 40 times, achieving 99.99% fidelity through a technique called magic state cultivation.

The experiment, published in Science, advances a component needed for fault-tolerant quantum computing. It does not demonstrate an attack against Bitcoin, but Google’s separate research has estimated that secp256k1 elliptic-curve cryptography could eventually be broken using fewer than 500,000 physical qubits under specific hardware assumptions.

Ledger

Bitcoin must therefore prepare for two different engineering constraints: the resources required to attack its existing cryptography and the network capacity required to replace it.

A 40-Fold Error Reduction Still Leaves a Production Bottleneck

Quantum computers need a reliable supply of specialized resources called magic states to execute certain operations used in large cryptographic algorithms.

Producing those states can consume substantial hardware capacity. Google’s cultivation technique improves their quality by applying error checks and discarding unsuccessful attempts.

The Willow experiment achieved approximately 99.99% fidelity, but only 8% of preparation attempts were retained. Around 92% failed the acceptance checks.

GOOGLE WILLOW / OCTOBER 2026

A breakthrough in accuracy,
but not yet in efficiency


Preparation yield


8 of 100

8% retained
92% rejected

The reported 99.99% fidelity refers to prepared quantum states,
not a complete cryptographic computation.
Source:

Google Quantum AI
.

For a cryptographically relevant quantum computer, producing accurate states is only part of the requirement. They must also be generated quickly enough to sustain a long sequence of logical operations.

Google’s separate elliptic-curve attack estimates involve roughly 70 million to 90 million Toffoli gates, depending on circuit design, and fewer than 1,500 logical qubits.

The estimated physical hardware requirement is below 500,000 qubits under the study’s assumptions. Willow’s latest result cannot be used to calculate a new Q-Day date without modeling the full machine, including state-production throughput, logical error rates and execution time.

The immediate consequence is greater confidence in one building block of fault-tolerant quantum computing, not a demonstrated reduction in the time required to compromise a Bitcoin wallet.

How Bitcoin’s Existing Address Types Compare

Not all Bitcoin outputs expose public keys at the same stage. That affects how long an attacker could have to recover a private key.

The comparison below concerns exposure to a future quantum attack against elliptic-curve cryptography. It does not classify any existing Bitcoin output as fully post-quantum secure.

Bitcoin public-key exposure

When does a quantum attacker see the key?

Output type Public key visible Exposure window
P2PK

Early Bitcoin outputs

At creation Long-term exposure
P2PKH

Legacy hashed-key outputs

Generally at spending Shorter if the key was never disclosed
P2WPKH

Native SegWit v0 key-hash

Generally at spending Shorter if the key was never disclosed
P2TR

Taproot

At creation Long-term exposure

Previously disclosed or reused public keys can remain exposed even when new outputs use key hashes. This comparison covers common single-key output types, not every Bitcoin script construction.

For holders using hierarchical deterministic wallets, generating a fresh receiving address for each payment helps avoid reusing keys. Most modern wallets already support this behavior.

Older P2PK holdings and coins associated with repeatedly used keys warrant particular attention. Moving coins to a fresh key-hash output can reduce long-term public-key exposure, although the migration transaction itself reveals signing information.

Taproot does not offer that particular concealment benefit because its output public key is visible from creation. Its existing Schnorr signatures remain vulnerable in principle to sufficiently powerful quantum computers.

No currently deployed Bitcoin address format eliminates every quantum attack scenario. Users should also avoid unverified wallet migration tools or urgent requests to disclose recovery phrases, regardless of quantum-related headlines.

BIP-361 Raises the Question of Who Gets to Move Old Bitcoin

The governance problem becomes sharper when considering coins that never migrate.

Draft Bitcoin Improvement Proposal 361, titled Post Quantum Migration and Legacy Signature Sunset, was authored by Jameson Lopp, Christian Papathanasiou, Ian Smith, Joe Ross, Steve Vaile and Pierre-Luc Dallaire-Demers.

Rather than leaving quantum-vulnerable signatures valid indefinitely, the proposal outlines a phased migration after Bitcoin introduces a post-quantum output type.

Its first phase would eventually prevent funds from being sent to vulnerable address types. A later phase would restrict legacy ECDSA and Schnorr spending through quantum-safe rescue requirements.

The current draft describes a five-year transition from activation to the later restrictions, with approximately three years before the first phase and another two years before the second. These are proposed intervals, not an adopted Bitcoin activation schedule.

The authors’ rationale is that leaving old signatures unrestricted could allow whoever first acquires sufficiently powerful quantum hardware to seize vulnerable coins.

Their proposed alternative raises an uncomfortable ownership question: should the network restrict the spending of coins that have not migrated, even when their legitimate owners might still possess the original private keys?

The proposal considers rescue mechanisms based on information a legitimate wallet owner may possess but a quantum attacker recovering an elliptic-curve private key would not. One example involves hardened hierarchical deterministic wallet derivation.

Such recovery techniques would not necessarily work for every historical output. Early P2PK coins, created before modern HD wallet standards, present a particularly difficult case.

That includes the broader debate surrounding dormant Satoshi-era holdings. Estimates attributing roughly 1.1 million BTC to Satoshi Nakamoto remain uncertain and should not be treated as verified ownership records.

A sunset policy could prevent quantum-enabled theft of vulnerable funds, but it might also leave some legitimate holders unable to spend their coins. Allowing unrestricted legacy spending would preserve compatibility while leaving the same funds exposed.

This is a disagreement about security, ownership and Bitcoin’s consensus rules, not simply a disagreement over which signature algorithm performs best.

BIP-361 remains a draft. Its publication does not establish community consensus, and no network-wide deadline has been approved.

A Smaller Signature May Be as Important as a Faster Quantum Computer

Bitcoin’s eventual response will depend on cryptographic efficiency as well as security.

ML-DSA-44 is useful for estimating the scale of the problem because its parameters are standardized. It is not necessarily the algorithm Bitcoin developers will choose.

Other post-quantum signature constructions, including hash-based approaches and Falcon-derived designs, involve different trade-offs in signature size, verification cost, implementation complexity and security assumptions.

Bitcoin’s Schnorr signatures also support multisignature constructions such as MuSig2, allowing cooperating signers to produce one compact signature in certain arrangements. ML-DSA does not offer an equivalent drop-in aggregation mechanism.

That difference matters for complex spending arrangements. Replacing each compact signature with an independent post-quantum signature could increase transaction weight roughly in proportion to the number of signatures required.

The size comparison below illustrates why the eventual algorithm choice matters.

Cryptographic payload comparison

What larger signatures could cost Bitcoin

Standardized and candidate algorithms compared by signature and public-key size.

Scheme Signature Public key Combined* Extra vB*
Schnorr 64 B 32 B output key 64 B witness Baseline
ML-DSA-44 2,420 B 1,312 B 3,732 B +917 vB
Falcon-512

Candidate format

~666 B 897 B ~1,563 B ~+375 vB

*Illustrative scenario: signature and public key are both carried as discounted witness data, replacing a 64-byte Schnorr witness signature. Extra virtual bytes exclude encoding and transaction overhead. Falcon signatures are variable-length; ~666 bytes is a commonly cited typical size, not a fixed universal encoding. Falcon-512 is not presented here as a finalized FN-DSA deployment specification.

The calculations show a substantial range of potential costs. An ML-DSA-44 signature and public key could add approximately 917 virtual bytes per spend under the stated assumptions, while a Falcon-512-style payload could add roughly 375 virtual bytes.

Neither figure predicts actual Bitcoin fees or establishes the best algorithm for the network. The chosen output structure, witness rules and possible optimizations would determine real-world transaction weight.

The choice could nevertheless influence how many transactions fit into a block, how much users pay during periods of congestion and how quickly the network could migrate millions of existing outputs.

Google’s Willow experiment has moved one quantum computing technique from theory into working hardware. Bitcoin developers face a different test: designing a post-quantum spending system that preserves security without imposing unacceptable costs on users or leaving large portions of the existing coin supply stranded.

The outcome will depend as much on Bitcoin’s technical and governance decisions as on the next quantum hardware breakthrough.





Source link

fiverr

Be the first to comment

Leave a Reply

Your email address will not be published.


*