Open mcelrath opened 8 years ago
I did this with another interpreted language, and got an 8000x speed up.. Definitely worth having.
That'd also make it easy to add HD key derivation operations too. One disadvantage though is it's a dependency, and unless I'm mistaken secp256k1 isn't available on Windows.
A reasonable compromise would be to make the actual underlying ECC library pluggable, with libsecp256k1 being an option in addition to OpenSSL.
I've added pull request with straightforward implementation (checking for presence and enabling signing with libsecp256k1 are done just with two exported functions) https://github.com/petertodd/python-bitcoinlib/pull/185
@petertodd, do you think pluggable ECC library scheme should mean the ability to totally swap openssl for libressl, for example ? Limiting the scope to only changing library for signing makes it much simpler.
@mcelrath Some libsecp256k1 support seems to have been merged (see comment by @dgpv ) . Do you think something is missing such that this issue should be kept open?
The libsecp256k1 support added by #185 is optional, and the signing is with openssl by default.
I think the discussion on if it makes sense to ditch openssl entirely and switch to libsecp can still continue.
bitcointx refined the integration with libsecp since then, it has functions to get the library handle if users need other low-level functions (and are ready to take responsibility for using them), and to set custom path for libsecp library (useful when a program ships with its own version of the lib)
Bitcoin core is now using libsecp256k1 for consensus-critical ECC operations. Therefore it makes sense to convert python-bitcoinlib to using the FFI interface to it: https://github.com/ludbb/secp256k1-py