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

j1729labs commented at 8:03 am on April 18, 2025: none

Summary: This pull request introduces a new Bitcoin Improvement Proposal (BIP) for QES2, a hybrid digital signature algorithm that combines post-quantum cryptography (PQC) with traditional ECDSA. The proposal aims to address the potential vulnerabilities posed by quantum computing while preserving backward compatibility with existing Bitcoin infrastructure.

Details:

Abstract: QES2 leverages a dual-signature mechanism to incorporate both a post-quantum signature and a classical ECDSA signature into Bitcoin transactions.

Motivation: With the emerging threat of quantum computers, classical cryptographic methods may become vulnerable. QES2 presents a transitional solution that enhances security during the shift towards quantum-safe systems.

Specification: The BIP outlines the structure, key generation, signing, and verification methods for the hybrid scheme.

Rationale: The hybrid approach ensures that if one signature method is compromised, the other still provides protection, offering a balanced trade-off between security and backward compatibility.

Reference Implementation: A reference implementation will be linked later for further review and testing.

Create bip-newproposal.mediawiki 7f9114f662

Update bip-newproposal.mediawiki 5414a5c56a

Update bip-newproposal.mediawiki 3a34446077

Update bip-newproposal.mediawiki 28c2aa8a7f

Update bip-newproposal.mediawiki 11a563aeaf

cryptoquick commented at 3:29 pm on April 18, 2025: none

Would it make sense to just add QES2 support to BIP-360?

in bip-newproposal.mediawiki:330 in 11a563aeaf outdated

325+Taproot Compatibility
326+--------------------
327+
328+QES2 can be integrated with BIP-340 (Taproot) by:
329+
330+1. Using the QES2-based signature in place of the Schnorr signature

cryptoquick commented at 3:49 pm on April 18, 2025:

You specify QES2 as ECDSA, but ECDSA doesn’t support all that Schnorr does. This seems like a step backwards that could break Taproot compatibility. Would it not make sense to implement QES2 with Schnorr and remove mention of ECDSA?

murchandamus commented at 1:08 pm on April 23, 2025:

Like @cryptoquick, I’m confused that this proposal focuses only on ECDSA signatures, when about 1/3 of all existing UTXOs use the P2TR output type that employs BIP340 signatures. Could you please provide rationale for this approach and further address the implications for existing P2TR outputs intended to be spent via the scriptpath?

j1729labs commented at 2:38 am on May 12, 2025:

You specify QES2 as ECDSA, but ECDSA doesn’t support all that Schnorr does. This seems like a step backwards that could break Taproot compatibility. Would it not make sense to implement QES2 with Schnorr and remove mention of ECDSA?

I am considering the overall direction of my research as follows:

Initially, I aim to provide a hybrid signature scheme.

Ultimately, I plan to propose a PQC-based signature scheme optimized for Bitcoin.

The QES2 scheme I’m presenting is a hybrid dual-signature model that combines ECDSA and Delicium. The role of ECDSA is to offer a structure that is well-suited for existing Bitcoin systems. As you mentioned, one might question whether this approach is vulnerable to attacks exploiting the Schnorr algorithm. However, even if the ECDSA signature is verified, the Delicium-related verification is not completed, so such concerns do not materialize.

Furthermore, we are in an advanced stage of R&D on a model that mitigates protocol-level vulnerabilities of the Schnorr algorithm in Isogeny-based PQC, one of the NIST Round 3 finalists. We are considering applying this improved model as the final design. (Isogeny-based PQC has the advantage of a small key size, and if the Schnorr-related vulnerabilities are addressed, it becomes a very strong candidate.)

j1729labs commented at 3:43 am on May 12, 2025:

Thank you for the great question. Let me clarify the intention behind QES2 in more detail.

First, QES2 is a general-purpose dual-signature scheme initially designed by combining ECDSA and our Dilithium-based post-quantum signature component. The reason we included ECDSA was to ensure compatibility with the existing Bitcoin infrastructure—especially since many legacy UTXOs and current wallet software still rely on ECDSA. Moreover, in the early stages of our research, we chose to develop on top of ECDSA to maintain control over Dilithium signatures and to align with digital signature types commonly used in the financial sector. We are also exploring the expansion to Schnorr signatures and actively working on methods to control and implement signatures more efficiently. Therefore, this proposal is part of a research roadmap and will be developed step-by-step.

