PoW Blockchain

ECDLP-Based signatures, for all script types. ECDSA (secp256k1) authorizes spends in all standard script types except Taproot. (1) Taproot (P2TR) outputs use Schnorr signatures. (2) Both ECDSA and Schnorr signatures are based on the Elliptic Curve Discrete Logarithm Problem and are broken by a cryptographically relevant quantum computer (CRQC) running Shor's Algorithm. (1)

P2PK, P2MS, P2TR script types expose public key when funds are received / Output is created. All additional script types are vulnerable to at-rest attacks if the public key has been previously exposed via address reuse or other user-initiated activity offchain.

Script types exposed to at-rest by default:

Pay-to-Public-Key (P2PK): Public Key is exposed directly in the locking script and is visible by default when the output is created / bitcoin is received. Oldest script type and includes "Satoshi" and early miners' coins that are believed to be "abandoned". P2PK addresses currently hold ~1.7M bitcoin. (1)

Pay-to-Multisig (P2MS): public key is exposed when output is created / funds are received. Records all n public keys directly on-chain. Similar exposure to P2PK, aside from the fact that an attacker must derive m private keys rather than one, but since the keys are exposed in the locking script the attack can be still launched offline. (1)

Pay-to-Taproot (P2TR): The tweaked public key is stored directly in the locking script when the output is created. All funds in P2TR today are vulnerable to at-rest attack. (1)

Script types not exposed by default to at-rest but via address reuse or through other user-initiated action that reveals public key:

Pay-to-Public-Key-Hash (P2PKH): Only the hash of the public key is recorded on-chain, deriving a public key from its hash would require inverting a hash function via Grover's algorithm, which is not a credible threat. Spending discloses the public key in the unlocking script, so on-spend exposure remains. (1)

Pay-to-Script-Hash (P2SH): Spending conditions and any public keys they contain are hidden behind a hash, immune to at-rest attacks as long as the script is not reused or otherwise exposed before spending. Scripts requiring many signatures make on-spend attacks with few CRQCs harder within the ~10 minute block interval. (1)

Pay-to-Witness-Public-Key-Hash (P2WPKH): Introduced in the 2017 SegWit upgrades, hides public keys behind hash values like P2PKH. (1)

Pay-to-Witness-Script-Hash (P2WSH): SegWit variant of P2SH, hides scripts and keys behind hash values. (1)

Pay-to-Merkle-Root (P2MR) (*proposed script type, not yet active): At-rest attack mitigation proposal under consideration (see PQ Approach). Would not expose public key by default but would still be vulnerable to on-spend attack without implementation of PQ signatures. (1)

Currently all bitcoin script types are at risk of on-spend attacks, as well as the current proposed implementation of P2MR. (1)(2)

In an on-spend attack the attacker extracts the public key from the public mempool and must derive the private key within the ~10 minute average block interval, then broadcast a competing transaction with a higher fee. (1) The Google Quantum AI paper estimates the probability of success at just under 41% for a single signature transaction under its stated assumptions, and notes an attacker could improve their odds by flooding the mempool with high fee transactions to delay confirmation. (1) The only mitigation available today is submitting transactions through private mempool / private block building services. (1)

Not Applicable

Not Applicable

No definitive proposal selected yet.

No definitive solution determined yet.

Surface area requiring proposals:

1. Mitigation of on-spend attack risk through implementation of one or more post-quantum signature types.

2. Mitigation of long-range (at-rest) attack risk through a script type that can support post-quantum signatures and does not expose a legacy Schnorr/ECDSA public key at output creation.

3. Mitigation of the risk of a CRQC stealing lost/dormant coins (including Satoshi-era coins) in legacy vulnerable scripts, including potential rescue/recovery mechanisms for legitimate owners who cannot or will not migrate before sunset deadlines.

1. MITIGATION OF ON-SPEND ATTACK RISK

Leading PQ signature candidates (SHRINCS/SHRIMPS via OP_CHECKSHRINCS) are covered under PQ Signature Schemes. (6)

