Skip to content

Conversation

@TheBlueMatt
Copy link
Member

reqwest has an absolutely insane dependency tree, with
anti-features (like insanely-fast-unsafe-IDN parsing) baked in.
Instead, the rust-bitcoin ecosystem is starting to move to bitreq
which is relatively simple, only depends (even optionally) on
tokio and rustls, and doesn't bother with crap like IDNs.

Here we switch over, maintaining the ability to proxy connections
for those that need that.

@TheBlueMatt TheBlueMatt force-pushed the main branch 2 times, most recently from ccfa0dd to 5c4b437 Compare December 28, 2025 14:37
`reqwest` has an absolutely insane dependency tree, with
anti-features (like insanely-fast-unsafe-IDN parsing) baked in.
Instead, the rust-bitcoin ecosystem is starting to move to `bitreq`
which is relatively simple, only depends (even optionally) on
`tokio` and `rustls`, and doesn't bother with crap like IDNs.

Here we switch over, maintaining the ability to proxy connections
for those that need that.
Sadly, we'd exposed `reqwest` in our public API, so we have to
bump the version for the swap to `bitreq`.
@TheBlueMatt
Copy link
Member Author

Looks like https://lnurl.mutinynet.com/.well-known/lnurlp/refund is sometimes failing (500s or just disconnecting). Its not a bitreq issue though I see it locally with curl.

@TheBlueMatt TheBlueMatt force-pushed the main branch 2 times, most recently from 1daa77b to ec0b296 Compare December 28, 2025 17:21
Copy link

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Makes sense to switch this crate to bitreq already, for other applications I'm still a bit sceptical if its feature set is fully ready yet.

Confirmed failing tests pass locally.


impl Default for HTTPHrnResolver {
fn default() -> Self {
HTTPHrnResolver { client: reqwest::Client::new() }
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, seems bitreq has no way to reuse a connection. That might be fine here, but for other applications it seems that might introduce a bunch of unnecessary latency overhead (cf rust-bitcoin/corepc#442).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, for syncing it likely does.

if let Some(proxy) = &self.proxy {
req = req.with_proxy(proxy.clone())
}
let resp = req.send_async().await.map_err(|_| ())?;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out that this is not actually async but currently just spawns a blocking task (i.e., potentially a thread) per request (cf. rust-bitcoin/corepc#441).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oof, yea, that's pretty gnarly...maybe we wait for that to be fixed....let me see if claude can do it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, got a PR up for it. Gonna go ahead and land this but we should wait for rust-bitcoin/corepc#448 to release.

@TheBlueMatt TheBlueMatt merged commit 13dc0dd into rust-bitcoin:main Jan 7, 2026
11 of 22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants