So far, every Bitcoin Improvement Proposal (BIP) that requires encryption of the original graph must be reinvented. Everyone has bundled their own custom Python implementation SECP256K1 elliptic curves and related algorithms, each of which is subtle to each other. These inconsistencies introduce quiet responsibility and unnecessarily complicate BIP. This issue was recently highlighted in the Bitcoin Optech Newsletter #348, which at least a few developers in the Bitcoin development community have long believed: There should be a unified, reusable standard for encrypting BIP reference SECP256K1 code.
Last week, Jonas Nick and Tim Ruffing of Blockstream Research and Sebastian Falbesoner made great strides in this. As part of their existing Chilldkg proposal, the team released the SECP256K1LAB. A new one, Intentionally unsafe Python library for prototypes, experiments and BIP specifications. It is not for production use (because it is not constant and therefore vulnerable to lateral channel attacks), but it fills a critical gap: it provides a clean, consistent reference to SECP256K1 features, including BIP-340-style Schnorr Signatures, ECDH, ECDH, ECDH, and low-level field/group/group arithmetic. The goal is simple: make future BIP easier and safer by avoiding one-time implementation of redundancy. For BIP authors, this means: less custom code, fewer spec issues, and a clearer path from prototype to suggestion.
> Why not use the real SECP256K1 library?
Bitcoin Core already includes a fast, constant C library in SECP256K1 cryptography. So why don’t BIP authors just use it?
When BIP authors submit proposals, they are expected to include reference implementations to explain how the idea works. These implementations do not have to be written in Python, but C is usually too low for prototyping. Python is easier to read, easier to modify, and makes what the author is trying to express clearer. These qualities make it particularly suitable for writing specifications.
When new encryption ideas are introduced, it helps to make some clear, concise and safe attempts. In principle, tools like HACSPEC are a good choice for formal specifications, as the HACSPEC code also effectively rusts. But in reality, HACSPEC can be difficult to use and read, especially for Bip readers who are not familiar with Rust.
Python’s readability continues to make it the language that many authors return when they need to explain something’s work.
Why BIP Authors Replay SECP256K1 Again and Again
This begins with BIP 340 schnorr signatureIt’s easy to follow math when Bip authors write original reference code in Python. They precisely define how to use the curve parameters of SECP256K1 for Schnorr style signature and verification. They have to build everything from scratch: field arithmetic, group operations, deterministic non-CE generation and coding rules. Python code is clear and educational. But it is tailor-made for this single BIP and is not for future reuse.
Similarly, BIP 324 Encrypted P2P TransmissionEncryption discusses how Bitcoin nodes should talk to each other and uses a protocol called noise that relies on key exchange, shared secrets and symmetric encryption. Although it is based on the SECP256K1 curve used in BIP 340, no actual implementation code is reused. Restart all encryption logic from scratch in Python, such as ECDH, serialization and handshake mode. Even if the basic math is the same, each BIP will eventually write its own version of logic. This leads to repeated efforts and introduces the potential for subtle contradictions.
What is SECP256K1LAB actually
SECP256K1LAB is a Python library built for one purpose: it is easier to write cryptographic specifications for Bitcoin. Python is already the most popular and widely used language in BIPS for reference implementations and test vectors, so it makes sense to have a shared reusable library. It is not designed for production use. It is designed for prototyping rather than performance. It provides a clean unified interface for the Core Secp256K1 functionality with readable code and minimal settings. Whenever you want to test an idea or demonstrate how it should work, there is no longer a scroll of your own.
Real-world use case: chilldkg
SECP256K1LAB First developed as part of the work Chilldkga new BIP proposal for distributed critical power generation. Not only did the author write another custom Python implementation of SECP256K1 for this specification, but instead uses SECP256K1LAB to handle all the encrypted building blocks, which others can take advantage of. By reusing the shared, readable code base, they hope that future encrypted BIPs do not have to start from scratch. With the help of SECP256K1LAB, a foundation was finally established where new suggestions could be built together and improved.
Where can it go
There is still an open question: Should SECP256K1LAB live in a BIPS repository? It has proven to be a shared reference for crypto suggestions, but discussions are underway about what it really belongs to in the broader Bitcoin development process. Whether as a standalone library or more closely integrated with the BIP workflow, it is clear that it fills the gap that has been around for years. If you are a BIP author, Spec Reviewer, or just curious about improving the crypto tools around Bitcoin, then we will love your input. You can join the discussion on the Bitcoin-DEV mailing list or contribute directly to the SECP256K1LAB GITHUB repository.
Here is a guest post from Kiara Bickers. The opinions expressed are entirely their own and do not necessarily reflect the views of BTC Inc or Bitcoin Magazine.
