Add BIP: QES2 – Hybrid PQC-based Digital Signature Algorithm

bip-newproposal.mediawiki

@@ -0,0 +1,140 @@
+<pre>
+  BIP: TBD
+  Title: PQ-Derived Schnorr: Hybrid Post-Quantum and Schnorr Signatures
+  Author: Author: [Caleb Lee] [email protected], [Justin Park] [email protected], [Eunice Lee] [email protected], [Sophia Shim] [email protected]
+  Status: Draft
+  Type: Standards Track
+  Created: 2025-07-02
+  License: BSD-2-Clause
+</pre>
+
+==Abstract==
+
+This BIP proposes '''PQ-Derived Schnorr''', a hybrid signature scheme that cryptographically binds a post-quantum signature (CRYSTALS-Dilithium) with Schnorr signatures (BIP340).  
+The scheme enables post-quantum secure transactions while maintaining compatibility with existing Bitcoin infrastructure.  
+
+Verification on-chain uses only a 64-byte Schnorr segment, while full Dilithium verification can be enforced by Tier-2/archive nodes.  
+The proposal introduces a new Taproot leaf version and an optional <code>OP_CHECKSIG_QES2</code> opcode to support hybrid verification.
+
+==Motivation==
+
+Quantum computing poses a fundamental threat to elliptic curve cryptography.  
+Shor’s algorithm renders discrete logarithm-based signatures (ECDSA, Schnorr) insecure.  
+
+NIST has standardized post-quantum signatures such as CRYSTALS-Dilithium, but direct integration into Bitcoin faces obstacles:
+* Large signature sizes (2–5 KB vs. 64 bytes for Schnorr).
+* Different verification algorithms requiring new opcodes.
+* Compatibility issues with Taproot and existing Bitcoin consensus.
+
+'''PQ-Derived Schnorr''' addresses these by:
+* Using Dilithium off-chain for quantum resistance.
+* Using Schnorr on-chain for efficiency and compatibility.
+* Binding both signature components cryptographically to prevent mix-and-match attacks.
+
+==Specification==
+
+===1. Key Generation===
+* Generate Dilithium key pair: <code>(pk_dil, sk_dil)</code>.
+* Generate Schnorr key pair: <code>(pk_sch, sk_sch)</code>.
+* Hybrid key: <code>pk = (pk_dil, pk_sch)</code>.
+
+===2. Signing===
+# Compute Dilithium signature <code>(c, z)</code> on message <code>m</code>.
+# Compute binding hash <code>h = H2(c || m)</code>.
+# Generate Schnorr signature <code>(R, s)</code> on <code>h</code>.
+# Hybrid signature: <code>σ = ((c, z), (R, s))</code>.
+
+===3. Verification===
+; Classical Mode (default)
+: Compute <code>h = H2(c || m)</code>.  
+: Verify <code>(R, s)</code> with <code>pk_sch</code>.  
+: Ensures lightweight on-chain validation (BIP340-compatible).  
+
+; Full Hybrid Mode (Tier-2)
+: Verify Dilithium <code>(c, z)</code> with <code>pk_dil</code>.  
+: Verify Schnorr <code>(R, s)</code> with <code>pk_sch</code>.  
+: Provides full post-quantum security.
+
+===4. Bitcoin Script Integration===
+* '''Taproot Leaf Extension'''  
+<syntaxhighlight lang="text">
+OP_1 <pubkey_combined> OP_CHECKSIG_HYBRID
+</syntaxhighlight>
+
+: <code>pubkey_combined = (pk_dil, pk_sch)</code>  
+: <code>OP_CHECKSIG_HYBRID</code>: verifies Schnorr on-chain, binds Dilithium off-chain.
+
+* '''Soft Fork Opcode'''  
+Introduce <code>OP_CHECKSIG_QES2</code>:  
+<syntaxhighlight lang="text">
+Stack: [signature, pubkey]
+Parse σ = ((c,z),(R,s)), pk = (pk_dil, pk_sch)
+h = H2(c||message)
+result = Schnorr.Verify(pk_sch, h, (R,s))
+Push result
+</syntaxhighlight>
+
+===5. Transaction Format===
+* Public key: 33 bytes (unchanged).  
+* Schnorr signature: 64 bytes (unchanged).  
+* Witness: includes Dilithium challenge vector <code>c</code>.  
+* Off-chain storage: full Dilithium <code>(c, z)</code>.  
+
+==Rationale==
+
+* '''Efficiency''': Only Schnorr (64 bytes, O(λ) ops) validated on-chain.  
+* '''Security''': Dilithium ensures quantum resistance; Schnorr ensures compatibility.  
+* '''Modularity''': Full verification optional for archive/Tier-2 nodes.  
+* '''Backward compatibility''': Transactions indistinguishable from Schnorr-only.
+
+==Comparison: QES2_ECDSA vs QES2_Schnorr==
+
+Early versions of QES2 proposed a hybrid with ECDSA. However:
+* ECDSA lacks native Taproot support and adds legacy script complexity.
+* Schnorr (BIP340) integrates seamlessly with Taproot.  
+* QES2_Schnorr eliminates the need to expose public keys directly in the script path.  
+* Key-path spend is intentionally disabled to ensure that PQC guarantees are always enforced via script path commitments.
+
+Thus, QES2_Schnorr is preferred as the long-term solution.
+
+==Taproot Script Path Considerations==
+
+* PQ-Derived Schnorr is integrated via Taproot leaves only.  
+* Key-path spend is disabled to avoid bypassing Dilithium binding.  
+* This ensures that all spends must go through the hybrid verification path, preserving post-quantum guarantees.  
+
+==Relation to P2QRH==
+
+P2QRH (Pay-to-Quantum-Resistant-Hash) has been proposed as a generic quantum-safe output format.  
+PQ-Derived Schnorr is compatible and potentially complementary:
+* P2QRH provides quantum-safe key commitment.  
+* PQ-Derived Schnorr provides quantum-safe transaction signatures.  
+* Together, they can form a layered defense against quantum adversaries.  
+
+==Backward Compatibility==
+
+* Legacy nodes interpret PQ-Derived Schnorr transactions as standard Schnorr.  
+* Dilithium verification is optional off-chain and does not affect consensus.  
+* New opcode <code>OP_CHECKSIG_QES2</code> can be activated via soft fork.  
+
+==Security Considerations==
+
+* Schnorr-only reliance collapses under quantum adversaries.  
+* Full Dilithium verification is necessary for PQC security.  
+* Binding <code>h = H2(c || m)</code> prevents mixing Schnorr and Dilithium signatures.  
+* Off-chain storage redundancy (e.g., IPFS, Arweave) is required for Dilithium proofs.  
+
+==Reference Implementation==
+
+* CRYSTALS-Dilithium v3 (NIST PQC Standard).  
+* BIP340 Schnorr (secp256k1).  
+* Prototype implementation in C/Python: [link if applicable].  
+
+==References==
+* BIP 340: Schnorr Signatures for secp256k1  
+* CRYSTALS-Dilithium, NIST PQC Standard  
+* J1729 Research Team, ''QES2_final.pdf'' (2025)  
+* [QES2 Research Paper (J1729Labs)][https://j1729labs.site/assets/QES2%20(2)_1756078951635-DfQQ4Pp_.pdf QES2 Research Paper (J1729Labs)]  
+* [QES2 Schnorr Whitepaper][https://pqc-function.xyz/assets/QES2_Schnorr__Algorithm_1751460046783.pdf QES2 Schnorr Whitepaper]
+
+