WIP Implement post-quantum security

[real-or-random]

In light of recent advancements in the area of quantum computing that reduce the number of qubits¹² and Toffoli gates² necessary to solve the discrete logarithm problem on secp256k1, I believe it's time to take action and secure this library against quantum attacks.

Implementation plan:

• 60892c9 ecmult_(gen/const): Implement post-quantum mode
• 9b9eb40 configure: Add --enable-post-quantum option
• Port configure option to CMake
• 9e2e6e7 Double major version number (BIG breaking change)
• Reevaluate functionality
• Fix CI
• Add Changelog entry

Footnotes

1. Clémence Chevignard, Pierre-Alain Fouque, André Schrottenloher. Reducing the Number of Qubits in Quantum Discrete Logarithms on Elliptic Curves, EUROCRYPT 2026, https://eprint.iacr.org/2026/280, ↩

2. Ryan Babbush, Adam Zalcman, Craig Gidney, Michael Broughton, Tanuj Khattar, Hartmut Neven, Thiago Bergamaschi, Justin Drake, Dan Boneh. Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations, preprint, https://arxiv.org/pdf/2603.28846 ↩ ↩²

[sipa]

Hmm, I would expect PQC mode to just be a "return false;" in all signature verification functions, but they seem unaffected here?

[hebasto]

I believe it's time to take action and secure this library against quantum attacks.

Indeed.

[theStack]

For better marketing, I'd recommend quadrupling the major version number instead of only doubling (implying an EVEN BIGGER breaking change). Happy to re-review the diff thoroughly if you want to follow that suggestion.

[furszy]

Change is too complex. Should be divided across multiple PRs. The more, the better.

[furszy]

tiny nit for the future:

Execute a GPT/Claude/Gemini prompt here.

[real-or-random]

Hmm, I would expect PQC mode to just be a "return false;" in all signature verification functions, but they seem unaffected here?

That's a fair point, and I've considered this as well, but it's orthogonal to this PR. Changing the signature verification functions would entail a softfork in Bitcoin, and so this will need more discussion. What we could do is add new API calls such as secp256k1_schorrsig_verify_pq which just return 0 when post-quantum mode is enabled and fall back to ordinary verification otherwise. However, based on @furszy's feedback, I suggest that this is done in another PR.

I should have made this clearer in the initial comment, but the purpose of this PR to ensure that any keys created in post-quantum mode are safe (and the same for any ECDH secrets derived in post-quantum mode). This will also make the library secure for new applications adopting libsecp256k1 in the future, e.g., in 50 years from now.

[real-or-random]

For better marketing, I'd recommend quadrupling the major version number instead of only doubling (implying an EVEN BIGGER breaking change). Happy to re-review the diff thoroughly if you want to follow that suggestion.

I think that's overkill for now, but we could do if @sipa's suggestion is implemented.

[real-or-random]

Change is too complex. Should be divided across multiple PRs. The more, the better.

Agreed. I had a hard time splitting 9e2e6e7, but I'm happy to move it to a follow-up PR.

[sipa]

It is quite impressive how this PR manages to create public keys that reveal nothing about the corresponding private keys, even in a CRQC setting!