Quantum Safe Bitcoin (QSB, Avihu Levy / StarkWare): Mitigates short-range (on-spend attack). This proposal would work today with no protocol changes by turning the transaction into a hash-to-signature puzzle relying on RIPEMD-160 preimage resistance plus quantum-resistant Lamport signatures. (7) This proposal, while technically quantum resistant, provides only ~59-bit effective security under Grover, below NIST's 128-bit PQ bar. Additionally it would require significant off-chain GPU compute (~$75-150 per transaction at current cloud spot pricing), and would require these transactions to be sent via a private mempool service. (7)

2. MITIGATION OF LONG-RANGE (AT-REST) ATTACK RISK

BIP-360: Pay-to-Merkle-Root (P2MR). Soft fork, proposed by Hunter Beast / Cryptoquick, Ethan Heilman, and Isabel Foxen Duke. This proposal disables the key path spend in P2TR transactions. The key path spend output currently exposes the tweaked public key in the output, which puts all P2TR outputs at risk of at-rest attack by CRQC. (1) With the key path spend removed, only the Merkle Root path exists. P2MR outputs have no key path spend and omit the Taproot internal key and instead have a 32-byte root of the script tree. (1) P2MR outputs are still vulnerable to on-spend attacks, as the Schnorr signatures used in transactions are quantum vulnerable. (1)

Originally termed P2QRH by Hunter Beast in 2024. The original proposal was much more all encompassing, and proposed a new output type, a new transaction field to carry post-quantum data, and a menu of PQ Signatures. (1) The smaller scope of the current proposal was favored to prioritize more incremental and decoupled upgrades. (2) BIP-360 is intended to first disable the key path spend, while an additional BIP or BIPs will introduce PQ Signatures. (1) The state prior to a CRQC coming online is intended to be P2MR with both Schnorr signatures and PQ Signatures supported. (1) Given Schnorr signatures are cheaper than any potential PQ Signature, users could continue to use Schnorr signatures until a CRQC is believed to be active, and switch to PQ Signatures. (2) In this state only P2MR outputs using PQ signatures would also be resistant to on-spend attacks. P2MR's Taproot foundation gives it tapscript support, which will allow for the future implementation of post-quantum signature opcodes, something non-tapscript outputs can't support. Due to this P2MR is seen as a foundational pre-req for post-quantum bitcoin. (1)

3. MITIGATION OF RISK TO LOST / DORMANT COINS

BIP-361: Post Quantum Migration and Legacy Signature Sunset. Soft fork, proposed by Jameson Lopp, Christian Papathanasiou, Ian Smith, Joe Ross, Steve Vaile, and Pierre-Luc Dallaire-Demers. This proposal has a pre-requisite of the implementation of any post-quantum output type. This proposal introduces a pre-announced sunset of legacy ECDSA/Schnorr signatures. (3) Phase A of the proposal would disallow sending of any funds to quantum-vulnerable addresses, which would occur ~160,000 blocks (~3 years) after the implementation of the BIP. (3) Phase B of the proposal restricts the sending of funds from ECDSA/Schnorr addresses by requiring an additional quantum-safe rescue protocol, intended to prevent theft of funds in vulnerable UTXOs by a CRQC. (3) The restriction of sending funds from the vulnerable addresses would happen 2 years after the activation of Phase A, 5 years after the initial implementation of BIP-361. (3)

The required rescue protocol has not yet been determined. Rescue proposals are new tighter verification for using ECDSA and Schnorr to spend coins designed to rule out quantum attackers but to permit spends from authentic coin holders. The proposal references that "such rescue protocols rely on asymmetry of knowledge between a quantum attacker and the authentic coin-holder. Any context where an asymmetry exists in favor of the authentic holder can theoretically be turned into a rescue protocol." (3)

BIP-361 would also be compatible with an "hourglass" style BIP which would set a limit on the number of TXs and number of bitcoin that can be sent from quantum vulnerable Bitcoin addresses, assuming an Hourglass BIP was implemented. The authors specifically support an Hourglass style approach for P2PK because no knowledge asymmetry usable in a rescue protocol is known for P2PK UTXOs. (3)

