From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 26 Dec 2025 16:53:11 -0800 Received: from mail-qv1-f57.google.com ([209.85.219.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vZIYR-0003M0-65 for bitcoindev@gnusha.org; Fri, 26 Dec 2025 16:53:11 -0800 Received: by mail-qv1-f57.google.com with SMTP id 6a1803df08f44-88a32bf024csf78351836d6.2 for ; Fri, 26 Dec 2025 16:53:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1766796780; x=1767401580; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=Bg8p27th5uXAMDzvaVil/QCWhczZ9xrwLetmUlGi230=; b=XbVMMOSz0rC9aDjsCQXJ3fOiO9kyXCCzuebDKOJaabJbpAOVR5lrBRtQ+veD+rp2uC SUHGffzTqQMGUMthdpdjwNRlUn6OCHIMfkR5+Sg0XpT4wmQSHnfYWoi3SsPf54qAwOTv v4AuPNqpPcz3bPfwnrhzXCkeKqC2LMoTlDEO3D1rvdT1dOMTj5Dv7zAgE9tDjRQn7rIP 3LuSI2dMM8dD2La1qEKAe5YUqbN4ih0mYnZAHpArrMIrxLATNs07EwdC0moCvUbwVv9z HNUztuvDQpUSNqC6ZzxvZMIzguMW1XdA16llO+vHlUkFZ+iO0AVj8SfEpa/Zfjlp9oTM q2bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766796780; x=1767401580; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=Bg8p27th5uXAMDzvaVil/QCWhczZ9xrwLetmUlGi230=; b=WnXE2slnXhJKxjPfanTkZFzdF5ERAIyo6dKq+72ejAtKLGb2KeB553Xz1+PWFbRfOY 0jOFChCn3O9bYj6OfZ/r1PCSkQABakYGZcYPUV1CVf/9F52j6pGwV8chvAuSgZh+Cidx 17NSNociKaasUoPydVbTek4aD/oVcNEGCuKs8w7NmoTzze5faCRJUAnJY+9EM31Qf6Xe Nvz0NAEaUEPDyhndBqXKgEgNo92qlAfmG2Ulv+3lnKF6PZaFPvleFGCfpZZCrH4vr64b wUlbFw8rXQcoiXb2EtXxgNFfpAckGgpjZbeQcNsdD+dPRg6mg9zBWejv/cDHXp0lJ6ns NDjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766796780; x=1767401580; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=Bg8p27th5uXAMDzvaVil/QCWhczZ9xrwLetmUlGi230=; b=ovetGruT+5St24Jbp6BhRcb0j+pHzowtbSYYhhhZOAmVgm0BmJlN55qxDMUiV4mNOy 80hUgjml2ihrLGOGr+G7ht1z/Gy+k9IXvQVyxG6YzIfcmcoL1R3iwfHm5E9m1SFKrWDc exrBDOvtZmIv+ZM9G2h2VajwTuQB4gNpHYN4m9U9SijNoS+WhZllCT799ZtvcE420QJB S/qAlx6fwHptOrwTnuaRCjabw2RI9BIE+XL1MFL9YeV9zcXyU861ZfIOfC8ivbGL/PWY 5/WWfZkz7+y2MRKqcOo0kenn3R58EARV6PMCislJjag7qBsOdhBxSPLJapg31dzf1t51 ILoQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWT+QDNRyCiGUIe98BkXQdAw4mqJk2208P4JXR9gMSHy+cY2hQM3C5rPyzOSoW3PNupEDEJ7Z0wyRi5@gnusha.org X-Gm-Message-State: AOJu0YxMEwSVkER0RxXkVH2o2JYVZ5bsYoHnD38mytadWk9wnZSV3myN 4KfH0GvDuvMaPTAknuKiChy232CRkWW2DwLJNjCZlc5aVubVB82QhUoI X-Google-Smtp-Source: AGHT+IE6hmtqL/jy+XA6fx3T7HmvIHOQFF+5yQ5VCzxtg1BXd8qdJAld2znDYpU8NXZflbEzbxRhAA== X-Received: by 2002:a0c:ed2d:0:b0:888:6f8d:8e93 with SMTP id 6a1803df08f44-88d8203ebf3mr310632266d6.21.1766796780132; Fri, 26 Dec 2025 16:53:00 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWYJwUY6IiyfxIF5ws2ITeYfkiMLs0PQmM77bEkKN+v80Q==" Received: by 2002:a05:6214:190d:b0:88f:cb33:421b with SMTP id 6a1803df08f44-88fcb3343a1ls63502476d6.2.-pod-prod-06-us; Fri, 26 Dec 2025 16:52:53 -0800 (PST) X-Received: by 2002:a05:620a:4412:b0:8b2:767c:31ab with SMTP id af79cd13be357-8c08fab7cbbmr3596691485a.60.1766796773653; Fri, 26 Dec 2025 16:52:53 -0800 (PST) Received: by 2002:a05:690c:4a92:b0:786:6c46:840 with SMTP id 00721157ae682-78fb39c9e68ms7b3; Tue, 23 Dec 2025 23:11:01 -0800 (PST) X-Received: by 2002:a05:690e:bcb:b0:644:7b34:7bd2 with SMTP id 956f58d0204a3-6466a8c8a71mr12738338d50.75.1766560260047; Tue, 23 Dec 2025 23:11:00 -0800 (PST) Date: Tue, 23 Dec 2025 23:10:59 -0800 (PST) From: Karin Eunji To: Bitcoin Development Mailing List Message-Id: <3f2c308b-13c2-47c9-b39e-861236601476n@googlegroups.com> Subject: [bitcoindev] QRMVL: Modular Verification Layer for Post-Quantum Hash-Based Signatures MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_205928_28373553.1766560259702" X-Original-Sender: karin.blockdev@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_205928_28373553.1766560259702 Content-Type: multipart/alternative; boundary="----=_Part_205929_1691687016.1766560259702" ------=_Part_205929_1691687016.1766560259702 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, Regarding the recent discussion on commit-based approaches: =20 I agree with the general direction. Using commitments at each stage=20 naturally prevents MITM-style substitution and eliminates replay attacks by= =20 construction. As several participants noted, this makes it a safer and more= =20 incremental starting point than moving directly to full quantum-safe=20 signature schemes. One strength of beginning with a commit-and-reveal path is that it allows= =20 the ecosystem to develop a quantum-resilient vault mechanism and a broadly= =20 useful covenant primitive without introducing premature trust assumptions. It also provides time to build a well-audited,= =20 performance-optimized library for quantum-safe commitments before addressing the much more=20 complex migration to PQ signatures. By comparison, quantum-safe signature libraries are not yet engineered=20 anywhere near the maturity of secp256k1, which is optimized to the point where timing side channels=20 are extremely difficult to exploit. Moving too quickly toward full PQ signatures seems unnecessary at= =20 this stage. In parallel with this discussion, I have been working on a complementary=20 framework focusing on the verification bottlenecks and scalability issues of hash-based PQ signatures= =20 in Bitcoin. The design, called **QRMVL (Quantum-Resilient Modular Verification Layer)**, aims to=20 provide a soft-fork=E2=80=93compatible, incremental path toward PQ validation while preserving current validation= =20 semantics. Key components of QRMVL include: =E2=80=A2 Hybrid hash-based signatures (stateful LMS + stateless SPHINCS+) = =20 =E2=80=A2 A STARK-style Linear Hash Tree (LHT) enabling parallelizable Merk= le=20 verification =20 =E2=80=A2 Deterministic UTXO-bound LMS index to avoid state-reuse problems = =20 =E2=80=A2 A fail-fast node pipeline designed to reduce PQC DoS exposure =20 =E2=80=A2 Tiered P2PQS levels (Lite / Standard / High) =20 =E2=80=A2 Fully backward-compatible witness extensions (v2/v3) with no txid= =20 modifications =20 Resources=20 --------- Full draft whitepaper (ver1.0): =20 https://github.com/karinCrypto/bitcoin-quantum-scaling/blob/main/whitepaper= /QRMVL%20v1%20A%20First%20Edition%20Framework%20for%20Quantum-Resilient%20V= erification%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: =E2=80=A2 Practicality of a soft-fork activation path =20 =E2=80=A2 Script versioning and witness layout implications =20 =E2=80=A2 Mempool policy considerations for PQ witness sizes =20 =E2=80=A2 Risks associated with deterministic LMS index derivation =20 =E2=80=A2 Expected impact on IBD and low-power validation hardware =20 Happy to refine or adjust the specification based on community input. Best regards, =20 Karin Lee =20 --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 3f2c308b-13c2-47c9-b39e-861236601476n%40googlegroups.com. ------=_Part_205929_1691687016.1766560259702 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all,

Regarding the recent discussion on commit-based approach= es: =C2=A0
I agree with the general direction. Using commitments at ea= ch stage naturally prevents MITM-style substitution and eliminates replay a= ttacks by construction. As several participants noted, this makes it a safe= r and more incremental starting point than moving directly to full quantum-= safe signature
schemes.

One strength of beginning with a co= mmit-and-reveal path is that it allows the ecosystem to develop a quantum-r= esilient vault mechanism and a broadly useful covenant primitive without in= troducing
premature trust assumptions. It also provides time to build = a well-audited, performance-optimized
library for quantum-safe commitm= ents before addressing the much more complex migration to PQ
signature= s.

By comparison, quantum-safe signature libraries are not yet e= ngineered anywhere near the maturity
of secp256k1, which is optimized = to the point where timing side channels are extremely difficult to
exp= loit. Moving too quickly toward full PQ signatures seems unnecessary at thi= s stage.

In parallel with this discussion, I have been working o= n a complementary framework focusing on the
verification bottlenecks a= nd scalability issues of hash-based PQ signatures in Bitcoin. The design,called **QRMVL (Quantum-Resilient Modular Verification Layer)**, aims t= o provide a soft-fork=E2=80=93compatible,
incremental path toward PQ v= alidation while preserving current validation semantics.

Key com= ponents of QRMVL include:
=E2=80=A2 Hybrid hash-based signatures (stat= eful LMS + stateless SPHINCS+) =C2=A0
=E2=80=A2 A STARK-style Linear H= ash Tree (LHT) enabling parallelizable Merkle verification =C2=A0
=E2= =80=A2 Deterministic UTXO-bound LMS index to avoid state-reuse problems =C2= =A0
=E2=80=A2 A fail-fast node pipeline designed to reduce PQC DoS exp= osure =C2=A0
=E2=80=A2 Tiered P2PQS levels (Lite / Standard / High) = =C2=A0
=E2=80=A2 Fully backward-compatible witness extensions (v2/v3) = with no txid modifications =C2=A0

Resources=C2=A0
---------=
Full draft whitepaper (ver1.0): =C2=A0
https://github.com/karinC= rypto/bitcoin-quantum-scaling/blob/main/whitepaper/QRMVL%20v1%20A%20First%2= 0Edition%20Framework%20for%20Quantum-Resilient%20Verification%20in%20Bitcoi= n_.pdf

Repository with examples and pseudocode=C2=A0(ver1.0):https://github.com/karinCrypto/bitcoin-quantum-scaling

Reques= t for feedback
--------------------
Given the ongoing discussion,= I would appreciate feedback specifically on:

=E2=80=A2 Practica= lity of a soft-fork activation path =C2=A0
=E2=80=A2 Script versioning= and witness layout implications =C2=A0
=E2=80=A2 Mempool policy consi= derations for PQ witness sizes =C2=A0
=E2=80=A2 Risks associated with = deterministic LMS index derivation =C2=A0
=E2=80=A2 Expected impact on= IBD and low-power validation hardware =C2=A0

Happy to refine or= adjust the specification based on community input.

Best regards= , =C2=A0
Karin Lee=C2=A0=C2=A0

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/3f2c308b-13c2-47c9-b39e-861236601476n%40googlegroups.com.
------=_Part_205929_1691687016.1766560259702-- ------=_Part_205928_28373553.1766560259702--