Add Async OHTTP client

[arminsabouri]

OHTTP lets a client send encrypted requests through a relay so the server can’t see who sent them and the relay can’t see what they contain. The following commit adds optional configurations to enable clients to proxy their requests through an OHTTP relay and gateway.

OHTTP functionality is feature flagged off behind async-ohttp. If a client provided OHTTP config it will attempt to use the relay instead of the target resource directly.

---

This work was first started by @alexlwn123
Tested against a blockstream's electrs and running an OHTTP relay and OHTTP Gateway locally. Automated tests are still TODO.

Seeking concept Ack/Nack

[luisschwab]

Concept ACK, this is a cool ideia. We are, however, in the process of completely dropping reqwest/minreq in favor of bitreq. Can you change the PR to use that?

[arminsabouri]

Concept ACK, this is a cool ideia. We are, however, in the process of completely dropping reqwest/minreq in favor of bitreq. Can you change the PR to use that?

Sure. Looks like the bitreq migration is a WIP #137. I may wait till thats in good shape before rebasing my commits on top of that.

[pseudozach]

I’ve also got a branch that ports this to the current bitreq client and gets the CI passing:
https://github.com/pseudozach/rust-esplora-client/tree/ohttp-bitreq

I also ended up building a compatible Bitcoin-HPKE OHTTP gateway (obitcoin) so I could actually do end-to-end testing with the client.

If any of that is useful, I’m happy to fold the gateway-backed smoke test, CI workflow, or related pieces into this PR, or you can cherry-pick whatever is helpful.

[arminsabouri]

I’ve also got a branch that ports this to the current bitreq client and gets the CI passing: https://github.com/pseudozach/rust-esplora-client/tree/ohttp-bitreq

This was useful ref for marking certain deps as duplicates. Thank you.

I also ended up building a compatible Bitcoin-HPKE OHTTP gateway (obitcoin) so I could actually do end-to-end testing with the client.
If any of that is useful, I’m happy to fold the gateway-backed smoke test, CI workflow, or related pieces into this PR, or you can cherry-pick whatever is helpful.

I suppose it could reduce the test boilerplate in this PR. i.e removing my dummy gateway. Do you already have a int. . e2e test that uses your gateway?

[pseudozach]

I’ve also got a branch that ports this to the current bitreq client and gets the CI passing: https://github.com/pseudozach/rust-esplora-client/tree/ohttp-bitreq

This was useful ref for marking certain deps as duplicates. Thank you.

happy to hear that!

I suppose it could reduce the test boilerplate in this PR. i.e removing my dummy gateway. Do you already have a int. . e2e test that uses your gateway?

e2e test is available here: https://github.com/pseudozach/rust-esplora-client/blob/ohttp-bitreq/tests/ohttp_smoke.rs
and runs here: https://github.com/pseudozach/rust-esplora-client/blob/ohttp-bitreq/.github/workflows/ohttp-smoke.yml

[arminsabouri]

Cleaned up the commits. Couple things are bothering me.

1. There is alot of boiler plate that could and should be abstracted away. things like bhttp payload construction. Assuming ohttp gets integrated into other clients in this space we could deduplicate this code. I already started putting together a ohttp-client crate. I'll share it later. Probably not a blocker for this PR -- something that could be refactored in a follow up. Maintainers please lmk if you disagree.
2. just audit fails on the second commit bc of the ohttp-relay dep. I could go the route @pseudozach went with (above) however, I would want the test harness to create and clean up the relay/gateway and electrum server instead of CI doing all of that.

The other thing worth revisiting is depending on ohttp vs bitcoin-ohttp. I dont see a compeling reason to use the secp256k1 curve for hpke. I think the main point that justified bitcoin-ohttp was clients already are using the same crypto primitives (secp256k1, sha256, polychaha). The tradeoff is clients that use the bitcoin-ohttp dep cannot use any of the existing ohttp libraries and/or infra. And this becomes a maintaince headache -- esp as new features comes up such as, PQ support and ohttp-streaming