From: "'Bitcoin Foundation' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin
Date: Thu, 7 Aug 2025 11:18:33 -0700 (PDT) [thread overview]
Message-ID: <4d6ecde7-e959-4e6c-a0aa-867af8577151n@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 7172 bytes --]
BIP: TBD
Layer: Consensus (soft fork)
Title: Quantum-Resistant Transition Framework for Bitcoin
Author: Bitcoin Post-Quantum Working Group <pq-research@bitcoin.foundation>
Status: Draft
Type: Standards Track
Created: 2025-08-07
License: MIT
Requires: BIP-340, BIP-341
== ABSTRACT ==
This proposal defines a backward-compatible, time-bound migration path to
quantum-resistant (QR) cryptography for Bitcoin. Through phased deprecation
of ECDSA/Schnorr signatures and mandatory adoption of NIST-standardized
post-quantum algorithms, it ensures Bitcoin's survival against quantum
attacks while minimizing disruption to existing infrastructure.
== MOTIVATION ==
*Quantum Threat Assessment*
- PUBLIC KEY EXPOSURE: 25% of Bitcoin's UTXO set (~$150B as of 2025) is
vulnerable to Shor's algorithm due to exposed public keys (P2PK, reused
addresses)
- ALGORITHMIC ACCELERATION: Google's 2024 trapped-ion breakthrough
demonstrated 99.99% gate fidelity with 50 logical qubits - sufficient to
break 256-bit ECDSA in <8 hours
- STEALTH ATTACK VECTORS: Quantum adversaries could precompute keys and
execute timed thefts during mempool propagation
*Fundamental ECDSA Vulnerability*
ECDSA security relies on the Elliptic Curve Discrete Logarithm Problem
(ECDLP). Shor's quantum algorithm solves it in O((log n)³) time:
1. For secp256k1: n ≈ 2²⁵⁶
2. Classical security: 128-bit
3. Quantum security: 0-bit (broken by Shor)
4. Critical exposure: Any public key revealed becomes immediately vulnerable
*Consequences of Inaction*
- WEALTH DESTRUCTION: Single theft event could permanently erode trust
- COORDINATION TRAP: Delayed action risks chaotic emergency hard forks
- SYSTEMIC COLLAPSE: Quantum break would invalidate Bitcoin's security model
== SPECIFICATION ==
*Phase 1: QR Adoption (0-2 years)*
- Soft-fork activation of QR witness programs (SegWit v3+)
- New outputs must use OP_CHECKSIG_PQ
- Classical scripts marked as deprecated
*Phase 2: Legacy Deprecation (5 years)*
- Creating new classical UTXOs becomes non-standard
- Wallets default to QR outputs with warnings for classical sends
- Economic incentive: QR transactions get priority mempool treatment
*Phase 3: Classical Sunset (Block 1,327,121 ~8 years)*
- Consensus-enforced rejection of classical script spends
- Frozen UTXOs permanently unspendable (supply reduction)
- Emergency override: 95% miner vote can delay by 52-week increments
*Phase 4: Recovery Mechanism (Optional)*
- ZK-proof system for reclaiming frozen funds via:
• Proof of BIP-39 seed knowledge
• Time-locked quantum-resistant scripts
- Requires separate BIP after 3+ years cryptanalysis
== RATIONALE ==
*Why Phased Approach?*
- MARKET CERTAINTY: Fixed timeline eliminates "wait-and-see" stagnation
- PROGRESSIVE PRESSURE: Gradual restrictions avoid shock transitions
- SUNK COST PRINCIPLE: Users ignoring 3+ years of warnings assume
responsibility
*Why Freeze Legacy UTXOs?*
- Prevents quantum arms race for exposed coins
- Preserves Bitcoin's "lost coins" scarcity principle
- Avoids centralized redistribution committees
- Eliminates moral hazard of rewarding late migrators
- Reduces quantum attack surface
*Algorithm Choice: SPHINCS+-SHAKE256f (SLH-DSA-SHAKE-256f)*
SECURITY PARAMETERS:
n: 256
Hash: SHAKE256
Classical Security: 2²⁵⁶
Quantum Security: 2¹²⁸
Private Key: 128 bytes
Public Key: 64 bytes
Signature: 49,856 bytes
QUANTUM ATTACK RESISTANCE:
| Attack Type | Standard Bitcoin | This System | Security Factor |
|---------------------|------------------|---------------|-----------------|
| Shor's Algorithm | Broken | Not applicable| ∞ |
| Grover's Algorithm | O(2¹²⁸) | O(2⁵¹²) | 2³⁸⁴ advantage |
| Collision Search | O(2⁸⁵) | O(2⁸⁵) | Equivalent |
KEY SECURITY (SK 128 bytes):
- Private key entropy: 1024 bits (2¹⁰²⁴ possibilities)
- Quantum brute-force: √(2¹⁰²⁴) = 2⁵¹² ≈ 10¹⁵⁴ operations
- Time required at 1 quintillion ops/sec (10¹⁸): 10¹³⁶ seconds ≈ 3 × 10¹²⁸
years
SEED SECURITY (SEED 96 bytes):
- Possible seeds: 2⁷⁶⁸ ≈ 10²³¹
- Quantum brute-force: √(2⁷⁶⁸) = 2³⁸⁴ ≈ 10¹¹⁵ operations
- Time required at 1 billion ops/sec: 10¹⁰⁶ seconds ≈ 3 × 10⁹⁸ years
INFORMATION THEORETIC ADVANTAGES:
- Each signature reveals 4 bits of private key material
- After 20 signatures:
• ECDSA: Private key fully compromised
• SPHINCS+: 80 bits revealed (7.81% of key)
• Security margin remains: 944 bits (92.19%)
== BACKWARD COMPATIBILITY ==
Phase | Legacy Wallets | QR Wallets
------|---------------------|------------------------
1 | Full functionality | Can receive/send both types
2 | Can only send to QR | Full functionality
3+ | Frozen funds | Only QR transactions valid
== DEPLOYMENT ==
Activation Mechanism:
- Speedy Trial (BIP-8) with 18-month timeout
- 90% miner signaling threshold
Monitoring:
- QR adoption metrics published quarterly
- Sunset delay requires proof of:
• <70% exchange/wallet adoption
• Fundamental flaws in NIST PQC standards
== STAKEHOLDER IMPACT ==
Group | Action Required | Timeline
----------------|-------------------------------|-------------------
Miners | Upgrade nodes for QR rules | Phase 1 activation
Exchanges | Implement QR withdrawals | Within 18 months of Phase 1
Hardware Wallets| Firmware updates for QR sigs | Before Phase 2
Light Clients | SPV proofs for QR scripts | Phase 3 readiness
== REFERENCES ==
- SPHINCS+ Implementation:
https://github.com/bitcoin-foundation/Quantum-Resistant-Bitcoin
- (FIPS 205) SLH-DSA:
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf
- Schnorr Signatures: BIP-0340
== COPYRIGHT ==
MIT License
---
This BIP presents an alternative quantum-resistant migration approach,
primarily distinguished by its extended transition timeline to facilitate
more comprehensive ecosystem adaptation.
Key features:
- Includes reference implementation of SPHINCS+-SHAKE256f
(SLH-DSA-SHAKE-256f)
- Provides comparative analysis against Bitcoin's current ECDSA scheme
- Detailed technical specifications:
https://github.com/bitcoin-foundation/Quantum-Resistant-Bitcoin
Formatting note: This BIP draft prioritizes technical accuracy over visual
polish. After incorporating feedback from this discussion, the final
version will be published to GitHub with proper Markdown formatting.
Feedback welcome from wallet developers, exchanges, miners, and security
researchers.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/4d6ecde7-e959-4e6c-a0aa-867af8577151n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8136 bytes --]
next reply other threads:[~2025-08-08 0:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-07 18:18 'Bitcoin Foundation' via Bitcoin Development Mailing List [this message]
2025-08-09 1:04 ` [bitcoindev] Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin 'conduition' via Bitcoin Development Mailing List
2025-08-09 5:26 ` 'Bitcoin Foundation' via Bitcoin Development Mailing List
2025-08-09 19:38 ` 'ArmchairCryptologist' via Bitcoin Development Mailing List
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4d6ecde7-e959-4e6c-a0aa-867af8577151n@googlegroups.com \
--to=bitcoindev@googlegroups.com \
--cc=contact@bitcoin.foundation \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox