Add draft BIP: pqcBitcoin Post-Quantum Cryptography for Bitcoin

[QbitsCode]

Delving discussion: https://delvingbitcoin.org/t/implemented-post-quantum-cryptography-pqc-feature-into-bitcoin-core/1320

[murchandamus]

Hi @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]

I don't have anything to do with this, don't know why my email is on the commit

[QbitsCode]

Hi @murchandamus :

1. No.
2. Yes, we had considerable discussions of this proposal on the mailing list.

[jonatack]

Hi @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.)

[QbitsCode]

You'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.

[QbitsCode]

@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:

1. Main objective of pqcBitcoin was a holistic implementation pqc repo.

2. If we go this suggestion, we need to know how to integrate your BIP-360 (seems Group 1) and Group 2.

[murchandamus]

Hi @QbitsCode, is this proposal still being worked on?

[QbitsCode]

Yes, 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!

[QbitsCode]

Due 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]

@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]

@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]

Hello @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?

[QbitsCode]

@murchandamus Hopefully, you can see the updates here.

[QbitsCode]

@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]

I 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]

Note 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.