Open ecdsa opened 2 months ago
Not sure how to name the new package. IMaybe python-libsecp256k1 ?
I strongly think it should have a distinct name. For example, coincurve is a good name because you can easily distinguish it from rusty's secp bindings. python-libsecp256k1
is not a name that can be easily distinguished from rusty's bindings. We could call it electrum-secp256k1
. If for some reason we did not want electrum
in the name, we could call it secp256k1-ctypes
.
That package could be used by other projects, and it would free those projects from importing cffi related dependencies. Note that some of the methods in ecc.py use cryptography (encrypt_message, verify_message). I think we should not import cryptography in the new package, but rather move those methods to electum/crypto.py.
Right, to make the new package useful, I think it should
ECPubkey.encrypt_message
(and decrypt_message also), it would make sense not to put them into the new package. Instead, there could be a new module in electrum, which adds a subclass of ECPubkey, which adds the encrypt_message
method. e.g. There would be electrum_secp256k1.ecc.ECPubkey
and electrum.ecc.ECPubkey(electrum_secp256k1.ecc.ECPubkey)
, and the base class would not have an encrypt_message
method, but the child class would. (but this is just an idea, there are other ways ofc)electrum-secp256k1
should be distributed on PyPIelectrum
would depend on electrum-secp256k1
and install it from PyPI
electrum
could use electrum-secp256k1
as a git submoduleelectrum-secp256k1
on PyPIcontrib/make_libsecp256k1.sh
should probably also be moved to the new package
electrum
as well...electrum-secp256k1
, it might be best to not use them as part of electrum's build process (force pip to use sdist and build from source at that time)
pip install .
on an electrum tar.gz or git clone. If we provide binary wheels for the secp package, we probably want a high bar of release security there too...electrum-secp256k1
python-nostr
, the cffi
-related dependencies won't be removed, because python-nostr
also uses cryptography
. So, the only thing that would get removed is secp256k1
. That might not be compelling enough for them to use it. However, if we decide to distribute python-nostr
in an Electrum plugin, we will want something that is pure python. Thus, we might have to fork it.python-nostr.
At this point, there is no real need for this.
Currently, some projects such as
python-nostr
usecffi
based python packages such assecp256k1
orcoincurve
. In contrast, Electrum usesctypes
in order to calllibsecp256k1
functions inecc.py
andecc_fast.py.
It would make sense to create a standalone python package for that. That package could be used by other projects, and it would free those projects from importingcffi
related dependencies.Note that some of the methods in
ecc.py
use cryptography (encrypt_message
,verify_message
). I think we should not import cryptography in the new package, but rather move those methods toelectum/crypto.py
.Not sure how to name the new package. IMaybe
python-libsecp256k1
?