Bitcoin BTC

Claim: Bitcoin's critical public-key mechanisms (secp256k1 ECDSA, BIP-340 Schnorr) and quantum threat model (CRQC key recovery from exposed public keys, affected address types P2PK/P2PKH/P2WPKH/P2TR, affected layers) are publicly inventoried via BIP-340/341 specs, secp256k1 code, BIP-361, CoinShares analysis, and Bitcoin Optech.

Coverage basis: Classical ECC inventory with community-driven quantum threat model; no PQ coverage

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Primary sources (BIP specs, source code, BIP-361 draft) provide high-confidence inventory. Threat model is community/industry-driven rather than a single official Bitcoin Core document, but is comprehensive and evidence-backed.

BIP-361 quantifies >34% revealed keys; CoinShares quantifies ~1.6M BTC P2PK. Both are research-grade estimates of on-chain data.

• https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
• https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
• https://github.com/bitcoin-core/secp256k1
• https://bips.dev/361/
• https://coinshares.com/research/bitcoins-quantum-vulnerability
• https://bitcoinops.org/en/topics/quantum-resistance/

Claim: Code references (secp256k1 repo), protocol specifications (BIP-340/341/360/361), independent audit (Quarkslab 2025), reproducible on-chain analytics (CoinShares, BIP-361), and community research (Bitcoin Optech, Delving Bitcoin) support the quantum risk assessment.

Coverage basis: Classical ECC evidence with quantum threat analysis; no PQ evidence

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Evidence record is strong: primary code, specs, audit, and analytics are all publicly available and reproducible.

• https://github.com/bitcoin-core/secp256k1
• https://ostif.org/wp-content/uploads/2025/11/25-05-2133-REP-bitcoincore-security-assessment-V1.3.pdf
• https://bips.dev/360/
• https://bips.dev/361/
• https://coinshares.com/research/bitcoins-quantum-vulnerability

Claim: Bitcoin mainnet transaction signatures use ECDSA (secp256k1) or BIP-340 Schnorr (secp256k1). No PQC or hybrid-PQC signature support exists in production.

Coverage basis: ECC-only; no PQ/hybrid coverage

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: ECC-only spend authorization caps QRI at 40 (Readiness & Risk Cap).

Assurance: Confirmed by primary BIP specifications and production secp256k1 library source code. Both ECDSA (legacy) and Schnorr (Taproot/BIP-340) are based on secp256k1 ECDLP and are Shor-vulnerable.

Taproot's key-path spend exposes the public key directly on-chain, making all Taproot-only addresses long-exposure quantum-vulnerable.

• https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
• https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
• https://github.com/bitcoin-core/secp256k1

Claim: Bitcoin address types include P2PK (permanently exposed public key), P2PKH/P2WPKH (hash-protected until spend), P2SH/P2WSH (hash-protected until spend), and P2TR (key-path exposes tweaked public key directly). No PQ/hybrid controls exist to prevent long-exposure quantum-vulnerable ownership paths.

Coverage basis: ECC-only; no PQ/hybrid controls; multiple long-exposure surfaces exist

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: P2PK outputs (~1.6M BTC) have permanently exposed keys. P2TR key-path stores tweaked public key directly in locking script (quantum regression). P2PKH/P2WPKH provide hash-based protection until first spend. BIP-360 P2MR proposes removing the key-path spend but is not activated.

• https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
• https://bips.dev/361/
• https://coinshares.com/research/bitcoins-quantum-vulnerability

Claim: Bitcoin is a PoW chain with no validator signatures, VRFs, finality signatures, threshold signatures, or block certificates. Consensus is achieved via SHA-256 proof-of-work.

Coverage basis: N/A — PoW chain without validator authentication

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: PoW consensus is hash-based (SHA-256d) and not vulnerable to Shor's algorithm.

• https://github.com/bitcoin/bitcoin

Claim: Bitcoin's block hash chain and Merkle tree commitments use SHA-256 (quantum-safe). Supply binding is enforced by hash-based consensus rules (quantum-safe). Script authorization (OP_CHECKSIG, OP_CHECKMULTISIG) relies on ECDSA/Schnorr over secp256k1 (quantum-vulnerable). No KZG/pairing commitments or bridge verification exist.