That said, as you rightly pointed out, about one-third of UTXOs utilize the P2TR output type that uses BIP340 (Schnorr) signatures. From a BIP-level integration perspective, it indeed makes more sense to consider Schnorr-based design, and we are currently evaluating this actively. We plan to provide a Schnorr-variant of QES2 in the near future.

Our research roadmap is as follows:

In the short term, we aim to provide an ECDSA + Dilithium hybrid signature model that can be practically deployed and is compatible with existing infrastructure.
In the long term, our goal is to propose a post-quantum signature scheme optimized for Bitcoin, likely based on isogeny-based cryptography.

We are currently developing an isogeny-based signature system that addresses known protocol vulnerabilities (as seen in NIST’s Round 3 competition). We believe this approach offers strong long-term security with small key sizes and resistance to quantum attacks.

To summarize:

We initially adopted ECDSA for general applicability and control over Dilithium.
We are actively researching integration with Schnorr-based signatures.
Our ultimate goal is not to finalize a hybrid scheme, but to fully transition to a PQC-based signature model.

Thank you again for your thoughtful feedback—we see this as a valuable opportunity to ensure QES2 evolves to meet both current and future Bitcoin use cases.

in bip-newproposal.mediawiki:581 in 11a563aeaf outdated

576+
577+1. **Dilithium Security**: The Dilithium signature is secure against quantum adversaries under the hardness assumptions of Module-LWE and Module-SIS problems.
578+
579+2. **ECDSA Security**: While vulnerable to quantum attacks, ECDSA remains secure against classical adversaries.
580+
581+3. **Binding Property**: The ECDSA signature validates the Dilithium signature, creating a binding that requires breaking both schemes or finding hash collisions to forge.

cryptoquick commented at 3:53 pm on April 18, 2025:

Why is it necessary to sign the PQ signature? Can’t it just be included separately and still benefit from the same guarantees if committed to in the same address as BIP-360 does?

j1729labs commented at 3:46 am on May 12, 2025:

My primary concern — and the motivation for this work — is that quantum computing poses a real and growing threat to the cryptographic foundations of Bitcoin and other blockchains. In response, we are actively exploring ways to strengthen these systems with post-quantum cryptography.

In the case of QES2, simply appending a PQ signature is not sufficient, as it does not provide a verifiable commitment to the signature within Bitcoin’s existing validation logic. By signing the PQ signature with a currently supported scheme such as ECDSA or Schnorr, we ensure that the signature is cryptographically bound and verifiable in the current infrastructure, without requiring consensus changes or new opcodes.

This hybrid dual-signature design provides a practical path for backward compatibility while introducing post-quantum security guarantees. Ultimately, our goal is to transition toward a fully post-quantum signature scheme, but this intermediate approach offers a secure and deployable solution today.

cryptoquick commented at 3:54 pm on April 18, 2025: none

Just some questions

jonatack commented at 5:54 pm on April 18, 2025: member

Hi @j1729labs, have you posted about this to the bitcoin-dev mailing list at https://groups.google.com/g/bitcoindev? Please refer to https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#user-content-BIP_workflow for details. Thanks!

jonatack added the label New BIP on Apr 18, 2025

murchandamus commented at 11:42 pm on April 18, 2025: contributor

Please take another look at the formatting. The document’s syntax doesn’t seem to be MediaWiki, and especially the preamble does currently not conform to the required formatting.

murchandamus added the label PR Author action required on Apr 18, 2025

in bip-newproposal.mediawiki:129 in 11a563aeaf outdated

124+- ``OP_QES2_CHECKSIG`` is a new opcode that verifies the entire chained signature scheme
125+
126+New Opcode
127+~~~~~~~~~~
128+
129+We introduce a new opcode, tentatively assigned as ``OP_QES2_CHECKSIG (0xba)``, that performs verification of the hybrid QES2 signature by checking both the ECDSA signature (which validates the PQC signature) and the Dilithium signature itself.

murchandamus commented at 1:02 pm on April 23, 2025:

Opcode 186 was designated OP_CHECKSIGADD by BIP 342.

in bip-newproposal.mediawiki:421 in 11a563aeaf outdated

416+======================
417+
418+This BIP maintains backward compatibility through several mechanisms:
419+
420+1. **Opt-in Deployment**: QES2 addresses are distinct from traditional addresses
421+2. **Traditional Scripts**: Existing P2PKH, P2SH, P2WPKH, and P2WSH scripts continue to function normally

murchandamus commented at 1:10 pm on April 23, 2025:

