Hi all,
Regarding the recent discussion on commit-based approaches:
I agree with the general direction. Using commitments at each stage naturally prevents MITM-style substitution and eliminates replay attacks by construction. As several participants noted, this makes it a safer and more incremental starting point than moving directly to full quantum-safe signature
schemes.
One strength of beginning with a commit-and-reveal path is that it allows the ecosystem to develop a quantum-resilient vault mechanism and a broadly useful covenant primitive without introducing
premature trust assumptions. It also provides time to build a well-audited, performance-optimized
library for quantum-safe commitments before addressing the much more complex migration to PQ
signatures.
By comparison, quantum-safe signature libraries are not yet engineered anywhere near the maturity
of secp256k1, which is optimized to the point where timing side channels are extremely difficult to
exploit. Moving too quickly toward full PQ signatures seems unnecessary at this stage.
In parallel with this discussion, I have been working on a complementary framework focusing on the
verification bottlenecks and scalability issues of hash-based PQ signatures in Bitcoin. The design,
called **QRMVL (Quantum-Resilient Modular Verification Layer)**, aims to provide a soft-fork–compatible,
incremental path toward PQ validation while preserving current validation semantics.
Key components of QRMVL include:
• Hybrid hash-based signatures (stateful LMS + stateless SPHINCS+)
• A STARK-style Linear Hash Tree (LHT) enabling parallelizable Merkle verification
• Deterministic UTXO-bound LMS index to avoid state-reuse problems
• A fail-fast node pipeline designed to reduce PQC DoS exposure
• Tiered P2PQS levels (Lite / Standard / High)
• Fully backward-compatible witness extensions (v2/v3) with no txid modifications
Resources
---------
Full draft whitepaper (ver1.0):
https://github.com/karinCrypto/bitcoin-quantum-scaling/blob/main/whitepaper/QRMVL%20v1%20A%20First%20Edition%20Framework%20for%20Quantum-Resilient%20Verification%20in%20Bitcoin_.pdfRepository with examples and pseudocode (ver1.0):
https://github.com/karinCrypto/bitcoin-quantum-scalingRequest for feedback
--------------------
Given the ongoing discussion, I would appreciate feedback specifically on:
• Practicality of a soft-fork activation path
• Script versioning and witness layout implications
• Mempool policy considerations for PQ witness sizes
• Risks associated with deterministic LMS index derivation
• Expected impact on IBD and low-power validation hardware
Happy to refine or adjust the specification based on community input.
Best regards,
Karin Lee