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.

Sign up for GitHub

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

Jump to bottom

consider removing sv2-ffi crate from the repo #1416

Open
plebhash opened this issue Jan 29, 2025 · 4 comments · May be fixed by #1417
Open

consider removing sv2-ffi crate from the repo #1416

plebhash opened this issue Jan 29, 2025 · 4 comments · May be fixed by #1417
Labels
ffi FFI related logic protocols Lowest level protocol logic refactor Implies refactoring code

Comments

@plebhash
Copy link
Collaborator

As discussed here, for historical reasons, the FFIs were started with the intention to be imported into Bitcoin Core (TP).

As a consequence, functionality of sv2-ffi is currently limited to only a few SRI crates, and expanding functionality to fully cover Sv2 is a considerable engineering effort (originally tracked by #919, which has since been closed).

The Template Provider strategy has since evolved, and it no longer is a meaningful motivation for maintaining FFIs.

While one could argue potential firmware integration as a motivation for maintaining FFIs (e.g.: https://github.com/plebhash/cgminer-sv2), the Embedded Rust ecosystem is very mature in 2025, and we even have projects in the community that are already implementing full-Rust firmware (e.g.: https://github.com/bitaxeorg/esp-miner-rs).

Meanwhile, keeping the sv2-ffi crate has been a meaningful burden. Whenever we change APIs on some of the crates that are covered by the FFIs, we have to do extra steps to keep sv2-ffi up-to-date (e.g.: run scripts/sv2-header-check.sh and make sure sv2.h is not broken).

Recently I also tried to clean up the examples/interop-cpp* examples via #1407, but eventually gave up as the effort didn't really seem to justify.

So my proposal here is: IMHO we should delete sv2-ffi from the repository.

If we ever get feedback from some adopter that they do need this, we can either:

  • start a FFI coverage task-force from scratch (which would be my preferred approach)
  • ressurect sv2-ffi from the git history
@plebhash plebhash added ffi FFI related logic protocols Lowest level protocol logic refactor Implies refactoring code labels Jan 29, 2025
@plebhash plebhash linked a pull request Jan 29, 2025 that will close this issue
Open
@GitGab19
Copy link
Collaborator

ACK

@Fi3
Copy link
Collaborator

Fi3 commented Jan 30, 2025

big nack for me. It can be very useful to implement an sv2 stack in other languages. It do not make sense to rewrite all the low level libs from scratch since the (low level) API will likely going to be very similar. Is very easy to maintain and it will be not so easy to reintroduce it. Also there are a lot of prop tests that are good for the rests of the crates

@GitGab19
Copy link
Collaborator

The current status of sv2-ffi is completely garbage.. it has never been completed nor maintained, and it probably covers around 20% of all protocols crates.

In addition to it, we can always recover it from git history if we are gonna need to build on top of it in the future.

@Fi3
Copy link
Collaborator

Fi3 commented Feb 3, 2025

it export a minimal set of feature to implement a TP without noise. Also there are a lot of prop tests there. Calling it complete garbage make no sense. Also maintain it do not require ANY effort I can do it if needed. Still very big nack for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
ffi FFI related logic protocols Lowest level protocol logic refactor Implies refactoring code
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

remove sv2-ffi crate plebhash/stratum
3 participants
@Fi3 @GitGab19 @plebhash