Internet IP address is revealed when running bitcoind behind Tor #1192

Judging from the connections my node has made just today, I don't see a single node running behind tor that isn't revealing it's actual internet IP address. Surely this isn't ideal, is it?

Example debug.log entries:-

03/05/12 13:55:16 receive version message: version 60000, blocks=178422, us=127.0.0.1:55963, them=24.7.178.63:8333, peer=p2hwc26zdsrqxiix.onion:8333 03/05/12 13:56:04 receive version message: version 50200, blocks=178422, us=127.0.0.1:57988, them=178.79.170.173:28333, peer=7hxvg2lvr2ashzli.onion:8333 03/05/12 13:56:17 receive version message: version 50200, blocks=178422, us=127.0.0.1:46801, them=106.187.36.183:28333, peer=siqdznszjf4e6v5j.onion:8333 03/05/12 13:57:02 receive version message: version 50300, blocks=178422, us=127.0.0.1:53726, them=81.20.130.168:8333, peer=sjdntqu5roj4q6lo.onion:8333 03/05/12 14:06:48 receive version message: version 50300, blocks=178423, us=127.0.0.1:34354, them=81.20.130.168:8333, peer=sjdntqu5roj4q6lo.onion:8333 03/05/12 14:06:53 receive version message: version 60000, blocks=178423, us=127.0.0.1:55967, them=24.7.178.63:8333, peer=p2hwc26zdsrqxiix.onion:8333 03/05/12 14:06:57 receive version message: version 50200, blocks=178423, us=127.0.0.1:58891, them=178.79.170.173:28333, peer=7hxvg2lvr2ashzli.onion:8333 03/05/12 14:07:03 receive version message: version 50200, blocks=178423, us=127.0.0.1:47146, them=106.187.36.183:28333, peer=siqdznszjf4e6v5j.onion:8333 03/05/12 15:21:50 receive version message: version 50200, blocks=178431, us=127.0.0.1:51802, them=106.187.36.183:28333, peer=siqdznszjf4e6v5j.onion:8333 03/05/12 15:24:30 receive version message: version 50300, blocks=178432, us=127.0.0.1:50175, them=81.20.130.168:8333, peer=sjdntqu5roj4q6lo.onion:8333 03/05/12 17:36:24 receive version message: version 50200, blocks=178452, us=127.0.0.1:47011, them=178.79.170.173:28333, peer=7hxvg2lvr2ashzli.onion:8333 03/05/12 17:52:30 receive version message: version 50300, blocks=178453, us=127.0.0.1:40151, them=81.20.130.168:8333, peer=sjdntqu5roj4q6lo.onion:8333 03/05/12 18:02:40 receive version message: version 50200, blocks=178456, us=127.0.0.1:59146, them=106.187.36.183:28333, peer=siqdznszjf4e6v5j.onion:8333 03/05/12 18:04:10 receive version message: version 60000, blocks=178456, us=127.0.0.1:56099, them=24.7.178.63:8333, peer=p2hwc26zdsrqxiix.onion:8333 03/05/12 18:58:37 receive version message: version 60000, blocks=178463, us=127.0.0.1:56108, them=24.7.178.63:8333, peer=p2hwc26zdsrqxiix.onion:8333 03/05/12 18:59:32 receive version message: version 50200, blocks=178463, us=127.0.0.1:34445, them=106.187.36.183:28333, peer=siqdznszjf4e6v5j.onion:8333 03/05/12 20:48:21 receive version message: version 50200, blocks=178476, us=127.0.0.1:34890, them=178.79.170.173:28333, peer=7hxvg2lvr2ashzli.onion:8333 03/05/12 21:36:40 receive version message: version 50300, blocks=178480, us=127.0.0.1:57949, them=81.20.130.168:8333, peer=sjdntqu5roj4q6lo.onion:8333 03/05/12 21:37:47 receive version message: version 60000, blocks=178480, us=127.0.0.1:56334, them=24.7.178.63:8333, peer=p2hwc26zdsrqxiix.onion:8333 03/05/12 21:38:00 receive version message: version 50200, blocks=178480, us=127.0.0.1:37606, them=178.79.170.173:28333, peer=7hxvg2lvr2ashzli.onion:8333 03/05/12 21:39:22 receive version message: version 50200, blocks=178480, us=127.0.0.1:39394, them=106.187.36.183:28333, peer=siqdznszjf4e6v5j.onion:8333 03/05/12 22:01:27 receive version message: version 50200, blocks=178484, us=127.0.0.1:39933, them=106.187.36.183:28333, peer=siqdznszjf4e6v5j.onion:8333 03/05/12 22:03:56 receive version message: version 50300, blocks=178484, us=127.0.0.1:43288, them=81.20.130.168:8333, peer=sjdntqu5roj4q6lo.onion:8333 03/05/12 22:04:06 receive version message: version 60000, blocks=178484, us=127.0.0.1:56343, them=24.7.178.63:8333, peer=p2hwc26zdsrqxiix.onion:8333 03/05/12 22:04:14 receive version message: version 50200, blocks=178484, us=127.0.0.1:40180, them=178.79.170.173:28333, peer=7hxvg2lvr2ashzli.onion:8333

Admittedly, there are only 4 unique nodes in that list.....

Please don't open issues on random behavior from other nodes you don't control or know anything about. I run a node behind tor which I have explicitly setup to share my public IP because is dual attached and I only offer the tor side connectivity for the benefit of tor users and I very much do want it to bridge to the regular network.

Especially don't open ones with alarmist headlines— most bitcoin users with tor are connecting out, not running hidden services which is what you're measuring. It's trivial enough to see that when you're locally using proxy mode (e.g. tor) for your outbound connections that it does not send the public IP.

Because there is no explicit hidden service support before Peter's patches these nodes are probably just regular nodes and have no way of knowing that they're connected to tor.

You can't expect nodes that were never intended to run as a Tor hidden service, are able to deal with this. If there are problems like this with code from my torhs branch, please report them in the relevant pull request.

I thought tor awareness had been in the code for a while. I remember seeing a fTor flag in the code checking if the proxy port is 9050, so thought it better to raise it as a potential issue (rather than a definite one). happy to hear it's not an issue.

Code for being behind a Tor proxy existed, yes. For outgoing connections behind a Tor proxy, the code should definitely not leak its ipv4 address. But what you're doing here is making connections to older code from 127.0.0.1, and expecting them to know that that is Tor (without them supporting running as a Tor hidden service).