TorConfig: HTTP calls (RGS, scoring, LNURL-auth) bypass SOCKS proxy

[FreeOnlineUser]

Problem

When TorConfig is set, only peer connections to .onion addresses are routed through the SOCKS proxy. All HTTP calls made by ldk-node (RGS gossip sync, pathfinding scoring, and LNURL-auth) go direct over clearnet.

This means even a node connecting exclusively to .onion peers still leaks its IP to rapidsync.lightningdevkit.org on every gossip sync cycle.

Proposal

Route HTTP calls through the configured SOCKS5 proxy when TorConfig is set. Three call sites in ldk-node use bitreq for HTTP:

• gossip.rs: RGS snapshot fetch
• scoring.rs: external pathfinding scores
• lnurl_auth.rs: LNURL-auth challenge/response

bitreq's proxy feature currently supports HTTP CONNECT but not SOCKS5. SOCKS5 support (~180 lines, RFC 1928) would need to be added to bitreq, either upstream or via fork.

This could be unconditional (always proxy HTTP when TorConfig is set) or gated behind an opt-in flag. Happy to hear what the maintainers prefer.

Context

I'm building a mobile Lightning node (Android) with embedded Tor (Arti). I have a working implementation of this: SOCKS5 in a bitreq fork + proxy plumbing in ldk-node. Tested on a live node with an open channel. Happy to submit a PR if this direction makes sense.

[tnull]

Yes, this is known and was so far a dedicated design decision, as in this first step we mainly wanted to be able to peer with .onion nodes. Def. feel free to work on improving this though, but we'd then need to make sure that we can really proxy everything over Tor, i.e., all chain sources for example would need to work.

See rust-bitcoin/corepc#472 for the bitreq discussion on adding SOCKS support, btw.

[FreeOnlineUser]

Thanks. I have a working implementation: SOCKS5 in a bitreq fork + route_all_traffic plumbing in ldk-node. Tested on a live node with an open channel over Tor.

Plan is to upstream the bitreq SOCKS5 support first (see rust-bitcoin/corepc#472), then submit the ldk-node PR that wires HTTP calls through the SOCKS proxy when TorConfig is set.

For chain sources: bitcoind RPC is typically local (127.0.0.1) so doesn't need proxying. Esplora would need it, but that's just another bitreq call.

[tnull]

Cool, yeah, then the next step is really to move forward with SOCKS support in bitreq, before we can revisit here.