Add Socks5 Proxy

[rajarshimaitra]

This is an attempt to complete the proxy support for bitcoin core json rpc. After apoelstra/rust-jsonrpc@7c94adf the rust-jsonrpc http transport optionally takes in a proxy configuration with a proxy feature flag.

This PR accomodates that change into this library.

Goal is to connect with a bitcoin core RPC port via Tor proxy, which is useful to connect a wallet to a home node RPC end point for syncing, which usually do not have static IP address.

This PR is draft because I can't get it to connect successfully to a regtest RPC endpoint. I have reported my attempts for that in #246 ..

Also this PR currently builds on an unreleased version of rust-jsonrpc as the new proxy feature isn't released yet.

Intent of this PR is for initial comment and any help in testing out actual RPC communication via Tor.

[rajarshimaitra]

I have been able to connect to a bitcoind node with a simple Socks5 Proxy server using https://github.com/EAimTY/socks5-server.

For anyone wanna try it out..

• run bitcoind in regtest mode.

• Start the proxy server https://github.com/EAimTY/socks5-server, using: cargo run --package socks5-server --example simple_socks5 . This should start the Socks5 Proxy server at 127.0.0.1:5050.

• Set env variable RPC_COOKIE=<your/cookies/path>, RPC_URL=127.0.0.1:18443, PROXY_URL=127.0.0.1:5000.

• Run the integration tests: cargo run -p integration_test --features proxy

Observe RPC response

Running `target/debug/integration_test`
[DEBUG][bitcoincore_rpc]: JSON-RPC request: getnetworkinfo []
[TRACE][bitcoincore_rpc]: JSON-RPC response for getnetworkinfo: {"version":230000,"subversion":"/Satoshi:23.0.0/","protocolversion":70016,"localservices":"0000000000000449","localservicesnames":["NETWORK","WITNESS","COMPACT_FILTERS","NETWORK_LIMITED"],"localrelay":true,"timeoffset":0,"networkactive":true,"connections":0,"connections_in":0,"connections_out":0,"networks":[{"name":"ipv4","limited":false,"reachable":true,"proxy":"","proxy_randomize_credentials":false},{"name":"ipv6","limited":false,"reachable":true,"proxy":"","proxy_randomize_credentials":false},{"name":"onion","limited":false,"reachable":true,"proxy":"127.0.0.1:9050","proxy_randomize_credentials":true},{"name":"i2p","limited":true,"reachable":false,"proxy":"","proxy_randomize_credentials":false},{"name":"cjdns","limited":true,"reachable":false,"proxy":"","proxy_randomize_credentials":false}],"relayfee":0.00001000,"incrementalfee":0.00001000,"localaddresses":[{"address":"pcsqgbuw5dja3wkwmasziv2scjxyil3goc5w422h2ldkce6z2zc6fuyd.onion","port":18444,"score":4}],"warnings":""}
[DEBUG][bitcoincore_rpc]: JSON-RPC request: getnetworkinfo []
[TRACE][bitcoincore_rpc]: JSON-RPC response for getnetworkinfo: {"version":230000,"subversion":"/Satoshi:23.0.0/","protocolversion":70016,"localservices":"0000000000000449","localservicesnames":["NETWORK","WITNESS","COMPACT_FILTERS","NETWORK_LIMITED"],"localrelay":true,"timeoffset":0,"networkactive":true,"connections":0,"connections_in":0,"connections_out":0,"networks":[{"name":"ipv4","limited":false,"reachable":true,"proxy":"","proxy_randomize_credentials":false},{"name":"ipv6","limited":false,"reachable":true,"proxy":"","proxy_randomize_credentials":false},{"name":"onion","limited":false,"reachable":true,"proxy":"127.0.0.1:9050","proxy_randomize_credentials":true},{"name":"i2p","limited":true,"reachable":false,"proxy":"","proxy_randomize_credentials":false},{"name":"cjdns","limited":true,"reachable":false,"proxy":"","proxy_randomize_credentials":false}],"relayfee":0.00001000,"incrementalfee":0.00001000,"localaddresses":[{"address":"pcsqgbuw5dja3wkwmasziv2scjxyil3goc5w422h2ldkce6z2zc6fuyd.onion","port":18444,"score":4}],"warnings":""}
Version: 230000

[rajarshimaitra]

Now that I am a bit confident that all of this is working, so taking this PR out of draft.. Any suggestion or modification for ways forward to get this merged would be very welcome..

[apoelstra]

@rajarshimaitra we'll definitely need to get a release of jsonrpc out first. To do that we need to tighten up the mutex locking code and also put a bound on the content-length header (or else change the logic to allow arbitrary sized inputs, just not all in one upfront allocation).

I spent some time working on this but got rabbit-holed trying to mock out the code so I could run fuzztests against it.

[rajarshimaitra]

@rajarshimaitra we'll definitely need to get a release of jsonrpc out first. To do that we need to tighten up the mutex locking code and also put a bound on the content-length header (or else change the logic to allow arbitrary sized inputs, just not all in one upfront allocation).

Okay.. Do I need to update something in the jsonrpc repo for this part of the logic?

[apoelstra]

@rajarshimaitra we need to get apoelstra/rust-jsonrpc#76 finished and in, adn then we should be good to go.