secp256k1lab: a Python library for prototyping

Hello list,

We're pleased to announce the initial release of secp256k1lab, an INSECURE implementation of the secp256k1 elliptic curve and related cryptographic schemes written in Python, intended for prototyping, experimentation and education.

https://github.com/secp256k1lab/secp256k1lab

Features:

- Low-level secp256k1 field and group arithmetic.
- Schnorr signing/verification and key generation according to BIP-340.
- ECDH key exchange.

We developed secp256k1lab as part of our work on the ChillDKG work-in-progress BIP [0]. It is based on the secp256k1 implementation in the Bitcoin Core test framework.

Our goal was to avoid including yet another custom Python implementation of the secp256k1 curve in the ChillDKG reference code. Several existing BIPs (340, 324, 327, and 352) already contain custom and sometimes subtly diverging implementations of secp256k1. This library aims to provide a single, consistent interface for secp256k1-related cryptographic specifications.

At the moment, secp256k1lab is included in the ChillDKG repository as a subtree. It remains an open question what would be the best approach for including ChillDKG (with the secp256k1lab dependency) into the bips repository [1].

We welcome your feedback and contributions to this project.

Best regards, The current secp256k1lab maintainers: Sebastian Falbesoner, Jonas Nick, Tim Ruffing

[0] https://github.com/BlockstreamResearch/bip-frost-dkg
[1] https://groups.google.com/g/bitcoindev/c/HE3HSnGTpoQ/m/Y2VhaMCrCAAJ
     (We renamed secp256k1proto to secp256k1lab)

Thanks for this.

Seems like a great initiative for, as you say, prototyping and education. (though iiuc your primary motive was standardising proposal "reference" code).

I'm guessing that things like MuSig2 and/or adaptors would be out of scope of this project? (i.e. you are only supplying the foundational ECC operations here.. except you are providing Schnorr signatures). Those are things that ate up time for me when I was prototyping stuff (like "pathcoin" for example), hence the Q.

Regards, AdamISZ/waxwing

On Tuesday, April 1, 2025 at 5:51:37 AM UTC-3 Jonas Nick wrote:

> Hello list,
>
> We're pleased to announce the initial release of secp256k1lab, an INSECURE
> implementation of the secp256k1 elliptic curve and related cryptographic
> schemes
> written in Python, intended for prototyping, experimentation and education.
>
> https://github.com/secp256k1lab/secp256k1lab
>
> Features:
>
> - Low-level secp256k1 field and group arithmetic.
> - Schnorr signing/verification and key generation according to BIP-340.
> - ECDH key exchange.
>
> We developed secp256k1lab as part of our work on the ChillDKG
> work-in-progress
> BIP [0]. It is based on the secp256k1 implementation in the Bitcoin Core
> test
> framework.
>
> Our goal was to avoid including yet another custom Python implementation
> of the
> secp256k1 curve in the ChillDKG reference code. Several existing BIPs
> (340, 324,
> 327, and 352) already contain custom and sometimes subtly diverging
> implementations of secp256k1. This library aims to provide a single,
> consistent
> interface for secp256k1-related cryptographic specifications.
>
> At the moment, secp256k1lab is included in the ChillDKG repository as a
> subtree.
> It remains an open question what would be the best approach for including
> ChillDKG
> (with the secp256k1lab dependency) into the bips repository [1].
>
> We welcome your feedback and contributions to this project.
>
> Best regards,
> The current secp256k1lab maintainers: Sebastian Falbesoner, Jonas Nick, Tim
> Ruffing
>
> [0] https://github.com/BlockstreamResearch/bip-frost-dkg
> [1] https://groups.google.com/g/bitcoindev/c/HE3HSnGTpoQ/m/Y2VhaMCrCAAJ
> (We renamed secp256k1proto to secp256k1lab)
>

Hi AdamISZ/waxwing,

I discussed with the maintainers, and we do consider MuSig2 and adaptor signatures to be in-scope. However, we don't currently plan to proactively add these features ourselves.

The reason the library currently contains an implementation of BIP 340 and not only raw elliptic curve operations is that we use BIP 340 in the ChillDKG reference code. So if there is demand to specify a scheme that is based on MuSig2 or adaptor signatures, then a similar reasoning would apply. MuSig2 would be particularly easy to add because it already has a python reference implementation and test vectors.