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.

Bitcoin could be headed for its most sweeping cryptographic overhaul yet if a new proposal gains traction.

A draft Bitcoin Improvement Proposal (BIP) titled Quantum-Resistant Address Migration Protocol (QRAMP) has been introduced by developer Agustin Cruz. It outlines a plan to enforce a network-wide migration of BTC from legacy wallets to ones secured by post-quantum cryptography.

Quantum computing involves moving away from a process reliant on binary code, ones and zeros, and exponentially increasing computing power by employing Quantum bits (qubits) that exist in multiple states simultaneously. Such a jump in power is expected to threaten modern computing encryption built by classic machines.

The proposal suggests that after a predetermined block height, nodes running the updated software would reject any transaction trying to spend coins from an address using ECDSA cryptography, which could theoretically make it vulnerable to quantum attacks.

A hard fork debate

Bitcoin currently relies on algorithms, including SHA-256 for mining and the Elliptic Curve Digital Signature Algorithm (ECDSA) for signatures. Per Cruz, legacy addresses that haven’t yet transacted are protected by additional layers, while those that have exposed their public keys—necessary to conduct transactions—may now be vulnerable “if sufficiently powerful quantum computers emerge.”

The move would require a hard fork, which is likely going to be a tall ask from the community. A hard fork refers to a change to a blockchain that renders an older version incompatible.

“I admire the effort but this will still leave everyone who doesn’t migrate’s coins vunerable, including Satoshi’s coins,” said one Reddit user about the new proposal.

“Bitcoin could implement a post quantum security for all coins but that would need a hard fork, which due to bitcoin’s history and the mantra repeated by maxis that would create a new coin and would not be bitcoin anymore.”

Read more: The Blocksize Wars Revisited: How Bitcoin’s Civil War Still Resonates Today

Preventive measure

The proposed solution sets a migration deadline to lock those funds unless they’re moved to a more secure wallet. This proposal isn’t a response to any imminent breakthrough in quantum computing. Instead, it’s a preventive measure, yet it comes a little over a month after Microsoft unveiled Majorana 1, a quantum processing unit designed to scale to a million qubits per chip.

During a migration window, users would still be able to move funds freely. The BIP calls for wallet developers, block explorers and “other infrastructure” to build tools and warnings to help users comply.

After the deadline, non-upgraded nodes could fork from the network if they continue accepting legacy transactions.

This is not the first time someone has suggested a mechanism to defend Bitcoin from quantum computing threats. Most recently, BTQ, a startup working to build blockchain technology that can withstand attacks from quantum computers, has proposed an alternative to the Proof of Work (PoW) algorithm involving quantum technology.

In its research paper, BTQ proposed a method called Coarse-Grained Boson Sampling (CGBS). This process uses light particles (bosons) to generate unique patterns—samples—that reflect the blockchain’s current state instead of hash-based mathematical puzzles.

However, this proposal would also require a hard fork involving miners and nodes replacing their existing ASIC-based hardware with quantum-ready infrastructure.

Read more: Quantum Startup BTQ Proposes More Energy Efficient Alternative to Crypto’s Proof of Work