Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement miniscript #235

Open
kanzure opened this issue Mar 9, 2020 · 7 comments
Open

Implement miniscript #235

kanzure opened this issue Mar 9, 2020 · 7 comments

Comments

@kanzure
Copy link
Collaborator

kanzure commented Mar 9, 2020

bitcoin/bitcoin#17975

@ysangkok
Copy link
Contributor

@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
Copy link
Collaborator Author

kanzure commented 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
Copy link
Contributor

dgpv commented 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
Copy link

michaelfolkson commented 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
Copy link
Collaborator

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
Copy link
Collaborator

For reference: Miniscript in:
javascript: https://github.com/thmour/miniscript
python: bitcoin/bitcoin#17975
rust: https://github.com/rust-bitcoin/rust-miniscript

@dgpv
Copy link
Contributor

dgpv commented Nov 25, 2020

Formal spec for miniscript: https://github.com/dgpv/miniscript-alloy-spec

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants