Until now, every Bitcoin Improvement Proposal (BIP) that needed cryptographic primitives had to reinvent the wheel. Each one came bundled with its own custom Python implementation of the secp256k1 elliptic curve and related algorithms, each subtly different from one another. These inconsistencies introduced quiet liabilities and made reviewing BIPs unnecessarily complicated. This problem was recently highlighted in Bitcoin Optech Newsletter #348, and it’s something at least a handful of developers in the Bitcoin development community have long felt: there should be a unified, reusable standard for cryptographic BIP reference secp256k1 code.
Last week, Jonas Nick and Tim Ruffing of Blockstream research and Sebastian Falbesoner made big progress towards this. As part of their existing ChillDKG proposal, the team released secp256k1lab. A new, intentionally INSECURE Python library for prototyping, experimenting, and BIP specifications. It’s not for production use (because it’s not constant-time and therefore vulnerable to side-channel attacks), but it fills a critical gap: it offers a clean, consistent reference for secp256k1 functionality, including BIP-340-style Schnorr signatures, ECDH, and low-level field/group arithmetic. The goal is simple: make it easier and safer to write future BIPs by avoiding redundant, one-off implementations. For BIP authors, this means: less custom code, fewer spec issues, and a clearer path from prototype to proposal.
> Why Not Just Use the Real secp256k1 Library?
Bitcoin Core already includes a fast, constant-time C library for secp256k1 cryptography. So why don’t BIP authors just use that?
When a BIP author submits a proposal, they are expected to include a reference implementation to explain how the idea works. These implementations do not have to be written in Python, but C is often too low-level for prototyping. Python is easier to read, easier to modify, and makes it clearer what the author is trying to express. These qualities make it especially well-suited for writing specifications.
When introducing a new cryptographic idea, it helps to have something clear, concise, and safe to experiment with. In principle, tools like hacspec are a good option for formal specifications, since hacspec code is also valid Rust. But in practice, hacspec can be difficult to work with and read, especially for BIP readers who are not familiar with Rust.
Python’s readability continues to make it the language many authors return to when they need to explain how something works.
Why BIP Authors Keep re-Rolling secp256k1 Again and Again
This started back with BIP 340 Schnorr Signatures, when the BIP authors wrote the original reference code in Python so it would be easy to follow the math. They defined exactly how to do Schnorr-style signing and verification using secp256k1’s curve parameters. They had to build everything from scratch: field arithmetic, group operations, deterministic nonce generation, and the encoding rules. The Python code was clear and educational. But it was tailored specifically to this single BIP, and not designed to be reused by future ones.Â
Similarly, BIP 324 Encrypted P2P Transport, added encryption to how Bitcoin nodes should talk to each other, and used a protocol called Noise that relies on key exchanges, shared secrets, and symmetric encryption. While it builds on the same secp256k1 curve used in BIP 340, it did not reuse any of the actual implementation code. All of the cryptographic logic such as ECDH, serialization, and handshake patterns was re-implemented from scratch in Python. Even though the underlying math is the same, each BIP ends up writing its own version of the logic. This leads to duplicated effort and introduces the potential for subtle inconsistencies.Â
What secp256k1lab Actually Is
secp256k1lab is a Python library built for one purpose: making it easier to write and test cryptographic specs for Bitcoin. Python is already the most popular and widely used language for reference implementations and test vectors in BIPs, so having a shared, reusable library just makes sense. It’s not designed for production use. It’s built for prototyping, not performance. It offers a clean, unified interface to core secp256k1 functionality, with readable code and minimal setup. No more rolling your own every time you want to test an idea or demonstrate how something should work.
Real-World Use Case: ChillDKG
secp256k1lab was first developed as part of the work on ChillDKG, a new BIP proposal for distributed key generation. Instead of writing yet another custom Python implementation of secp256k1 just for this one spec, the authors used secp256k1lab to handle all the cryptographic building blocks in a way that it could be leveraged by others. By reusing a shared, readable codebase, their hope is that future cryptographic BIPs won’t have to start from scratch. With secp256k1lab, there’s finally a foundation that new proposals can build on and improve together.
Where It Could Go
There’s still an open question: should secp256k1lab live in the BIPs repository? It’s already proving useful as a shared reference for cryptographic proposals, but there’s ongoing discussion about where it truly belongs within the broader Bitcoin development process. Whether it stays as a standalone library or becomes more tightly integrated with the BIP workflow, one thing is clear—it fills a gap that’s been around for years. If you’re a BIP author, spec reviewer, or just curious about improving the cryptographic tooling around Bitcoin, we’d love your input. You can join the discussion on the Bitcoin-Dev mailing list or contribute directly to the secp256k1lab GitHub repo.
This is a guest post by Kiara Bickers. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
