Add BIP: QES2 – Hybrid PQC-based Digital Signature Algorithm #1830
Conversation
|
Would it make sense to just add QES2 support to BIP-360? |
|
|
||
| QES2 can be integrated with BIP-340 (Taproot) by: | ||
|
|
||
| 1. Using the QES2-based signature in place of the Schnorr signature |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
|
|
||
| 2. **ECDSA Security**: While vulnerable to quantum attacks, ECDSA remains secure against classical adversaries. | ||
|
|
||
| 3. **Binding Property**: The ECDSA signature validates the Dilithium signature, creating a binding that requires breaking both schemes or finding hash collisions to forge. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
|
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! |
murchandamus
added
the
PR Author action required
There was a problem hiding this comment.
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.
| New Opcode | ||
| ~~~~~~~~~~ | ||
|
|
||
| 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. |
There was a problem hiding this comment.
Opcode 186 was designated OP_CHECKSIGADD by BIP 342.
|
|
||
| QES2 can be integrated with BIP-340 (Taproot) by: | ||
|
|
||
| 1. Using the QES2-based signature in place of the Schnorr signature |
There was a problem hiding this comment.
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?
| This BIP maintains backward compatibility through several mechanisms: | ||
|
|
||
| 1. **Opt-in Deployment**: QES2 addresses are distinct from traditional addresses | ||
| 2. **Traditional Scripts**: Existing P2PKH, P2SH, P2WPKH, and P2WSH scripts continue to function normally |
There was a problem hiding this comment.
As mentioned, this does not address P2TR outputs which make up about 1/3 of all existing UTXOs.
| Acknowledgments | ||
| ============== | ||
|
|
||
| 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. |
There was a problem hiding this comment.
I’m confused that this proposal mentions BIP 340 several times, but insufficiently addresses BIP 340 signatures.
| This BIP introduces a new script template: | ||
|
|
||
| .. code-block:: | ||
|
|
||
| <pq_signature_push> <ecdsa_signature_push> <pubkey_push> OP_QES2_CHECKSIG |
There was a problem hiding this comment.
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?
| :BIP: Unassigned | ||
| :Title: QES2 - A Hybrid Post-Quantum and Classical Digital Signature Scheme for Bitcoin | ||
| :Author: [Caleb Lee] [email protected], [Justin Park] [email protected], [Eunice Lee] [email protected], [Sophia Shim] [email protected] | ||
| :Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXXX | ||
| :Status: Draft | ||
| :Type: Standards Track | ||
| :Created: 2025-04-18 | ||
| :License: BSD-2-Clause | ||
| :Requires: 340, 341, 342 |
There was a problem hiding this comment.
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 <[email protected]>.
Thank you for the guidance. I will make sure to post this to the mailing list. |
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.