You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@kanzure Do you insist on a Python re-implementation, or do you think that the Rust impl or C++ impl could be wrapped? This library is already depending on a lot of native code, and it would be a lot easier to wrap an existing implementation.
My instinct is to say python but only because it makes distribution of the library easier than wrapping and compiling other libraries. What do you think?
As I understand, the native code dependencies are not distributed with bitcoinlib, because they are widespread (openssl and libsecp)
On the other hand, bitcointx has an interface to libbitcoinconsensus with an expectation that the user of bitcointx will make sure that libbitcoinconsensus lib is available, or will load it with explicit path.
Both of the above approaches work well when the underlying libs have a stable API, and there's little chance to hit the incompatibilities, or they can be sensibly handled (like older versions of libsecp lacking some functions)
With newer libs with less stable APIs using these approaches could become problematic.
And the ease of distribution is one of the strengths of bitcoinlib/bitcointx, as there's no additional compilations in the installation steps, which could cause their own problems.
The python-only implementation also has an advantage that it would be more easily readable and instrumentable by the python-oriented users. For example, while libbitcoinconsensus interface exists for bitcointx, having python-only script interpeter is still valuable because of this aspect.
Just an outside observer but I prefer the idea of this being a Python library as much as possible. I think wrapped code is ok when there is no Python code and no one with the bandwidth to implement it in Python. But at least in this Miniscript example, James has implemented a large part of it in Python and it will probably/possibly get merged into the Core test framework at some stage in the future.
I'll second the idea of having a pure python library. For security critical code, minimizing dependencies is paramount, and while I like Rust, I don't think wrapping it is the way to go. If you want to write in Rust, write in Rust and there's no reason to use python-bitcoinlib.
Activity
ysangkok commentedon Oct 12, 2020
@kanzure Do you insist on a Python re-implementation, or do you think that the Rust impl or C++ impl could be wrapped? This library is already depending on a lot of native code, and it would be a lot easier to wrap an existing implementation.
kanzure commentedon Oct 12, 2020
My instinct is to say python but only because it makes distribution of the library easier than wrapping and compiling other libraries. What do you think?
dgpv commentedon Oct 13, 2020
As I understand, the native code dependencies are not distributed with bitcoinlib, because they are widespread (openssl and libsecp)
On the other hand, bitcointx has an interface to libbitcoinconsensus with an expectation that the user of bitcointx will make sure that libbitcoinconsensus lib is available, or will load it with explicit path.
Both of the above approaches work well when the underlying libs have a stable API, and there's little chance to hit the incompatibilities, or they can be sensibly handled (like older versions of libsecp lacking some functions)
With newer libs with less stable APIs using these approaches could become problematic.
And the ease of distribution is one of the strengths of bitcoinlib/bitcointx, as there's no additional compilations in the installation steps, which could cause their own problems.
The python-only implementation also has an advantage that it would be more easily readable and instrumentable by the python-oriented users. For example, while libbitcoinconsensus interface exists for bitcointx, having python-only script interpeter is still valuable because of this aspect.
michaelfolkson commentedon Oct 13, 2020
Just an outside observer but I prefer the idea of this being a Python library as much as possible. I think wrapped code is ok when there is no Python code and no one with the bandwidth to implement it in Python. But at least in this Miniscript example, James has implemented a large part of it in Python and it will probably/possibly get merged into the Core test framework at some stage in the future.
mcelrath commentedon Oct 13, 2020
I'll second the idea of having a pure python library. For security critical code, minimizing dependencies is paramount, and while I like Rust, I don't think wrapping it is the way to go. If you want to write in Rust, write in Rust and there's no reason to use python-bitcoinlib.
mcelrath commentedon Oct 13, 2020
For reference: Miniscript in:
javascript: https://github.com/thmour/miniscript
python: bitcoin/bitcoin#17975
rust: https://github.com/rust-bitcoin/rust-miniscript
dgpv commentedon Nov 25, 2020
Formal spec for miniscript: https://github.com/dgpv/miniscript-alloy-spec