Switch from `reqwest` to `bitreq`

[tnull]

Which crate is this feature request for?

ohttp-relay, payjoin-cli

Please describe the feature you'd like to see added.

While well-known, the reqwest HTTP client unfortunately has a huge dependency tree that makes it not a great fit for security critical applications such as Bitcoin-related programs. To this end, the rust-bitcoin ecosystem had a while back discussed to maintain a shared, saner, HTTP async-compatible client library and by now it is released in the form of bitreq (see also https://github.com/rust-bitcoin/corepc/tree/master/bitreq).

Quite a few projects are now committed to making the switch ASAP (us at LDK are currently switching over everything, bitcoin-payment-instruction has made the switch already, there are open issues/PRs for BDK, etc). Reports from the libraries making the switch speak for themselves, for example, Breez SDK recently reported that dropping reqwest resulted in ~120 fewer transient dependencies and ~5m less binary size.

It would be great if this library could also make the switch soon!

--

Dan's edit tracking prerequisite changes from bitreq

• feat(bitreq): HTTPS Proxy Support for HTTP CONNECT rust-bitcoin/corepc#472 for payjoin to switch
• feat(bitreq): API for custom root certificates at runtime rust-bitcoin/corepc#473 for payjoin & payjoin-cli to switch

[DanGould]

A feature-complete replacement would require bitreq to support HTTPS Proxy support. I think that's the only thing, though

rust-payjoin/payjoin/src/core/io.rs

Line 23 in 7f27460

let proxy = Proxy::all(ohttp_relay.into_url()?.as_str())?;

[DanGould]

We would probably also require custom cert support in bitreq. We need to test _manual-tls feature self-signed certs all over the place because TLS is a big helper to this protocol in practice even though in theory it can be secure without any TLS in e.g. Core, bootstrapping depends on the fact that everyone already has TLS on pretty much every machine.

[tnull]

Cool, mind opening issues for these feature requests over at https://github.com/rust-bitcoin/corepc/issues ?

[DanGould]

Ok, another issue with bitreq is that it seems like it's only ever going to be used for HTTP 1.1. I think we will eventually want h2/h3 for multiplexing and streaming when we do multiparty protocols. I'm not sure if that's just going to be between OHTTP Relays and gateways, or for our payjoin clients as well. some discussion here I have some concerns that at that time we could end up with bitreq AND reqwest across the ecosystem, which would be the worst of both worlds. Why'd LDK-Node use bitreq completely? Doesn't anything that touches esplora clients use reqwest? it looks like the client lets you choose between minreq and reqwest but not bitreq as of today.

[tnull]

Ok, another issue with bitreq is that it seems like it's only ever going to be used for HTTP 1.1. I think we will eventually want h2/h3 for multiplexing and streaming when we do multiparty protocols.

Whether or not we eventually want to support more than just plain HTTP 1.1 is maybe up for discussion. FWIW, we would also have a usecase for it, as then we could use it for our gRPC client

Doesn't anything that touches esplora clients use reqwest?

Migration is inflight (see bitcoindevkit/rust-esplora-client#137), currently blocked on rust-bitcoin/corepc#518.