Migrate to `secp256k1-py`

[darosior]

First to test https://github.com/rustyrussell/secp256k1-py and then to get rid of coincurve.

[jemshit]

What is the motivation for this? Is coincurve not safe? secp256k1-py readme says it is experimental?
@darosior

[jemshit]

@darosior ?

[darosior]

Coincurve is a decent, well maintained alternative to the previously unmaintained libsecp256k1 package.

Rusty recently took over the maintenance of this package. Once it is stable, i'd rather use it as it's closer to the original library (intersection of the sets of contributors of both projects is larger). Also see this.

That said, there is no rush. Coincurve works well for us. I'll wait for secp256k1-py to be more widely used before making any change here.

secp256k1-py readme says it is experimental?

I think you are confused. The libsecp256k1 labels itself as experimental (although it is the basis of an almost trillion-dollar worth monetary system) and that seems to be what you are referring to. Both coincurve and secp256k1-py are bindings to this "experimental" library.

[jemshit]

Thank you 👍

[MementoRC]

@darosior @jemshit Please revisit the assertions made above.

coincurve (master, yet to be pushed to pypi) is actively maintained and tracking fairly decently the updates made by the bitcoin-core maintainers of the secp256k1 C library, (recently updated to v0.4.0 while coincurve is tracking v0.3.2 not impacted by the changes in 0.4.0 - new features)

Recently, I have worked on a couple of conda-forge recipe for both secp256k1 C library (called libsecp256k1) and coincurve. coincurve=18.0.0 conda package is directly compatible with the latest libsecp256k1=0.4.0.

[MementoRC]

@darosior I have also prepared a conda-recipe for python-bip32. It is pending review of the coincurve recipe. Are you interested in being a maintainer for that recipe?

[ofek]

Hey there, heads up that I just released coincurve v21.0.0 which brings performance improvements and removes all runtime dependencies!

[darosior]

Neat!

[darosior]

Another reason for this is that i'm a bit wary of the numerous bells and whistles in the Coincurve library. I'd prefer if the secp256k1 wrapper we use was minimal, with no noise that make reviewing diffs when upgrading dependencies unnecessarily more complicated (see for instance the diff between 20 and 21).

That being said, as mentioned previously there is no well-maintained alternative to Coincurve at the moment.

[SomberNight]

That being said, as mentioned previously there is no well-maintained alternative to Coincurve at the moment.

We split out our stuff into a standalone library: https://github.com/spesmilo/electrum-ecc

Although electrum-ecc is also not a "minimal" wrapper in the sense that it adds some abstractions for EC pubkeys and privkeys on top of libsecp.

[darosior]

Interesting, thanks for sharing.

[ofek]

Another reason for this is that i'm a bit wary of the numerous bells and whistles in the Coincurve library. I'd prefer if the secp256k1 wrapper we use was minimal, with no noise that make reviewing diffs when upgrading dependencies unnecessarily more complicated (see for instance the diff between 20 and 21).

The diff you're referring to was literally all about improving supply chain security so I think your take is rather uncharitable 😅

• A contributor/now co-maintainer (@MementoRC) completely changed the build system to not depend on a hacky setup.py script in favor of a standard CMake build. This is a huge win and brings us up to modern times with proper build provenance.
• Users such wanted less dependencies so I removed both.
  • I hand wrote an optimized ASN.1/DER encoder & decoder that only works for secp256k1 EC private keys. This allowed us to get rid of the asn1crypto dependency which is all we used it for.
  • I started extracting the specific shared library we require from the cffi dependency at build time so that it's no longer a runtime dependency. End users were having trouble building that from source in some circumstances. Eventually, even that won't be required when we switch to using Cython although I haven't had time for that yet and it would depend on the results of benchmarking (which I happened to add in the changes you mentioned).

[darosior]

Sorry if that cames across as harsh @ofek, of course this release brings great improvements (which i do note here). I was just pointing these improvements are drown among various doc string refactorings, emoji URL fixups, LLM tooling configuration, etc.

[ofek]

No worries at all 🙂

I suppose it's just a difference in preferences as if I see a project languishing with older code style, dead links, etc. I assume that it lacks maintenance and am reluctant to use it no matter if it happens to work in the present. For user-facing changes in coincurve, I would recommend the official changelog or equivalent release entry (e.g. v21.0.0) as I take care to document things that would affect users directly.

Please let me know what I can improve on in your mind to make using the library even more desirable! I'm always interested in feedback and take it seriously.