Coverage basis: Hash-based state integrity (quantum-safe); ECC script authorization (quantum-vulnerable) — mixed state

Implementation score: 0.5 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: SHA-256 block hashing and Merkle commitments are quantum-resistant. Supply cannot be inflated by quantum attack. Script authorization (OP_CHECKSIG) remains the quantum-critical weak point — a quantum attacker who can forge ECC signatures can steal coins even though the chain integrity is intact.

Partial score reflects hash-based state integrity and supply binding being quantum-safe (majority of subfactor scope), while script authorization (the dominant spend path) remains ECC-vulnerable.

• https://github.com/bitcoin/bitcoin
• https://github.com/bitcoin-core/secp256k1
• https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki

Claim: Bitcoin mainnet has no privacy layer, zero-knowledge proofs, shielded pools, note encryption, viewing keys, or stealth address protocol at the consensus layer.

Coverage basis: N/A — no privacy layer

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

• https://github.com/bitcoin/bitcoin

Claim: Bitcoin's P2P layer does not use ECC signatures for node identity or peer authentication in a consensus-critical, spend-critical, bridge-critical, or custody-critical way. Peers are identified by IP address; block validation uses SHA-256 PoW. Message integrity uses SHA-256 checksums.

Coverage basis: Satisfied by design — no quantum-vulnerable P2P identity path for critical layers

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Bitcoin Core's P2P protocol does not authenticate peers via ECC signatures. Optional BIP-324 v2 transport uses ECDH on secp256k1 for encryption but this is not consensus or spend-critical.

• https://github.com/bitcoin/bitcoin

Claim: No PQ or hybrid-PQC wallet, custody, HSM, or hardware-wallet workflow exists for Bitcoin mainnet. All production wallets use ECDSA/Schnorr over secp256k1 exclusively.

Coverage basis: ECC-only; no PQ/hybrid wallet support

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: No PQ wallet path exists because no PQ signature scheme is activated on mainnet. Hardware wallets support secp256k1 ECDSA/Schnorr only.

Wallet support for PQ signatures would follow mainnet activation of a PQ signature BIP. Ledger Safe 7 ships SLH-DSA for firmware signing but not for Bitcoin transaction signing.

• https://github.com/bitcoin-core/secp256k1

Claim: Approximately 0% of Bitcoin's economically relevant value-at-risk is protected by PQC or hybrid-PQC controls. All UTXOs are spendable only via ECDSA or Schnorr signatures over secp256k1. ~1.6M BTC (P2PK) and >34% of supply (revealed keys) are long-exposure vulnerable.

Coverage basis: Unprotected value; <25% coverage threshold per 9.3.1

Implementation score: 0.05 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: cap-applying

Quantum blocker: Material long-exposure quantum-vulnerable value with no migration/freeze/deprecation path caps QRI at 55 (subsumed by 40 cap).

Assurance: Coverage is effectively 0% — no PQ-protected spend path exists on mainnet. Per 9.3.1: <25% coverage → score 1 out of 20 subfactor weight → Implementation Score = 0.05. Value-at-risk estimates (34%, 1.6M BTC) are independently corroborated on-chain research.

CoinShares narrows practically exploitable risk to ~10,200 BTC in large UTXOs, but all exposed-key UTXOs are cryptographically vulnerable.

• https://bips.dev/361/
• https://coinshares.com/research/bitcoins-quantum-vulnerability
• https://www.forbes.com/sites/forbesdigitalassets/2026/05/28/bitcoins-quantum-threat-timeline/

Claim: No critical Bitcoin wallets (exchanges, custodians, treasuries, foundations, major protocols) are migrated to or protected by PQC. All critical wallets use ECDSA/Schnorr over secp256k1.

Coverage basis: ECC-only; no PQ migration for any critical wallet

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: No PQ migration path exists on mainnet, so no critical wallet can be migrated. Bitcoin Security Consortium (Coinbase et al., July 2026) is funding PQ R&D but no production migration is live.

• https://github.com/bitcoin-core/secp256k1
• https://www.coinbase.com/blog/coinbase-joins-bitcoin-security-consortium

Claim: Legacy quantum-vulnerable UTXO pools are identified and measurable (P2PK: ~1.6M BTC per CoinShares; revealed-key UTXOs: >34% of supply per BIP-361; P2TR key-path outputs). No deprecation, migration, freeze, or burn mechanism is live on mainnet.