BIP-XXX: Hourglass Spending Rule v2. Soft fork proposed by Hunter Beast / Cryptoquick and Michael Casey. This BIP restricts the throughput of number of P2PK spends to one per block and limits the net amount of that spend to one bitcoin per block. (4) Once activated only 1 P2PK output may be included as a transaction input per block. (4) Additionally this would prevent the creation of P2PK outputs to any address not currently being sent from and the creation of P2PK outputs from other address types. (4) This proposal is intended to act as a limit to the potential impact of a CRQC seizing vulnerable coins from vulnerable P2PK addresses. This proposal would only target P2PK address types. If implemented this would only allow for roughly 144 bitcoin per day to be spent from P2PK addresses. (4)

Post-Quantum BIP-86 Recovery via zk-STARK Proof of BIP-32 Seed Knowledge (Olaoluwa Osuntokun). Built on the Lifted FawkesCoin protocol using zk-STARK proofs, allows users to prove ownership of a Taproot address by demonstrating knowledge of the original BIP-32 seed and BIP-86 derivation path without ever revealing the seed. (5) Designed for a future where an emergency soft fork disables Taproot's keyspend path (leaving script-path-only spending). The zk-STARK provides a quantum-resistant proof of ownership. Currently scoped to BIP-86/Taproot addresses but could be expanded to most BIP-32 wallets (post-2012). It would not cover Satoshi's coins or non-BIP-32 wallets. The tradeoffs associated with this proposal are significantly larger transaction size due to the proof, and high confirmation latency (hours to days) because security depends on deliberate temporal separation in the two-phase commit/reveal process. (5)

Commit/reveal and timestamping proposals: There are a variety of commit/reveal and timestamping based proposals which would implement a mechanism in which users today could conduct an action, using knowledge associated with ownership of their bitcoin script outside of standard transaction signing, which would allow the owner to reliably prove ownership of the script even in the presence of a CRQC. These proposals include Tadge Dryja's post-quantum commit/reveal FawkesCoin variant as a softfork (8), Paradigm's PACTs (9), and Jeremy Rubin's commit-reveal for PQ migration (10).

None finalized. Cryptographic agility is preferred, in which multiple signature schemes are supported in parallel. Cryptographic agility is likely to occur in the implementation of P2MR, in which Schnorr signatures and the selected PQ signature scheme would be supported in parallel. Three primary families under consideration: hash-based, lattice-based, and isogeny-based. SHRINCS and SHRIMPS appear to be the leading candidates.

HASH-BASED

Security relies solely on hash-function assumptions, in that hash functions are non-invertible. (1)

SHRINCS: Developed by Blockstream researchers Jonas Nick and Mikhail Kudinov. SHRINCS provides 324-byte stateful post-quantum signatures with static backups. SHRINCS achieves very small hash-based signatures by having the signing device keep track of how many signatures it has produced, which is what stateful means in this context. Each key is given a budget of signatures it can produce through the compact path, and because best practice discourages address reuse this budget can be kept very small. The construction uses a single public key with two signing paths, a compact path that produces small signatures while the budget holds, and a stateless fallback that is always accessible. The catch is that the efficient stateful path requires transferring the signature count to any new device, which is error-prone, so in practice any restored or secondary device falls back to producing much larger stateless signatures. (2)(4)

SHRIMPS: Developed by Blockstream researcher Jonas Nick. SHRIMPS provides ~2.5 kB post-quantum signatures across multiple stateful devices. SHRIMPS removes the single-device limitation of SHRINCS by adding a second compact path specifically for backup devices, with a budget of one thousand signatures. This means a static key backup can be loaded into many independent signing devices without the devices needing to coordinate with each other, as long as each key only signs a small number of times. SHRIMPS signatures are up to three times smaller than SLH-DSA. (3)(4)

SHRINCS + SHRIMPS: The two schemes are designed to be combined. A user's primary device runs SHRINCS, producing compact ~324 byte signatures for day to day spending. Any backup device loaded from the same static seed backup runs the SHRIMPS compact path instead, producing ~2.5 kB signatures without needing to coordinate with the primary device or each other. This means losing or replacing the primary device never forces the user into the full stateless fallback signatures, which are the largest of the three paths. Both schemes would be deployed as spend paths within a P2MR script tree via a future opcode such as OP_CHECKSHRINCS. (3)(4)

