From: Karin Eunji <karin.blockdev@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] QRMVL: Modular Verification Layer for Post-Quantum Hash-Based Signatures
Date: Tue, 23 Dec 2025 23:10:59 -0800 (PST) [thread overview]
Message-ID: <3f2c308b-13c2-47c9-b39e-861236601476n@googlegroups.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 3243 bytes --]
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_.pdf
Repository with examples and pseudocode (ver1.0):
https://github.com/karinCrypto/bitcoin-quantum-scaling
Request 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
--
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/3f2c308b-13c2-47c9-b39e-861236601476n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3680 bytes --]
reply other threads:[~2025-12-27 0:53 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=3f2c308b-13c2-47c9-b39e-861236601476n@googlegroups.com \
--to=karin.blockdev@gmail.com \
--cc=bitcoindev@googlegroups.com \
/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