-proxy does not work for addresses like 10.x.y.z #25684

Got unexpected behavior when trying to run bitcoind with -proxy setting. -proxy is used to connect to SOCKS5 proxy which is able to access some internal network. bitcoind is started with -noconnect option and network activity is absent (as it should be).

Then I command bitcoin-cli to connect to node with address 10.x.y.z with the command bitcoin-cli addnode 10.x.y.z add

Expected behavior is for bitcoind to initiate connection through proxy.

Actual behavior is bitcoind trying to connect without using proxy.

In the code: CConnman::ConnectNode calls GetProxy and GetProxy returns false because CNetAddr::GetNetwork returns NET_UNROUTABLE.

My take is this is unexpected behavior at minimum and should be documented. Better way is to introduce another option just for the unroutable addresses:

• connect locally (for compatibility reasons, default);
• connect thru proxy;
• don't connect to unroutable addresses.

One more side effect of this: bitcoind may leak information (like - is bitcoin node running at 192.168.0.1) to outside world.

I could work on this. I'm going to reproduce the issue..

The question to ask (in my opinion) is why bitcoind should know about unroutable addresses at all? Why those addresses are treated in a special way? It's not bitcoind's job to know routing rules.

I agree that this is unexpected and should be documented or fixed or made optional.

One more side effect of this: bitcoind may leak information (like - is bitcoin node running at 192.168.0.1) to outside world.

How?

The question to ask (in my opinion) is why bitcoind should know about unroutable addresses at all? Why those addresses are treated in a special way? It's not bitcoind's job to know routing rules.

Bitcoin nodes keep a list of possible addresses of other nodes to connect to. This list is maintained by gossiping known addresses between nodes, including advertising own address to the other nodes, so that others know our address and can connect to us. From this perspective, it is useless to advertise an address like 10.x.y.z to others on the internet because they will not be able to connect back. This is why we have a special NET_UNROUTABLE in the code.

Bitcoin nodes keep a list of possible addresses of other nodes to connect to. This list is maintained by gossiping known addresses between nodes, including advertising own address to the other nodes, so that others know our address and can connect to us. From this perspective, it is useless to advertise an address like 10.x.y.z to others on the internet because they will not be able to connect back. This is why we have a special NET_UNROUTABLE in the code.

Thank you for explaining this.

How?

If bitcoind doesn't broadcast 10.x.y.z addresses as peers, then my assumption is not valid.

I agree that this is unexpected and should be documented or fixed or made optional.

My vote for default behavior is to connect to 10.x.y.z using proxy. But that change would break compatibility. Would it be enough just to document this change?

Would it be enough just to document this change?

There is no central decision maker to answer that question. My advice would be to pick the solution you think is best, open a pull request and see if there will be a rough consensus around it (enough people to review and approve it and no objections).