You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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.
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?
Activity
DanGould commentedon Jan 22, 2026
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
DanGould commentedon Jan 22, 2026
We would probably also require custom cert support in bitreq. We need to test
_manual-tlsfeature 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 commentedon Jan 22, 2026
Cool, mind opening issues for these feature requests over at https://github.com/rust-bitcoin/corepc/issues ?
DanGould commentedon Apr 23, 2026
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
bitreqANDreqwestacross the ecosystem, which would be the worst of both worlds. Why'd LDK-Node usebitreqcompletely? 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 commentedon Apr 23, 2026
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
Migration is inflight (see bitcoindevkit/rust-esplora-client#137), currently blocked on rust-bitcoin/corepc#518.
benalleng commentedon Jun 16, 2026
With payjoin-cli now having bitreq in the tree we can take another look at moving this forward #1646 (review)