secp256k1lab: a Python library for prototyping

[Jonas Nick]

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)

[waxwing/ AdamISZ]

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

[Jonas Nick]

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.