As mentioned, this does not address P2TR outputs which make up about 1/3 of all existing UTXOs.

in bip-newproposal.mediawiki:594 in 11a563aeaf outdated

589+   Where Adv_X(A) represents the advantage of an adversary A against scheme X.
590+
591+Acknowledgments
592+==============
593+
594+This proposal builds on the work of several other BIPs, including BIP-340, BIP-341, and BIP-342 (Taproot), and incorporates concepts from ongoing research in post-quantum cryptography for blockchains.

murchandamus commented at 1:12 pm on April 23, 2025:

I’m confused that this proposal mentions BIP 340 several times, but insufficiently addresses BIP 340 signatures.

in bip-newproposal.mediawiki:117 in 11a563aeaf outdated

112+
113+This BIP introduces a new script template:
114+
115+.. code-block::
116+
117+   <pq_signature_push> <ecdsa_signature_push> <pubkey_push> OP_QES2_CHECKSIG

murchandamus commented at 1:14 pm on April 23, 2025:

Please provide more detail how this new script template would be used in transactions. How is it split between output script, input script, witness section, or a newly introduced transaction section? How would this transaction be serialized? If it is intended to be a soft fork, what mechanism is used to allow unupgraded nodes to accept transactions using this signature scheme?

in bip-newproposal.mediawiki:11 in 11a563aeaf outdated

 6+:Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXXX
 7+:Status: Draft
 8+:Type: Standards Track
 9+:Created: 2025-04-18
10+:License: BSD-2-Clause
11+:Requires: 340, 341, 342

murchandamus commented at 1:30 pm on April 23, 2025:

The document must start with the preamble adhering to the required format. Beyond the formatting needing to be amended, the title is too long and the authors need to be on separate lines with the format Name <addr@dom.ain>.

murchandamus changes_requested

murchandamus commented at 1:30 pm on April 23, 2025: contributor

Thanks for your submission. The content of this document shows potential, however it is still lacking some important details (see other review comments). It also currently does not meet the formatting requirements for the BIPs process. Please fix the formatting to conform to the MediaWiki syntax and amend the Preamble to use preformatted text with the required formatting.

As this document is currently not ready to be merged, I’m turning it into a Draft pull request at this time.

murchandamus marked this as a draft on Apr 23, 2025

j1729labs commented at 3:50 am on May 12, 2025: none

Hi @j1729labs, have you posted about this to the bitcoin-dev mailing list at https://groups.google.com/g/bitcoindev? Please refer to https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#user-content-BIP_workflow for details. Thanks!

Thank you for the guidance. I will make sure to post this to the mailing list.

murchandamus commented at 10:23 pm on June 20, 2025: contributor

Hi @j1729labs, are you still working on this proposal?

j1729labs commented at 0:18 am on June 21, 2025: none

Hi @j1729labs, are you still working on this proposal?

Based on your advice, I intend to deliver meaningful outcomes and build upon them to develop further proposals. Thank you for your support.

j1729labs commented at 4:40 am on July 7, 2025: none

To @murchandamus, @cryptoquick, and @jonatack,

First of all, thank you very much for your valuable advice. Initially, we focused on developing general-purpose technologies, but your insights helped us recognize the importance of building solutions tailored specifically for Bitcoin.

Based on this, we extended our original QES2 framework into a hybrid signature scheme incorporating the Schnorr algorithm. Considering existing protocols, the implementation was not particularly difficult. As a result, we split QES2 into two variants — QES2_ECDSA and QES2_Schnorr — and have completed the corresponding whitepaper.

[QES2_Schnorr Architecture and Design]

A hybrid signature algorithm that performs the first signature using Dilion (an improved version of Dilithium) and the second signature using Schnorr.

The Dilion signature is generated off-chain, and the resulting signature is wrapped with a Schnorr signature so that Bitcoin can perform verification using its native Schnorr support.

[Benefits of QES2_Schnorr]

It is structured to enable seamless compatibility with Bitcoin’s Schnorr verification without additional processing of the off-chain Dilion signature.

Although the total signature size is about 4000 bytes (similar to Dilion), only a 64-byte Schnorr signature is used on-chain, achieving lightweight on-chain performance.

The scheme maintains post-quantum security due to its structural integration with Dilion.

We have built a website to provide access to the whitepaper and allow you to try out the demo.

🔗 Website: https://pqc-function.xyz/

