feature: add tor support by using arti-hyper with new feature async-arti-hyper

[oleonardolima]

What

As mentioned and discussed at bitcoindevkit/bdk#66 adding Tor support to both rust-esplora-client or rust-electrum-client is really useful as an alternative to the current SOCKS proxy support, and adds another layer of privacy and anonymity for BDK, and other crates that rely on rust-esplora-client.

That said, why the new releases of Arti it became somewhat easy to add support for Tor, even more so for HTTP-based requests such as this crate, arti-client can be used in a way to have Tor support as async streams requiring some work with it's APIs and streams.

The Arti team already added support to HTTP requests by using hyper, keeping its usage APIs and usage, through arti-hyper.

As rust-esplora-client has support for both blocking/async/TLS/SOCKS based on its feature flags, I think that adding Tor support by using arti-hyper, and exposing it as a new feature flag, such as: async-arti-hyper would be a good approach.

NOTE: For the long-run I think that adding a different approach, as a new feature or refactor that is based on usage of different data streams, selected or built by the user, would make it easier to add support for different transport layers using the same API, something similar to what have been done on electrum_client::client::ClientType

How

It can be done by adding a new feature and adding support for all HTTP calls with arti-hyper, I think it's somewhat straightforward, and I can get it started working if it seems like a good approach.

If you are curious about arti-hyper and hyper usage, you can check both docs/examples:

• https://gitlab.torproject.org/tpo/core/arti/-/blob/main/crates/arti-hyper/examples/hyper.rs
• https://github.com/hyperium/hyper/tree/master/examples

[oleonardolima]

@notmandatory @vladimirfomene Do you have any thoughts on this approach?

[notmandatory]

I'd like to target this for bdk 1.1 milestone. Looks like a great enhancement.

[notmandatory]

As posted on discord: I'm not aware of any localhost tor testing frameworks , how do you currently do manual testing? for now it's probably enough to have detailed testing instructions and/or script that can be run manually for others working on that feature until we can come up with something automated in CI

[oleonardolima]

As posted on discord: I'm not aware of any localhost tor testing frameworks , how do you currently do manual testing? for now it's probably enough to have detailed testing instructions and/or script that can be run manually for others working on that feature until we can come up with something automated in CI

I'm currently manually testing with the testnet endpoints on https://blockstream.info/ and trying to manually test with their OnionV3 service too.

Sure, the testing instructions and a script with a different CI step is feasible, I'll follow this strategy then.

[oleonardolima]

update:

I've been working and using the https://blockstream.info/api for building the tests, but it seems flaky when connecting to it over Tor, some exit nodes work, and some receive a 403 Forbidden.

I'll check how arti-hyper, and arti handle the connection to hidden services, as another option in such scenarios, although it's not very stable on their side/implementation yet.

--

edit: Although it requires some changes on arti configuration and compilation strategy, connecting directly with blockstream hidden service seems to solve this problem.