bitcoin
Add BIP: QES2 – Hybrid PQC-based Digital Signature Algorithm
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.
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!
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.
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.
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.
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.
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.
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.
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.
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
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.
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!
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.
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.
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.