Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using SOCKS5 proxy to connect to calendar servers but not Bitcoin node? #131

Open
kristapsk opened this issue Oct 29, 2022 · 3 comments
Open

Comments

@kristapsk
Copy link

Currently it looks to me when --socks5-proxy is specified, it is used both to connect to calendar servers and Bitcoin node. Might be useful to be able to use proxy for calendar servers, but not Bitcoin node. Either by being able to specify different settings here or (which might be simpler) to just skip proxy when connecting to localhost and / or LAN. See discussion at raspibolt/raspibolt#1087 for context.

@petertodd
Copy link
Member

Interesting point.

Is there any circumstance where a proxy for the Bitcoin Node makes sense? I personally never use proxies. But I'd be interested in hearing from others.

@kristapsk
Copy link
Author

Is there any circumstance where a proxy for the Bitcoin Node makes sense? I personally never use proxies.

Neither do I, but have seen other people doing that. For example, when travelling and wanting to connect to your Bitcoin node at home via Tor v3 onion from your laptop. Or when you run some site accepting Bitcoin payments on a VPS, where running bitcoind would be expensive, so you configure it to connect to your node at home.

@petertodd
Copy link
Member

Seems like a reasonable enough use-case.

Unfortunately implementing this is going to require quite a bit of refactoring. The way socks5 support is implemented right now is by monkey-patching the the low-level socksocket and create_connection functions:

# Monkey patch socket to use SOCKS5 proxy

The code that actually creates the HTTP connection - what we are monkeypatching - is three libraries deep: python-bitcoinlib -> httplib -> socket

So I'd need to figure out the best way to re-architect these libraries to integrate proxy support in a more modular way.

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

No branches or pull requests

2 participants