About the site: It introduces Dilion, a post-quantum digital signature algorithm (an enhanced version of Dilithium), as well as hybrid schemes QES2_Schnorr and QES2_ECDSA, and the zk-FIDNA zero-knowledge proof algorithm. The platform also provides engine APIs as a SaaS service.

cryptoquick commented at 7:30 am on July 7, 2025: none

If you’re still committing to a secp256k1 key, which is what you’d need to do if you use a P2TR address, you’re still vulnerable against quantum attackers. I’m not sure what this gets you without key path spends disabled.

j1729labs commented at 8:22 am on July 7, 2025: none

If you’re still committing to a secp256k1 key, which is what you’d need to do if you use a P2TR address, you’re still vulnerable against quantum attackers. I’m not sure what this gets you without key path spends disabled.

QES2_Schnorr: A Hybrid Signature Scheme that Achieves Post-Quantum Security in Taproot Without Public Key Exposure

Bitcoin’s Taproot (P2TR) was introduced to simplify signature structures, improve privacy, and enable greater scripting capabilities. It utilizes the Schnorr signature algorithm as its core. However, Taproot still requires the commitment of a secp256k1-based public key on-chain, which becomes a security liability in a post-quantum context, where quantum computers could eventually derive private keys from exposed public keys.

To address this structural vulnerability, we introduce QES2_Schnorr, a hybrid signature scheme designed to retain full Taproot compatibility while providing post-quantum resilience without revealing the committed public key.

QES2_Schnorr Architecture Overview

QES2_Schnorr generates signatures through two distinct phases:

Primary Signature (Off-chain, PQC-based) → A signature is first generated using Dilion, a post-quantum secure scheme derived from Dilithium. This ensures quantum-resistant forgery protection at the origin of the transaction.
Secondary Signature (On-chain, Schnorr-based) → The Dilion signature is then treated as the message input for generating a Schnorr signature. This final Schnorr signature is what gets included and verified on-chain under a Taproot (P2TR) address.

In this model, while the address remains in Taproot format (bc1p...), the secp256k1 public key is never directly revealed on-chain. The only data accessible to the blockchain is the Schnorr signature itself, which encapsulates the quantum-secure Dilion signature. As a result, even in the presence of quantum adversaries, an attack would require breaking the underlying PQ signature scheme—a computationally infeasible task.

cryptoquick commented at 8:25 am on July 7, 2025: none

Whatever Taproot address is committed to, that corresponds to a valid private key, no matter if it’s part of your scheme or not. A CRQC running Shor’s could absolutely compromise the funds in that address if the key path spend is not disabled.

j1729labs commented at 8:37 am on July 7, 2025: none

Whatever Taproot address is committed to, that corresponds to a valid private key, no matter if it’s part of your scheme or not. A CRQC running Shor’s could absolutely compromise the funds in that address if the key path spend is not disabled.

Thanks for the insight — your point about Taproot committing to a secp256k1 key is absolutely valid. However, in the QES2_Schnorr scheme we’re working on, key path spend is deliberately disabled. So although the Taproot address includes a commitment to a classical key, it’s never used to authorize spending. This effectively removes the classical path that a quantum attacker would exploit.

Instead, spending is enforced entirely through the script path, where we include post-quantum signatures like Dilithium in the MAST structure. QES2_Schnorr isn’t about relying solely on Schnorr — it’s used selectively within a hybrid architecture that combines compatibility (with Bitcoin’s existing stack) and forward-looking quantum resistance. So in practice, the design stays secure against CRQC, while remaining deployable in today’s ecosystem.

I would appreciate it if you could understand that, for now, this primarily represents the cryptographic approach required for such development, rather than the overall system architecture.

cryptoquick commented at 8:42 am on July 7, 2025: none

That’s not quite what the BIP says: https://github.com/bitcoin/bips/pull/1830/files#diff-43c37a8806b41fe5af6e8835d2cb9c00e662fb80228bdb8a0f3ea372b086959fR332-R342

Also, P2QRH is being trimmed down quite a bit in the recent edits. If you want, you can review the changes and see if you might want to make it a dependency of this BIP: https://github.com/cryptoquick/bips/pull/21

j1729labs commented at 8:58 am on July 7, 2025: none

That’s not quite what the BIP says: https://github.com/bitcoin/bips/pull/1830/files#diff-43c37a8806b41fe5af6e8835d2cb9c00e662fb80228bdb8a0f3ea372b086959fR332-R342

Also, P2QRH is being trimmed down quite a bit in the recent edits. If you want, you can review the changes and see if you might want to make it a dependency of this BIP: cryptoquick#21

