Skip to content

Switch from reqwest to bitreq #1288

Open

Description

@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

Activity

  1. DanGould commented on Jan 22, 2026

    @DanGould
    Member

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

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

  2. DanGould commented on Jan 22, 2026

    @DanGould
    Member

    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.

  3. tnull commented on Jan 22, 2026

    @tnull
    Author

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

  4. DanGould commented on Apr 23, 2026

    @DanGould
    Member

    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.

  5. tnull commented on Apr 23, 2026

    @tnull
    Author

    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.

  6. benalleng commented on Jun 16, 2026

    @benalleng
    Collaborator

    With payjoin-cli now having bitreq in the tree we can take another look at moving this forward #1646 (review)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesthelp wantedExtra attention is neededtrackingHigh-level tracking issues

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions