Add draft BIP: pqcBitcoin Post-Quantum Cryptography for Bitcoin #1832
pull QbitsCode wants to merge 3 commits into bitcoin:master from QbitsCode:bip-pqcbitcoin changing 1 files +162 −0-
QbitsCode commented at 7:34 pm on April 22, 2025: none
-
Add draft BIP: pqcBitcoin Post-Quantum Cryptography for Bitcoin dc5b9136de
-
murchandamus commented at 0:37 am on April 23, 2025: contributorHi @QbitsCode, if this is a collaboration with @ysangkok, how come there is only one author? Has there been a discussion of this proposal on the mailing list?
-
ysangkok commented at 1:33 am on April 23, 2025: contributorI don’t have anything to do with this, don’t know why my email is on the commit
-
QbitsCode commented at 2:18 am on April 23, 2025: none
Hi @murchandamus :
- No.
- Yes, we had considerable discussions of this proposal on the mailing list.
-
jonatack commented at 2:25 am on April 23, 2025: memberHi @QbitsCode, can you please add the link to the mailing list discussion of this proposal to your pull request description? (I took a quick look in the mailing list https://groups.google.com/g/bitcoindev but did not find it.)
-
jonatack added the label New BIP on Apr 23, 2025
-
QbitsCode commented at 3:34 am on April 23, 2025: noneYou’re right — I mistakenly stated that the proposal was discussed on the mailing list. It was actually discussed in other forums, such as Delving Bitcoin: https://delvingbitcoin.org/t/implemented-post-quantum-cryptography-pqc-feature-into-bitcoin-core/1320.
-
in bip-pqc-bitcoin.mediawiki:7 in dc5b9136de outdated
0@@ -0,0 +1,74 @@ 1+BIP: Unassigned 2+Title: pqcBitcoin Post-Quantum Cryptography for Bitcoin 3+Author: Eid Al Subaie <ceo@qbitsest.com> 4+Status: Draft 5+Type: Standards Track 6+Created: 2025-04-22 7+License: BSD-2-Clause
murchandamus commented at 12:21 pm on April 23, 2025:The preamble should use preformatted text:
0<pre> 1 BIP: ? 2 Title: pqcBitcoin Post-Quantum Cryptography for Bitcoin 3 Author: Eid Al Subaie <ceo@qbitsest.com> 4 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-? 5 Status: Draft 6 Type: Standards Track 7 Created: ? 8 License: BSD-2-Clause 9</pre>
QbitsCode commented at 1:21 pm on April 23, 2025:Thanks for the feedback. This draft is part of a broader ongoing initiative to explore post-quantum cryptography for Bitcoin. We’ll initiate the discussion on the mailing list and continue refining the proposal in my fork as suggested.in bip-pqc-bitcoin.mediawiki:23 in dc5b9136de outdated
18+- Ensure Bitcoin’s resilience in the face of future technological advancements, maintaining trust in its decentralized model. 19+ 20+== Specification == 21+The proposed solution introduces the use of post-quantum cryptography to Bitcoin's transaction signing process. It integrates cryptographic primitives that are resistant to quantum computing-based attacks. 22+ 23+### Proposed Algorithm
murchandamus commented at 12:24 pm on April 23, 2025:I wonder whether this and the two instances below were supposed to be section headers:
0=== Proposed Algorithm ===
in bip-pqc-bitcoin.mediawiki:20 in dc5b9136de outdated
15+This proposal aims to: 16+- Protect Bitcoin from quantum-enabled attacks by integrating post-quantum cryptographic algorithms. 17+- Provide a roadmap for transitioning to quantum-safe cryptographic techniques while maintaining Bitcoin's decentralization and security. 18+- Ensure Bitcoin’s resilience in the face of future technological advancements, maintaining trust in its decentralized model. 19+ 20+== Specification ==
murchandamus commented at 12:29 pm on April 23, 2025:The Specification section should describe the syntax and semantics detailed enough to allow implementation of the feature. This is just a description for an approach.in bip-pqc-bitcoin.mediawiki:46 in dc5b9136de outdated
41+The implementation includes the following: 42+- A **PQC-enabled wallet** that supports generating quantum-safe addresses and signing transactions using NTRU-based signatures. 43+- A **modified Bitcoin node** that validates both ECDSA and PQC signatures, ensuring compatibility with both old and new addresses during the transition period. 44+- **Test vectors** that demonstrate the functionality and security of the proposed cryptographic methods when applied to Bitcoin transactions. 45+ 46+== Rationale ==
murchandamus commented at 12:30 pm on April 23, 2025:Given that this is the third or fourth PQ proposal in a few months, it would be especially appreciated if the Rationale got into alternative approaches.murchandamus changes_requestedmurchandamus commented at 12:38 pm on April 23, 2025: contributorThis document does not describe the proposed feature in sufficient detail and is not a stage where it should be a pull request to this repository. The Specification section seems like a good starting point for a conversation on the mailing list about the approach. It would be preferable if the proposal had seen more discussion and the document were further developed before being submitted here. We recommend that authors iterate on a pull request against their own fork of the BIPs repository at the early sketch stage as it doesn’t make sense to bombard other subscribers of this repository with notifications while the proposal is just starting to take shape.
I’m going to turn this into a draft pull request, but I would recommend that it be closed and reopened at a later time when the proposal is fleshed out more.
Also, please look into why your commit is labeled as having been authored by Janus—that’s just weird.
murchandamus marked this as a draft on Apr 23, 2025cryptoquick commented at 2:39 am on April 30, 2025: noneBecause the details aren’t specified, it’s not quite clear how this would differ from BIP-360. As Murch mentioned, it would make sense to at least contrast this with that BIP. There seems to be some overlap, and the parts that don’t overlap, such as PQC KEM, might be better specified as a separate BIP. If I were to make a suggestion, maybe this BIP could focus on Group 2 algorithms (for communication between nodes and wallets, as the pqc-bitcoin readme states) and BIP-360 would cover Group 1. Do you think that might make sense?QbitsCode commented at 9:22 pm on May 6, 2025: none@cryptoquick Thanks for your suggestion on pqcBitcoin. We’re considering your point in our evaluation. So, what you’re saying take Group 1 out as it covered in your BIP-360 and just foucs on Group 2 algorithms for communications between nodes, and wallets. It makes sense but let me tell the following:
-
Main objective of pqcBitcoin was a holistic implementation pqc repo.
-
If we go this suggestion, we need to know how to integrate your BIP-360 (seems Group 1) and Group 2.
murchandamus commented at 10:25 pm on June 20, 2025: contributorHi @QbitsCode, is this proposal still being worked on?QbitsCode commented at 7:29 am on June 21, 2025: noneYes, we’re actively working on it. Given the importance of post-quantum resilience for Bitcoin, we’re taking the time to ensure the proposal is precise, solid, and forward-compatible!murchandamus added the label PR Author action required on Jul 16, 2025QbitsCode commented at 6:48 am on July 27, 2025: noneDue to emerging post-quantum threats and the current phase of our pqcBitcoin implementation, I recommend temporarily removing or hiding your PGP public key from all public-facing locations (key servers, websites, email signatures, etc.). We’re mitigating the risk of quantum-enabled ‘harvest-now, decrypt-later’ attacks. Once our PQC implementation is live, you’ll be invited to re-expose your keys under quantum-resistant standards.murchandamus commented at 7:07 pm on July 28, 2025: contributor@QbitsCode: This PR has had unaddressed feedback for over three months, and now you are instead posting unrelated warnings here instead of an update. Please focus on your proposal in this pull request.QbitsCode commented at 7:31 pm on August 1, 2025: none@murchandamus: Thanks for your patience. We’ve been diligently working on addressing the technical feedback and refining the proposal to ensure clarity, completeness, and alignment with Bitcoin Core standards. The updated specification now includes detailed descriptions of key formats, signature schemes, hybrid constructions, backward compatibility mechanisms, and test vectors to facilitate implementation and review.murchandamus commented at 7:46 pm on August 1, 2025: contributorHello @QbitsCode, it sounds like you published the update, but so far I don’t see a change to this branch. Did you perhaps accidentally publish somewhere else instead of here?Update bip-pqc-bitcoin.mediawiki
Final update: Revised BIP text for PQC integration.
Update bip-pqc-bitcoin.mediawiki
Final update: Revised BIP text for PQC integration.
QbitsCode commented at 9:24 pm on August 1, 2025: noneFinal update: Revised BIP text for PQC integration.QbitsCode commented at 9:30 pm on August 1, 2025: none@murchandamus Hopefully, you can see the updates here.in bip-pqc-bitcoin.mediawiki:118 in 8c18328661
113+Features include: 114+ 115+* PQC-enabled wallet and key management supporting quantum-safe address generation. 116+* Modified Bitcoin node with support for validating both ECDSA and PQC signatures. 117+* Test vectors and unit/integration tests validating PQC functionality. 118+* Implementation of hybrid signature schemes and KEM-based secure communication.
murchandamus commented at 10:55 pm on August 1, 2025:I had a look at the linked repository to get a sense of the progress on the reference implementation. The branch in that repository hasn’t had updates since December and appears to consist mostly of documentation changes. I noticed that there were// TODO
placeholders in the functions for key generation for and signing with the PQ schemes. Is this link outdated? Where can I find the current version of this implementation effort?murchandamus commented at 11:23 pm on August 1, 2025: contributor@QbitsCode: Thanks, I can see the update now. The document that I’m seeing consists largely of bullet points that amount to outlining an approach.
Upon review, I find that this document does not meet our baseline expectations regarding technical soundness, clarity, and completeness. My comments regarding the prior version stand, especially that the purpose of a BIP is to provide a detailed Specification with sufficient detail that other projects can implement the proposed feature. The prototype/reference implementation appears to be missing crucial parts of the proposed feature.
I appreciate the effort invested and encourage you to review the guidelines to BIP authors in BIP 2 and BIP 3 as well as other BIPs that propose new output types and soft forks before considering a revised submission.
murchandamus closed this on Aug 1, 2025
QbitsCode commented at 6:14 am on August 2, 2025: none@murchandamus Respectfully, the closure lacks specific technical feedback. No line-level questions or concrete issues were raised. Clear objections would help improve the proposal before closing it prematurely!murchandamus commented at 10:34 pm on August 4, 2025: contributorI have raised the following issues:
- The idea has had very little public discussion.
- This sketch has barely enough detail to discuss the idea, but is too vague to discuss the concrete approach and trade-offs, let alone actually implement support for the implied feature.
- The linked reference implementation is missing the very feature you are proposing.
- This document does not discuss related work.
You are proposing a softfork to the Bitcoin network, define four new PQ-signature schemes for use in Bitcoin, and introduce two new output types. Try putting yourself in the shoes of someone reading your document without prior knowledge. What do they want to learn from your document? What questions would they have? Then thinking from their perspective, assess your document whether it serves those needs.
As it is, this is not “a clear and complete description of the proposed enhancement”, which would entail how signatures are created and validated, the concrete validation rules for the new output types, rationale for design decisions, comparison to related work, etc.
murchandamus commented at 3:32 pm on August 5, 2025: contributorNote that this is not a final rejection of your idea, but merely an assessment that what was submitted in this pull request is nowhere mature enough to be merged. If you wish to continue working on it, please open it e.g., against your personal fork of the BIPs repository and consider a revised submission when it is more mature.
If you are looking for some examples what we would expect BIPs that propose similar changes to look like, please read e.g., BIP 141–143, 173, 341–343, 350, and 360.
github-metadata-mirror
This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2025-09-13 12:10 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me