SLH-DSA (SPHINCS+): stateless hash-based signature scheme which is an evolution of SPHINCS with size-reduction improvements. Because it is stateless there is no signature count to track or transfer between devices, which removes the state management risk of SHRINCS and SHRIMPS entirely. The tradeoff is size and speed, with signatures ranging from roughly 3 to 8 kB at NIST Security level 1 depending on the parameter set, and the smaller parameter sets are slow to sign. SLH-DSA is the NIST standardized scheme in this family and serves as the stateless fallback path in the SHRINCS construction. (1)(2)

LATTICE-BASED

A class of systems based on "hard problems" over spaces formed by combining sets of vectors to form new vectors. (5)

ML-DSA (CRYSTALS-Dilithium): light on CPU and relatively straightforward to implement but the major tradeoff is large signatures and public keys (~2.4 kB and ~1.3 kB respectively). (6)

FN-DSA (Falcon): relatively small signature and public key sizes with efficient signing and verification, but signing relies on discrete Gaussian sampling using constant-time floating-point arithmetic, which is difficult to implement safely and in constant time. (7)

ISOGENY-BASED

Built on functions mapping points from one elliptic curve to points on another and utilizes the supersingular isogeny path problem. (8)

SQIsign: leading isogeny-based signature protocol, with the smallest key+signature sizes of any post-quantum signature under NIST consideration. Some view it as risky following the classical-computer attack that broke the isogeny-based key exchange SIDH. (9)

Sep 2024: BIP-360 (then Pay-to-Quantum-Resistant-Hash, P2QRH) shared for the first time by Hunter Beast. (1)

Apr 14 2025: Updated BIP-360 posted. (1)

Apr 29 2025: Hourglass v1 posted by cryptoquick and Michael Casey. (2)

Jul 7 2025: BIP-360 rescoped: P2QRH redefined as P2TR with the key path spend removed, PQ signature support deferred to opcodes or leaf version. (1)

Dec 2025: Jonas Nick publishes SHRINCS. (3)

Feb 2026: BIP-360 renamed Pay-to-Merkle-Root (P2MR), via interim rename to Pay-to-Tapscript-Hash (P2TSH) in Sep 2025. (1)

Feb 10 2026: Hunter Beast and Michael Casey publish Hourglass v2. (4)

Mar 27 2026: Jonas Nick publishes SHRIMPS. (5)

Mar 30 2026: Google Quantum AI cryptocurrency whitepaper published. (6)

Apr 8 2026: Olaoluwa Osuntokun publishes Post-Quantum BIP-86 Recovery via zk-STARK Proof of BIP-32 Seed Knowledge. (7)

Apr 9 2026: Avihu Levy (StarkWare) publishes Quantum Safe Bitcoin (QSB). (8)

Apr 14 2026: BIP-361 published. (9)

No target completion date has been set.

Changes to the Bitcoin protocol are proposed through the BIP process. Soft forks typically activate once a supermajority of miners signal readiness within a defined window, though nodes are ultimately what enforce the new rules. No quantum proposal has reached the activation stage. (1)(2)

Current proposals for mitigating Bitcoin's quantum risk opt for soft forks rather than hard forks, though it is not out of the realm of possibility that a future proposal will require a hard fork. Soft forks optimize for backwards compatibility and interoperability. Upgraded nodes enforce the new rules while non-upgraded nodes continue to operate and can still process/validate transactions. (1)(2) Under BIP-361, non-upgraded wallets can send and receive normally until Phase A. After Phase A they can no longer receive from any wallets and can only send to upgraded wallets. After Phase B both senders and receivers require upgraded wallets. (2)

The largest open governance debate is what happens to vulnerable and dormant coins that cannot or will not migrate, including Satoshi era coins. The options being weighed are Do Nothing, in which attackers acquire dormant assets, Burn, which renders dormant assets unspendable after a date and effectively confiscates them, Hourglass, which throttles spending to one P2PK input and 1 BTC per block or roughly 144 BTC per day, and recovery mechanisms honoring offchain proofs of ownership such as a pegged recovery sidechain governed by a consortium. BIP-361's authors support Hourglass for P2PK specifically because no knowledge asymmetry usable in a rescue protocol is known for P2PK UTXOs. (2)(3)(4)