Add draft BIP: pqcBitcoin Post-Quantum Cryptography for Bitcoin

bip-pqc-bitcoin.mediawiki

@@ -0,0 +1,162 @@
+<pre>
+BIP: ?
+Title: pqcBitcoin – Post-Quantum Cryptography for Bitcoin
+Author: Eid Al Subaie <[email protected]>
+Discussions-To: https://delvingbitcoin.org/t/implemented-post-quantum-cryptography-pqc-feature-into-bitcoin-core/1320
+Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-?
+Status: Draft
+Type: Standards Track
+Created: 2025-11-04
+License: MIT
+</pre>
+
+== Abstract ==
+
+This BIP introduces post-quantum cryptography (PQC) into Bitcoin to protect
+against future quantum computers that could break ECDSA/Schnorr signatures.
+It specifies hybrid signature and key-exchange schemes that combine classical
+and PQC algorithms, allowing an incremental, **soft-fork** upgrade path that is
+fully backward-compatible with existing nodes.
+
+== Motivation ==
+
+Quantum computers threaten the discrete-log security of ECDSA and Schnorr,
+enabling private-key extraction and counterfeit transactions.  
+Integrating PQC now:
+
+* future-proofs the chain before large-scale quantum hardware arrives,  
+* avoids a disruptive “flag-day” migration, and  
+* keeps Bitcoin competitive with other PQ-ready payment networks.
+
+== Specification ==
+
+=== 1. Key Format and Management ===
+
+* **PQC_KEY** – byte array (256–2048 bytes) plus algorithm ID metadata.  
+* **HYBRID_KEY** – concatenation of classical ECDSA public key and PQC public key.  
+* Wallets tag keys with algorithm identifiers and derivation paths (e.g., `m/86'/…/pqctype`).
+
+=== 2. Signature Scheme Support ===
+
+Supported PQC signature algorithms (Group 1):
+
+* SPHINCS+ (stateless hash-based)  
+* CRYSTALS-Dilithium (lattice-based)  
+* FALCON (compact lattice-based)  
+* SQIsign (experimental isogeny-based)
+
+**Hybrid signature** format is defined as:
+
+HYBRID_SIG = <length_of_ECDSA_signature (1 byte)> || <ECDSA_signature> || <PQC_signature> || <algorithm_id (1 byte)>
+
+Validation of hybrid signatures requires both classical and PQC signature verification to succeed independently.
+
+=== 3. Key Encapsulation Mechanisms (KEM) ===
+
+To enable quantum-resistant secure channel establishment (e.g., for encrypted wallet backups, P2P communication), this proposal integrates KEMs:
+
+* Kyber (lattice-based)  
+* FrodoKEM (LWE-based)  
+* NTRU (lattice-based)
+
+Shared secrets are derived via:
+
+SHARED_SECRET = HKDF(ECDH_SECRET || PQC_KEM_SECRET)
+
+
+An optional non-consensus opcode `OP_KEMNEGOTIATE` is introduced for use in scripts, enabling experimental KEM-based protocols without affecting consensus.
+
+=== 4. Backward Compatibility ===
+
+Backward compatibility is ensured through:
+
+* New SegWit output types (e.g., `p2pqcsig`, `p2hybridsig`) for PQC and hybrid scripts.  
+* Legacy nodes will ignore unknown scripts safely or treat PQC-only outputs as anyone-can-spend/unspendable.  
+* Hybrid keys/signatures allow transactions to be validated by both classical and PQC-aware nodes during the transition.
+
+=== 5. Node and Wallet Configuration Flags ===
+
+Nodes and wallets can enable and configure PQC features using the following command-line flags:
+
+-pqc=0|1 # Enable or disable all PQC features (default: 1)
+-pqcalgo=kyber,ntru,... # Specify enabled KEM algorithms
+-pqcsig=sphincs,dilithium,... # Specify enabled PQC signature algorithms
+-pqchybridkeys=0|1 # Enable hybrid key generation (default: 1)
+-pqchybridsig=0|1 # Enable hybrid signature verification (default: 1)
+
+
+=== 6. Fork Status ===
+
+This BIP is designed to be implemented as a **soft fork**, utilizing:
+
+* New SegWit output types to introduce PQC-enabled outputs without invalidating existing ones.  
+* Optional `OP_RETURN`-based script extensions for experimental features.  
+
+Activation mechanisms (e.g., BIP-8 or BIP-9 version bits signaling) will be proposed following testnet deployment and community consensus.
+
+=== 7. Test Vectors and Validation ===
+
+Test vectors are included covering:
+
+* PQC key generation across all supported algorithms.  
+* Creation and verification of PQC-only and hybrid signatures.  
+* Script-level validation of PQC signatures and hybrid transaction processing.  
+* Key encapsulation shared secret derivation and secure communication handshake.
+
+These are integrated into the Bitcoin Core test framework and located in `doc/pqc.md` and `test/pqc_*`.
+
+== Reference Implementation ==
+
+Reference implementation repository:  
+https://github.com/QBlockQ/pqc-bitcoin
+
+Features include:
+
+* PQC-enabled wallet and key management supporting quantum-safe address generation.  
+* Modified Bitcoin node with support for validating both ECDSA and PQC signatures.  
+* Test vectors and unit/integration tests validating PQC functionality.  
+* Implementation of hybrid signature schemes and KEM-based secure communication.
+
+== Rationale ==
+
+The transition to post-quantum cryptography is critical for Bitcoin’s long-term security. This proposal:
+
+* Uses hybrid signatures to enable incremental adoption without disrupting the existing network.  
+* Selects NIST finalist algorithms (Kyber, Dilithium) and mature PQC candidates for strong security and efficiency.  
+* Provides cryptographic agility for future algorithm upgrades as PQC research evolves.  
+* Ensures backward compatibility to avoid network forks or invalidation of legacy wallets.
+
+== Backward Compatibility ==
+
+The hybrid approach allows:
+
+* Existing ECDSA keys and signatures to remain valid.  
+* Gradual PQC adoption with simultaneous support for classical and quantum-resistant schemes.  
+* Legacy clients to safely ignore PQC-only scripts or treat them as anyone-can-spend/unspendable, while upgraded nodes enforce PQC validation.
+
+== Security Considerations ==
+
+Potential risks include:
+
+* **Downgrade attacks** if hybrid signatures are improperly verified — both classical and PQC parts must be validated.  
+* **Increased transaction size and blockspace usage** due to larger PQC signatures (notably SPHINCS+).  
+* **Cryptographic agility necessity** — algorithms must be reviewed and replaceable as PQC research matures.  
+* **Implementation complexity and bugs** require rigorous testing, peer review, and audits prior to mainnet deployment.
+
+== Test Vectors ==
+
+Comprehensive test vectors cover:
+
+* Generation and validation of keys for all PQC algorithms and hybrid keys.  
+* Signing and verification of transactions using PQC-only and hybrid signatures.  
+* Derivation of shared secrets for secure communication using KEMs.
+
+Vectors ensure cryptographic conformance and interoperability across node configurations.
+
+== License ==
+
+MIT
+
+
+
+