Coverage basis: Identified and measurable; not deprecated/migrated/frozen

Implementation score: 0.25 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Identification and measurement are strong (BIP-361, CoinShares, Delving Bitcoin). Hourglass rate-limiting proposal is theoretical only. No consensus policy exists for unmigratable coins (e.g., Satoshi's P2PK stash).

Partial credit (0.25 = research/analysis level) for identification and measurability. Per QRI 9.3.2, unmigratable vulnerable value without a policy mechanism counts as unprotected.

• https://bips.dev/361/
• https://coinshares.com/research/bitcoins-quantum-vulnerability
• https://delvingbitcoin.org/t/thoughts-on-a-network-policy-for-quantum-vulnerable-utxos/1225

Claim: BIP-360 (P2MR, Draft) and BIP-361 (Legacy Signature Sunset, Draft) provide a proposal-level migration roadmap with phased sequencing (Phase A: disallow sends to vulnerable addresses; Phase B: restrict ECDSA/Schnorr spends; Phase C: recovery). BIP-361 specifies deployment parameters (starttime Jan 1, 2027 UTC, bit 5). Neither is activated on mainnet.

Coverage basis: Draft BIP proposals; not activated on mainnet

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: none · Score treatment: note-only

Assurance: BIP-361 Requires: TBD Post Quantum Signature BIP that does not yet exist. BIP-360 P2MR mitigates long-exposure but does not introduce PQ signatures. Roadmap is proposal-stage only.

Per Implementation Score table: draft BIP specification = 0.25.

• https://bips.dev/360/
• https://bips.dev/361/
• https://bitcoinops.org/en/topics/quantum-resistance/

Claim: No PQ or hybrid-PQC account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education materials, or migration prompts exist for Bitcoin mainnet users.

Coverage basis: No migration accessibility on mainnet

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: No PQ address format or signature scheme is activated on mainnet, so no migration tooling can exist. BIP-360 proposes bc1z addresses (SegWit v2) but is not activated.

• https://github.com/bitcoin/bitcoin

Claim: BIP-361 proposes enforcement mechanisms (Phase A: disallow sends to vulnerable addresses; Phase B: restrict ECDSA/Schnorr spends) but none are activated. Bitcoin Security Consortium (Coinbase et al., July 2026) provides nascent institutional coordination for PQ R&D funding. No production enforcement prevents unsafe fallback into vulnerable systems.

Coverage basis: Proposal-level enforcement; nascent institutional coordination

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: none · Score treatment: note-only

Assurance: BIP-361 enforcement is proposal-stage. Bitcoin Security Consortium is real (formed July 2026) but funds R&D, not production enforcement. Hourglass rate-limiting proposal is theoretical.

Partial credit (0.25) for proposal-level enforcement design and nascent institutional coordination. No production enforcement exists.

• https://bips.dev/361/
• https://www.coinbase.com/blog/coinbase-joins-bitcoin-security-consortium
• https://delvingbitcoin.org/t/thoughts-on-a-network-policy-for-quantum-vulnerable-utxos/1225

Claim: Bitcoin Core maintains a mature general security disclosure process ([email protected], responsible disclosure, CVE process). The BIP process provides governance for protocol upgrades. No quantum-specific incident-response playbook exists, but the general process would apply to quantum vulnerabilities.

Coverage basis: Mature general process applicable to quantum scenarios; no quantum-specific playbook

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Bitcoin Core's security disclosure process is operational and mature. The absence of a quantum-specific playbook is note-only per QRI spec (does not create a current quantum-vulnerable path).

Per QRI spec: lack of a formal quantum-specific incident-response playbook is note-only unless it leaves a current quantum-vulnerable path unresolved. Bitcoin's general process is adequate for current state.

• https://github.com/bitcoin/bitcoin
• https://www.coinbase.com/blog/coinbase-joins-bitcoin-security-consortium

Claim: Bitcoin mainnet uses no PQC or hybrid-PQC algorithms. Prototypes exist using NIST-standardized algorithms (BTQ ML-DSA canary network, Falcon-512 demo fork) and hash-based schemes (Blockstream SHRINCS on Liquid), but none are in production on Bitcoin mainnet.

Coverage basis: No PQC algorithm in production; prototypes on separate networks

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Prototype work (ML-DSA, Falcon, SHRINCS) demonstrates technical feasibility but none is on Bitcoin mainnet. SHRINCS is a novel hash-based scheme with a draft specification deployed on Liquid sidechain.

No PQC algorithm is activated or available for production use on Bitcoin mainnet.

• https://github.com/bitcoin-core/secp256k1
• https://www.sec.gov/Archives/edgar/data/1967617/000110465925107645/tm2528451d1_ex99-1.htm
• https://blog.blockstream.com/op_checkshrincs-a-hash-based-signature-opcode-for-post-quantum-bitcoin/

Claim: The 2025 Quarkslab/OSTIF Bitcoin Core security assessment is a recent general security audit but does not cover post-quantum readiness or PQC implementation. No quantum-specific audit exists for Bitcoin's production scope.

Coverage basis: No quantum-critical audit; classical audit is scope-mismatched

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: Quarkslab audit is current (2025) and valuable for classical code quality but scope-mismatched for quantum-critical assessment. No PQC implementation exists to audit. The absence of a quantum-specific audit does not reduce the QRI Score because the quantum-critical vulnerability (ECC-only) is independently verifiable from code and standards.

Per QRI spec: scope-mismatched audit supports only the audited component; confidence limited for unaudited production scope.

• https://ostif.org/wp-content/uploads/2025/11/25-05-2133-REP-bitcoincore-security-assessment-V1.3.pdf

Claim: Bitcoin Core and the secp256k1 library are fully open-source (MIT License), publicly developed on GitHub, and reproducible. Deterministic builds are supported.

Coverage basis: Open-source classical implementation; no PQ code in production

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Bitcoin Core is one of the most scrutinized open-source cryptographic codebases. Deterministic builds (Gitian) support reproducibility. This applies to the classical ECC implementation.

• https://github.com/bitcoin/bitcoin
• https://github.com/bitcoin-core/secp256k1

Claim: Bitcoin's consensus protocol has limited crypto agility (signature scheme changes require soft forks). BIP-360 and BIP-361 document a proposed future PQ upgrade path. No parameter agility mechanism exists in the current production consensus.

Coverage basis: Proposal-level upgrade path; no production agility

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: none · Score treatment: note-only

Assurance: Bitcoin's soft-fork upgrade mechanism is well-understood but slow (Taproot: ~22 months from BIP to activation). BIP-360/361 document a proposed upgrade path but no PQ signature BIP exists yet.

Per Implementation Score table: proposal-level documentation = 0.25.

• https://bips.dev/360/
• https://bips.dev/361/

Claim: No PQC implementation exists in Bitcoin mainnet production, so stateful-signature safety (XMSS/LMS anti-reuse controls) is not applicable. Classical secp256k1 implementation has well-reviewed constant-time side-channel protections.

Coverage basis: No PQC implementation; classical side-channel handled

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: Classical secp256k1 constant-time implementation is well-reviewed. Stateful-signature safety (XMSS/LMS) is not applicable (no PQC in production). Note-only per spec: does not reduce QRI Score because no PQ implementation exists to assess.

Per QRI spec: do not mark a subfactor N/A merely because the project has not implemented it. Scored 0.00 because no PQ implementation risks have been addressed.

• https://github.com/bitcoin-core/secp256k1
• https://ostif.org/wp-content/uploads/2025/11/25-05-2133-REP-bitcoincore-security-assessment-V1.3.pdf

Claim: No production PQC implementation exists, so no production performance or resource-impact analysis for PQ signatures on Bitcoin mainnet is available. Blockstream published SHRINCS size/throughput figures (~580 bytes compact path) for the Liquid sidechain demonstration.

Coverage basis: No production PQ performance analysis

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: note-only

Assurance: SHRINCS performance data (Liquid sidechain) is preliminary and not for Bitcoin mainnet. No formal PQ performance benchmark exists for Bitcoin's production scope. Note-only per spec: no PQ path exists to benchmark.

PQ signature sizes would significantly impact Bitcoin block sizes and validation times. This is a known concern but not formally analyzed for mainnet.

• https://blog.blockstream.com/op_checkshrincs-a-hash-based-signature-opcode-for-post-quantum-bitcoin/