Yes, I understand! Actually, I haven’t made the changes yet, but I’m planning to revise the BIP proposal based on the advice you kindly shared, @cryptoquick. I just wanted to leave a comment first to show that I’m taking your suggestions seriously and planning to make improvements!

I was hoping for a bit of encouragement, so I was a little sad to get corrected instead. 😅 But I appreciate the feedback — I’ll make sure to review everything more thoroughly.

samuelmanzanera commented at 12:07 pm on July 7, 2025: none

That’s not quite what the BIP says: https://github.com/bitcoin/bips/pull/1830/files#diff-43c37a8806b41fe5af6e8835d2cb9c00e662fb80228bdb8a0f3ea372b086959fR332-R342 Also, P2QRH is being trimmed down quite a bit in the recent edits. If you want, you can review the changes and see if you might want to make it a dependency of this BIP: cryptoquick#21

Yes, I understand! Actually, I haven’t made the changes yet, but I’m planning to revise the BIP proposal based on the advice you kindly shared, @cryptoquick. I just wanted to leave a comment first to show that I’m taking your suggestions seriously and planning to make improvements!

I was hoping for a bit of encouragement, so I was a little sad to get corrected instead. 😅 But I appreciate the feedback — I’ll make sure to review everything more thoroughly.

I think it is totally okay that the changes aren’t made yet; just showing you’re engaged and planning to improve is already a big step forward. It’s clear you’re putting genuine effort into this, and that kind of attitude is exactly what makes collaboration productive and rewarding. The approach for the hybrid solution of post quantum and still relying on ECDSA seems interesting and promising. Keep going, I’m sure your work here would be appreciated!

cryptoquick commented at 3:34 pm on July 9, 2025: none

I’ll admit I would be more encouraging if I understood it better. I still don’t really understand the why behind this. Please be sure to do your best to explain, in simple but comprehensive terms, why this necessary. I also invite you to find flaws in P2QRH as it stands now, or how this might be capable of being integrated into that in some way.

murchandamus commented at 11:09 pm on August 8, 2025: contributor

Hey @j1729labs, it has been about four months since this pull request was opened. My understanding is that you are working on the implementation corresponding to this proposal, but this proposal itself has not seen any updates since then. We prefer pull requests to be opened against this repository when a proposal is close to ready for publication and actively being developed.

It doesn’t make sense to me for this pull request to be open, if the proposal is not getting updates. Could you please share your timeline when you expect work on this proposal to pick up? If this is not expected to be updated within the next month, perhaps it would make more sense if the pull request were closed for now and you would submit your document at a later time when you are focused on it.

Update bip-newproposal.mediawiki 74fc27ef19

Update bip-newproposal.mediawiki ce013f5c6a

j1729labs commented at 5:33 am on September 8, 2025: none

Hey @j1729labs, it has been about four months since this pull request was opened. My understanding is that you are working on the implementation corresponding to this proposal, but this proposal itself has not seen any updates since then. We prefer pull requests to be opened against this repository when a proposal is close to ready for publication and actively being developed.

It doesn’t make sense to me for this pull request to be open, if the proposal is not getting updates. Could you please share your timeline when you expect work on this proposal to pick up? If this is not expected to be updated within the next month, perhaps it would make more sense if the pull request were closed for now and you would submit your document at a later time when you are focused on it.

Thank you for the feedback. First of all, I apologize for the delay over the past period. I believed it would be more meaningful to complete the results and proceed with a paper submission before updating, and that work has now been completed and the updates are in place. I will make sure to take your suggestion into account and manage this more appropriately moving forward.

Update bip-newproposal.mediawiki bfd2c1b06d

in bip-newproposal.mediawiki:4 in bfd2c1b06d

0@@ -0,0 +1,140 @@
1+<pre>
2+  BIP: TBD
3+  Title: PQ-Derived Schnorr: Hybrid Post-Quantum and Schnorr Signatures
4+  Author: Author: [Caleb Lee] director@j1729labs.online, [Justin Park] justin7361@j1729labs.online, [Eunice Lee] cuspro0103@j1729labs.online, [Sophia Shim] zypo1015@j1729labs.online

murchandamus commented at 9:17 pm on September 10, 2025:

“If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions.”

0  Author: Caleb Lee <director@j1729labs.online>
1          Justin Park <justin7361@j1729labs.online>
2          Eunice Lee <cuspro0103@j1729labs.online>
3          Sophia Shim <zypo1015@j1729labs.online>

