Bitcoin’s security model depends on elliptic curve cryptography (ECC). A cryptographically relevant quantum computer breaks (CRQC) ECC, exposing private keys and putting on-chain funds at risk. This isn’t science fiction anymore, it’s engineering.
Quantum computing has gone through multiple hype cycles, leaving many cynical. However, a succession of major challenges have been solved in the past 2-3 years, including quantum error correction and producing high-quality qubits, and the field will now steadily progress towards a CRQC, or a machine on the order of 1M physical qubits.
The Bitcoin community has started grappling with this future and proposing changes to stay ahead of the (elliptic) curve - but the fixes aren’t simple. Some proposals are elegant but fragile, others robust but complex.
This post takes a look at the most serious quantum-resistant proposals being discussed today–what they do well, where they fail, and what they might cost us.
https://groups.google.com/g/bitcoindev/c/oQKezDOc4us
BIP360 introduces a new Bitcoin output type, “Pay to Quantum Resistant Hash” (P2QRH), that lets you spend coins with post-quantum (PQ) signatures. This doesn’t require a massive hard fork, or a sudden block-size jump. Instead of revealing an elliptic-curve public key & signature when you spend, you reveal multiple sets of these, which can include both elliptic-curve and post-quantum signatures.
Under the hood, P2QRH rides on SegWit version 3 and addresses now start with “bc1r”. Legacy nodes will treat UTXOs with these output addresses as anyone-can-spend (so they’ll never relay or mine them), while upgraded nodes parse the 32-byte commitment in the scriptPubKey. When you want to spend, you provide an witness that bundles your public keys and signatures. Miners check that your signatures are valid and match the original 32-byte value. You can mix and match classical Schnorr and post-quantum keys–FN-DSA, ML-DSA, or SLH-DSA–in the same output, think multi-sig with a combination of classical and PQ crypto. A “key type bitmask” in the hash identifies which digital signature algorithms are included in the hash and a threshold says how many signatures are required. If you have, say, a 3-of-5 multisig, you only reveal the three keys you actually want to use (and the hashes of the others). That way, unused keys stay hidden under their hashes and the script can still execute as normal.
Because all the hashing happens inside the scriptPubKey, a P2QRH address is just a 32-byte Bech32m string (“bc1r…”). There’s no script to execute until you spend. At spend time, the witness includes the public keys and signatures (in this BIP, they are contained within a new field called the attestation but it’s effectively the same thing).
P2QRH deliberately builds a hybrid: every output can include classical secp256k1 keys alongside one or more post-quantum keys. That way, if someone finds a flaw in a PQC scheme, you still have your ECC fallback.
Of course, there’s a price to pay. Post-quantum public keys and signatures are much much larger than a 64-byte Schnorr signature. A single ML-DSA signature can be between 2-3KB. SLH-DSA signatures can be up to 8KB! That means P2QRH spends demand far more block space, driving fees higher unless miners give these “quantum attestations” some witness discount.
There’s also implementation effort: wallets and nodes must learn to parse SegWit v3, compute that 32-byte hash from a sorted list of public-key hashes, and verify a combination of ECC and PQC signatures. Until P2QRH is widely adopted, older wallets simply won’t know what “bc1r” is, so interoperability hiccups are inevitable.
On the plus side, P2QRH gives immediate quantum resilience without touching existing transaction forms or forcing private mempools. In a world where many high-balance wallets still use older address types, P2QRH is a straightforward way to seal off those coins against quantum threat. Future BIPs can layer in things like signature aggregation and full BIP-32 support.
In short: P2QRH is a minimal-diff, high-compatibility patch – but it kicks some of the hard problems down the road. It’s a useful foundation, not a full fix.
https://groups.google.com/g/bitcoindev/c/8O857bRSVV8
This proposal describes a “just-in-time” upgrade to Taproot that embeds a post-quantum fallback without forcing anyone to migrate today. Taproot already lets you include a hidden script-path option–most wallets ignore it and spend via the simpler Schnorr key-path. Here, we add one more leaf to that Taproot tree: a hash-based, SLH-DSA signature check. When you create your Taproot output, it now commits to two ways to spend: the familiar Schnorr key-path or, when quantum becomes a real threat, the new SLH-DSA script-path. Underneath it all, the Taproot output’s public key is computed by tweaking your internal key (your original X-only Schnorr pubkey) with the Merkle root of the entire script tree. Because a quantum attacker only ever sees the final, tweaked key on-chain, and never the internal key itself, they cannot forge a new SLH-DSA leaf. In short, only the wallet that chose that internal key (and built the SLH-DSA leaf) can ever spend via the post-quantum path once Schnorr key-paths are disabled.
In practical terms, implementing this is straightforward. When you build your Taproot address, simply add one more script leaf containing OP_SLHDSA <hash of your PQ public key>. Everything else–fee calculations, address formats, key-path spending–remains exactly the same. That extra leaf’s hash folds into the Merkle root, which in turn tweaks the internal key to form your on-chain Taproot pubkey. Until quantum arrives, nobody ever uses that SLH-DSA branch, and wallets continue signing with Schnorr exactly as before.
Once a credible quantum threat emerges, miners flip a soft-fork switch that globally disables all Schnorr key-path spends. From that moment onward, any attempt to spend a Taproot UTXO via the old key-path is immediately rejected by upgraded nodes. The only valid spend is the script-path branch, which requires a valid SLH-DSA proof. If an old, pre-soft-fork wallet somehow tries a Schnorr spend, it appears valid to legacy nodes but is rejected by upgraded nodes–so blocks containing those spends simply fail consensus among the upgraded majority. This preserves backward compatibility until the moment of activation, then instantly locks down funds behind post-quantum checks.
UTXOs in Taproot outputs created before this upgrade–or any wallet that opts out of including the SLH-DSA leaf–will be effectively frozen once quantum arrives. Those UTXOs can no longer be spent with Schnorr, and they have no PQ fallback. That raises a critical governance question: should core developers be allowed to enact a change that confiscates coins from non-opting wallets?
Another nuance is ensuring every non-PQ path is disabled once the soft fork activates. If you only disable the Schnorr key-path but still allow legacy script-path branches (for instance, any path containing an ECDSA or Schnorr check), a quantum adversary could slip in a backdoor. To prevent that, upgraded nodes must reject any script-path that relies on ECC once the soft-fork is enabled. Because each script leaf is committed to the internal key’s hash, an attacker who doesn’t know your internal key cannot create a valid new leaf. In effect, disabling all non-SLH-DSA branches guarantees that every spending route is protected by post-quantum signatures alone.
An upside of this approach is that it doesn’t rely on waiting for OP_CAT or any other heavyweight script opcodes. All you need is a new opcode–OP_SLHDSA–which verifies a SLH-DSA signature against a known hash. Once that’s deployed, wallets can continue building Taproot outputs just as they do today, except they append the extra SLH-DSA branch. If quantum never materializes, nothing breaks: users still spend with Schnorr, and that extra leaf simply sits unused on the Merkle tree. If quantum does arrive, coins were already ready for safe spending via SLH-DSA, with no last-minute migrations or frantic wallet updates.
In practice, SLH-DSA signatures are thousands of bytes long, so once everyone switches to the script path, fees will spike for those spends. By the time quantum is powerful enough to break ECC, high-value users will likely accept that fee premium for peace of mind. Regular everyday transactions can continue using Schnorr until the network flips the soft-fork. And if quantum computers never reach the necessary capability, the ongoing cost is effectively zero–just a few extra bytes per Taproot output that no one ever uses.
In short, this scheme offers a “Plan B” for Taproot that shelters funds from a sudden quantum breakthrough without reshaping Bitcoin today. When the quantum threat finally arrives, upgraded nodes simply disable key paths and force SLH-DSA spends, locking out attackers and keeping coins safe–while non-quantum users remain unaffected until that long-anticipated day.
https://github.com/cryptoquick/bips/blob/p2trh/bip-p2trh.mediawiki
Pay to Taproot Hash (P2TRH) is a lightweight tweak to Taproot that simply swaps out the on-chain tweaked X-only public key for a 32-byte hash of that key. In a normal Taproot output you publish your 32-byte tweaked X-only pubkey directly in the scriptPubKey, and anyone can see it from the moment it lands on chain, this quantum security vulnerability was actually noted in the Taproot BIP. With P2TRH, you instead publish SHA-256(SHA-256(pubkey)) in the scriptPubKey and only reveal the actual public key–and its Schnorr signature–when you spend. This restores the classic “key hidden until spend” behavior of older P2PKH/P2WPKH addresses, but still lets you have Taproot’s efficiency and signature aggregation once you actually broadcast a transaction.
Why bother? The main driver is “long-exposure” quantum attacks. Any public key sitting exposed on chain could eventually be cracked. Taproot’s X-only key is visible in every UTXO forever, so high-value coins that sit idle could be mined for days or weeks by a quantum adversary. By storing only a hash of the key on chain, P2TRH limits that risk window to “from when your spend hits the mempool until it confirms”.
Implementing P2TRH is almost trivial compared to a full post-quantum signature scheme. You reuse all the existing Taproot logic without adding any new cryptographic primitives. The only difference is that in your scriptPubKey you push the hash of the public key rather than the X-only coordinate. When it’s time to spend, your witness still contains a Schnorr signature and the full public key–exactly what Taproot normally uses. Miners simply check that when they hash your revealed pubkey twice it matches the 32-byte hash in the original output. No new opcodes, no new signature formats: just swap one 32-byte value for another.
Of course, this is not a silver bullet. P2TRH does nothing to stop a quantum attacker from capturing your public key while your transaction is in the mempool. If you broadcast on a public node, an adversary could conceivably grab the full pubkey from your unconfirmed spend and immediately throw quantum hardware at it. We call this a “Just In Time” attack. In other words, P2TRH pushes off the moment of exposure from “when you first receive funds” to “when you finally spend them”, but it doesn’t make that final exposure disappear. On top of that, this is an opt-in update, old P2TR UTXOs don’t magically adopt this change, holders must upgrade to P2TRH.
The upside is that adopting P2TRH is hardly contentious (famous last words). By building on the same Schnorr code paths and SegWit structure, it avoids any debate around new cryptographic standards or controversial script changes (in theory). Wallets merely need to treat “bc1t…” addresses as Hash-only versions of “bc1p…” and adjust their spending code to supply the full pubkey when it’s time to sign. It’s a small change, but it immediately reduces the “coins sitting in Taproot addresses get scanned by a quantum adversary” risk, especially for long-holding wallets or cold storage that might never move funds until far in the future. However, just like with P2PKH & P2WPKH, address re-use renders this incremental change useless.
In the end, P2TRH is a modest “quick win” for anyone who wants to lock down P2TR funds against tomorrow’s quantum threat without waiting for the full PQC migration to happen.
https://groups.google.com/g/bitcoindev/c/wKizvPUfO7w
If Bitcoin adopts post-quantum (PQ) signatures, it inherits their size problem. This threatens to choke Bitcoin’s throughput, bloat the chain, and skew fee markets. NTC proposes a countermeasure: compress all of those big PQ signatures into a smaller proof.
The idea is to enable a new transaction type that supports PQ signatures and allows miners to compress all the PQ signature data in a block into a single STARK proof. The STARK verifies that every transaction includes valid signatures, with a strong cryptographic guarantee. Instead of each transaction carrying its own massive signature blob, they share one succinct proof–effectively amortizing the cost across the entire block.
This approach, referred to as Non-Interactive Witness Aggregation (NIWA), has two key consequences:
- It reduces the on-chain footprint of PQ payments–down to potentially ~76 bytes per transaction.
- It reshapes Bitcoin’s fee economics, making normal payments significantly cheaper than non-compressible data (like NFTs or “JPEGs”).
One of the core concerns about adding PQ support is that any discounting of large witness data could be gamed to store arbitrary data cheaply on-chain. NTC sidesteps that entirely. JPEGs don’t get compressed by the STARK. Only valid PQ payments do. This creates a natural cost differential: paying becomes cheap; storing junk stays expensive.
There are also some scalability gains. With compressed PQ signatures, you could push raw throughput from today’s ~7 tx/s up to ~87 tx/s–even higher with aggregation strategies like pre-block coinjoins. Exchanges, custodians, and other high-volume actors can aggregate transactions off-chain and publish tightly packed settlement bundles. That relieves pressure on the mempool and helps the network scale without changing consensus rules or moving to an account-based model.
But…
First: proving time. STARK proofs aren’t free to generate. They are computationally intensive, novel, and somewhat unknown.
Second: wallet and ecosystem support. This requires new transaction formats, new logic, and full-node support for verifying these block-level proofs.
Third: premature adoption. Until PQ signatures are widely used, it’s unclear whether introducing NTC will see real uptake. The design anticipates this with an economic lever: the STARK gets treated as “free” in block weight. That incentivizes adoption early on, even if only a few transactions use the new format.
There’s also an open question around signature schemes. The proposal suggests using LaBRADOR or similar PQ schemes that support non-interactive aggregation. That avoids needing the STARK to perform all aggregation logic and reduces its cost to just proof-of-correctness for signature inclusion and transaction integrity.
NTC doesn’t just patch in PQ support–it rethinks how Bitcoin could scale in a post-quantum world. It reframes the PQ cost problem into a scalability opportunity, with side benefits for fee structure, user privacy, and mempool load. But it’s also speculative. It requires confidence in proof generation costs; coordination on new signature schemes; debates around coinjoins, ZK in Bitcoin, and scaling; and significant engineering to make it viable.
When PQ signatures become mandatory, Bitcoin either gets dramatically bigger–or smarter. NTC is an argument for the latter. However, STARKs are an unknown quantity for Bitcoin. Should we be focused on solving one problem at a time?
(Note, that #5, #6, #7 can all be grouped together under “commit/reveal” schemes)
https://groups.google.com/g/bitcoindev/c/jr1QO95k6Uc
This proposal shows that hashed‐key UTXOs (like P2PKH or P2WPKH) can be made fully safe from a quantum attacker–even though they’re normally vulnerable in the mempool–by forcing them to spend through a two‐step commit/reveal process paired with a tiny post‐quantum (QR) helper output. The basic idea is that you only finalize a spend of a hashed‐key coin if it’s paired with a matching QR signature reveal. In effect, you lock the old coin behind a QR check so a quantum adversary can’t simply snatch it from the mempool.
First, assume a minimal QR signing scheme is available (big assumption!), even if it isn’t widely deployed yet. A user who wants to protect a hashed‐key UTXO obtains a small amount of Bitcoin locked on a QR script–just enough to cover fees. Next, they build a commitment transaction that spends both the old hashed‐key UTXO and the helper QR UTXO in one go, but instead of revealing the QR public key or signature, they embed a hash of a future QR signature inside that transaction. That hash proves “I know the QR private key” without revealing anything to a quantum attacker. If anyone tries to spend the old coin alone, nodes reject it because it lacks the matching QR commitment.
Once that commitment transaction confirms under the usual block‐confirmation rules, the user broadcasts a recovery spend that again spends both UTXOs–this time revealing the actual QR signature, which must match the earlier hash. Nodes check “Does SHA256(signature) equal the committed hash?” If yes, they allow the old hashed‐key UTXO to move. A quantum attacker, by contrast, would have to reorganize the chain back to before the commitment and insert their own forged QR commitment–an economically infeasible deep reorg. At worst, honest coins might be temporarily frozen until the reveal, but they cannot be stolen.
When quantum computers become a threat, this commitment requirement can be turned into a soft fork: nodes simply refuse any hashed‐key spend unless they see the corresponding QR commitment in a prior block. Old wallets that ignore it will see their transactions dropped, forcing users to adopt the commit/reveal workflow or risk being unable to spend.
https://groups.google.com/g/bitcoindev/c/oa4nDmlLzN4
This proposal flips the usual “react after quantum shows up” mindset by letting users prep today for a post-quantum move without ever revealing which coins they control. This proposal aims to tackle two problems, the quantum one, and a privacy one. In the event of needing to upgrade UTXOs to be quantum secure, anyone who tries to migrate early effectively tells the world “I still care about these addresses,” exposing which keys are active and which sit empty.
The idea here is: each user builds and signs all of their “recovery” transactions now–transactions that would send their coins into quantum-resistant addresses in the future. Instead of submitting those transactions today (which wouldn’t even be valid under current rules), they collect each transaction’s full hash into a Merkle tree and publish only the root in an OP_RETURN. That single 32-byte commitment locks in every future move without revealing a single UTXO or address. There’s no need for any consensus upgrade today; anyone, right now, can commit in this way.
When a quantum computer finally threatens ECC-based signatures, the network soft-forks to impose a delay–say, “n” confirmation blocks–on any spend from a quantum-vulnerable UTXO. Regular spending still works, but no uncommitted transaction can clear until this delay has passed. If an attacker cracks your key and tries to steal, you simply reveal the matching Merkle path to your pre-signed recovery transaction. Miners check “Does this transaction’s hash appear in the committed Merkle root from 2025?” If yes, your recovery transaction overrides the attacker’s spend after the delay. In effect, you’ve planted a “poison pill”: the thief can broadcast a grab, but your pre-commitment dethrones them.
This approach has several clear benefits. First, it requires zero consensus changes today–any user can protect themselves immediately. Second, it preserves privacy, since the Merkle root never leaks which UTXOs you own. Third, it’s efficient: a single hash covers all your future migrations, and even multiple users could aggregate commitments into one root if desired. Finally, it’s flexible: if quantum never arrives, nothing ever changes. If it does, your recovery plan is already on-chain, waiting to activate.
The catch: you must have never exposed your ECC public key before crafting those offline recovery TXs (otherwise an attacker could anticipate the same wTXIDs and create a valid Merkel proof). Wallets need to support pre-signed TXs, Merkle‐proof generation, and users must track announcements.
Again, this assumes we have some form of quantum safe address present for users to create these offline upgrade transactions.
https://groups.google.com/g/bitcoindev/c/LpWOcXMcvk8
This proposal offers a “just‐in‐time” way to add on post‐quantum protection without any protocol today. The core idea is to let UTXOs exist as they are today, and only require a hash‐based commitment once a quantum computer actually shows up. That way, you don’t lock up funds prematurely or force big consensus changes until you really need them.
At a high level, here’s how it works. You pick an output you control. Before spending that UTXO, you normally sign a transaction–but instead of broadcasting it right away, you hash the public key and the transaction ID together, bundle those hashes plus the txid into a tiny OP_RETURN commitment, and push that to chain first. We call the three‐part commitment the Address ID (AID = h(pubkey)), the Sequence‐Dependent Proof (SDP = h(pubkey ‖ txid)), and the Commitment TXID (CTXID = txid). Once that commitment confirms, you broadcast your real spend. Miners check “Does this UTXO’s public key hash match AID, and does h(pubkey ‖ txid) equal SDP, and is txid the CTXID we saw earlier?” If so, the spend is valid. Otherwise it’s rejected.
That simple version has a timing issue: once you reveal your pubkey in the full spend, a quantum attacker could immediately hash the same pubkey and slip in their own commitment and malicious spend before yours confirms. To address that, the proposal adds a “first‐seen commitment” rule. If you commit first (and your commitment was honestly derived from your pubkey), you lock out other claims.
The proposal suggests that a soft-fork is triggered once there is “proof-of-quantum-computer” (PoQC). This way, any UTXO that is not coupled with a valid commitment is dropped.
There are trade‐offs to consider. If you wait too few blocks between confirming your commitment and broadcasting your spend, an attacker with some hash‐power could potentially reorg back far enough to replace your commitment with their own. The longer you wait, the safer you are, but that slows down spending. This may favour private memopools or off-chain payment to miners to get your commitment on-chain–something generally viewed as “anti-Bitcoin”, but at least it’s the devil we know.
Storing all these commitments in a database is also extra work for node operators. You could force each commitment to pay a nonzero amount to discourage spam, but that’s a policy call.
The nice thing about this approach is that, until someone actually breaks secp256k1 with a real quantum device, Bitcoin behaves exactly as it does today. Wallets don’t have to change, nodes don’t have to store commitments, and fees stay normal. The moment PoQC is triggered on-chain, every node starts requiring those 3‐hash commitments before any spend. You don’t need to define or deploy a brand‐new PQ signature algorithm; you just ask users to prove they knew their ECC key before quantum showed up. It’s a minimal, soft‐forkable emergency brake, giving everyone a way to lock down funds at rest without a massive upfront migration for the cost of a few hashes in an OP_RETURN UTXO.
All three proposals share a core idea: you hide your ECC public key behind a commitment, then later reveal just enough information to prove you knew the private key at commit time. That way, an attacker can’t simply wait until quantum arrives, break your key, and race you to spend. Beyond that common thread, each design takes a different approach to when and where you put your commitment, how miners enforce it, and what you must do today versus in the future.
In each case, the promise of post-quantum safety relies on keeping your ECC key private until you create a valid commitment. If your public key was ever revealed before committing, an attacker can simply produce identical commitments or wTXIDs and still win. That single requirement–pristine key hygiene–is the key to all three schemes, not something we can take for granted*.
Every proposal reviewed here offers a different slice of the problem space–and not one of them escapes serious limitations. The simplest options–like P2TRH or quantum-safe Taproot–are easy to implement but offer only narrow protection, or worse, come with risks of permanent fund loss. BIP-360 and NTC via STARKs are comprehensive, but their real-world adoption is gated by technical complexity, massive transaction overhead, or unproven cryptographic assumptions. The commit/reveal schemes are clever and balance large changes to the protocol vs quantum risk well–if you’ve kept your ECC keys private*.
This is the shape of the problem: stronger protections tend to require deeper protocol changes, more user coordination, or more risk. Simpler fixes either break at the first serious test or protect only a subset of users.
There’s no single path forward. Realistically, Bitcoin’s move to quantum safety will need to be gradual. Immediate, minimal-risk changes like P2TRH may buy time. More involved options–like commit/reveal schemes–can provide structured upgrade paths for those who prepare early. Meanwhile, proposals like BIP-360 or NTC via STARKs need more cryptographic scrutiny, prototyping, and community alignment before they become viable.
What’s clear is that Bitcoin’s defense against quantum threats can’t rely on last-minute patches. It demands layered strategy, early warnings, and a lot of realism about coordination costs and user behavior. The longer we delay meaningful progress, the fewer good options we’ll have when it matters.