in bip-newproposal.mediawiki:3 in bfd2c1b06d

0@@ -0,0 +1,140 @@
1+<pre>
2+  BIP: TBD
3+  Title: PQ-Derived Schnorr: Hybrid Post-Quantum and Schnorr Signatures

murchandamus commented at 9:18 pm on September 10, 2025:

The title is required to be 44 characters or less (https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#bip-header-preamble)

in bip-newproposal.mediawiki:43 in bfd2c1b06d

38+* Generate Schnorr key pair: <code>(pk_sch, sk_sch)</code>.
39+* Hybrid key: <code>pk = (pk_dil, pk_sch)</code>.
40+
41+===2. Signing===
42+# Compute Dilithium signature <code>(c, z)</code> on message <code>m</code>.
43+# Compute binding hash <code>h = H2(c || m)</code>.

murchandamus commented at 9:23 pm on September 10, 2025:

What is “H2”?

in bip-newproposal.mediawiki:49 in bfd2c1b06d

44+# Generate Schnorr signature <code>(R, s)</code> on <code>h</code>.
45+# Hybrid signature: <code>σ = ((c, z), (R, s))</code>.
46+
47+===3. Verification===
48+; Classical Mode (default)
49+: Compute <code>h = H2(c || m)</code>.

murchandamus commented at 9:24 pm on September 10, 2025:

Where does the verifier get “c” from if the Dilithium signature is kept off-chain?

in bip-newproposal.mediawiki:64 in bfd2c1b06d

59+* '''Taproot Leaf Extension'''  
60+<syntaxhighlight lang="text">
61+OP_1 <pubkey_combined> OP_CHECKSIG_HYBRID
62+</syntaxhighlight>
63+
64+: <code>pubkey_combined = (pk_dil, pk_sch)</code>

murchandamus commented at 9:26 pm on September 10, 2025:

This syntax does not appear to be available in mediawiki:

in bip-newproposal.mediawiki:75 in bfd2c1b06d

70+Stack: [signature, pubkey]
71+Parse σ = ((c,z),(R,s)), pk = (pk_dil, pk_sch)
72+h = H2(c||message)
73+result = Schnorr.Verify(pk_sch, h, (R,s))
74+Push result
75+</syntaxhighlight>

murchandamus commented at 9:27 pm on September 10, 2025:

Does not render as intended:

in bip-newproposal.mediawiki:81 in bfd2c1b06d

76+
77+===5. Transaction Format===
78+* Public key: 33 bytes (unchanged).  
79+* Schnorr signature: 64 bytes (unchanged).  
80+* Witness: includes Dilithium challenge vector <code>c</code>.  
81+* Off-chain storage: full Dilithium <code>(c, z)</code>.

murchandamus commented at 9:29 pm on September 10, 2025:

Could you be more specific on the mechanism per which the Bitcoin nodes achieve data availability for the Dilithium signature if it is stored off-chain? Nodes cannot verify the signature without access to the full data.

in bip-newproposal.mediawiki:116 in bfd2c1b06d

111+* PQ-Derived Schnorr provides quantum-safe transaction signatures.  
112+* Together, they can form a layered defense against quantum adversaries.  
113+
114+==Backward Compatibility==
115+
116+* Legacy nodes interpret PQ-Derived Schnorr transactions as standard Schnorr.

murchandamus commented at 9:32 pm on September 10, 2025:

Could you elaborate how legacy nodes would know to pull in c from an off-chain data source to verify the signature without being updated?

in bip-newproposal.mediawiki:125 in bfd2c1b06d

120+==Security Considerations==
121+
122+* Schnorr-only reliance collapses under quantum adversaries.  
123+* Full Dilithium verification is necessary for PQC security.  
124+* Binding <code>h = H2(c || m)</code> prevents mixing Schnorr and Dilithium signatures.  
125+* Off-chain storage redundancy (e.g., IPFS, Arweave) is required for Dilithium proofs.

murchandamus commented at 9:34 pm on September 10, 2025:

Given the criticality of the full signature data being available for transaction verification, I would expect this point to be further elaborated for this proposal to be considered technically sound.

murchandamus commented at 9:35 pm on September 10, 2025: contributor

Thanks @j1729labs for the update. I gave this a quick first read and left a few suggestions.

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

QES2_Schnorr: A Hybrid Signature Scheme that Achieves Post-Quantum Security in Taproot Without Public Key Exposure

QES2_Schnorr Architecture Overview