Topic: TOR and I2P (Read 22951 times)

I feel obligated to post this in this thread to.
Using Bitcoin over Tor might be dangerous. (It doesn't have to though!)


Here is the message: https://bitcointalksearch.org/topic/for-a-website-taking-payments-with-bitcoins-better-ip-or-bitcoin-addresses-129

There isn't an easy way to specify what to bind to.

Modify the source code, re-compile it.

Or just use a firewall. That's even easier.

Any answers to how to make bitcoin bind only to localhost:8333?  Also, how can I make bitcoin broadcast the torland address instead of the external IP?

I'm trying to set up a hidden service on tor, and I've copied the following into my torrc:

HiddenServiceDir /some/directory
HiddenServicePort 8333 127.0.0.1:8333

but now I'd like to make bitcoin bind only to 127.0.0.1:8333 whereas "netstat -lp" shows that it is listening on all interfaces. I haven't easily found how to specify this.

suggestions?

Maybe you could mirror the nodelist from the IRC-server over http or ftp if the load's not too high.

When using proxy port 9050, it will only make one attempt to connect to IRC, then give up, since it knows it will probably always fail because IRC servers ban all the TOR exit nodes.  If you're using another port, it would assume it might be a regular old normal proxy and would keep retrying IRC at longer and longer intervals.  You should not use Polipo or Privoxy as those are http filters and caches that would corrupt Bitcoin's messages if they make any changes.  Bitcoin might be trying to overcome it by reconnecting.  You should use port 9050.

As riX says, the "is giving Tor only an IP address. Apps that do DNS..." warnings are nothing to worry about.  Bitcoin doesn't use DNS at all in proxy mode.

Since Bitcoin can't get through to IRC through Tor, it doesn't know which nodes are currently online, so it has to try all the recently seen nodes.  It tries to conserve connection attempts as much as possible, but also people want it to connect quickly when they start it up and reconnect quickly if disconnected.  It uses an algorithm where it tries an IP less and less frequently the longer ago it was successful connected.  For example, for a node it saw 24 hours ago, it would wait 5 hours between connection attempts.  Once it has at least 2 connections, it won't try anything over a week old, and 5 connections it won't try anything over 24 hours old.

OK thanks riX.

So, once Bitcoin has connected to at least one node then the -connect option will eliminate the 6667 warnings.

Is Bitcoin using any kind of 'peer exchange' or DHT because this still does not seem to prevent the constant Tor 'exit' warnings and therefore Tor's requirement to try a new 'exit' node for connection. (which is problematic ! For Tor anyway, not Bitcoin ) This is really what I meant by "However, Bitcoin must try to connect with all nodes to check its not missing any blocks ?" I just communicated it incorrectly.

I2P would seem to be a much easier solution to implement to increase a Bitcoins users anonymity.
http://forum.i2p2.de/viewtopic.php?t=3946&sid=213e3cd998db98c4511675ecbba17af4

I'm also testing JonDonym http://anonymous-proxy-servers.net/ (only the paid services support socks !) However, they do accept paysafecards which can currently be brought in exchange for Bitcoins.

Bitcoin is using ip-adresses, not hostnames, so there's no need for dns. Tor thinks that since bitcoin is trying to connect to an ip without looking it up through tors internal dns, it's using a regular dns.


Bitcoin is using port 8333, even though it's relaying it through tor on port 9050.. 
6667 is irc, bitcoin uses an irc-server to distribute the nodelist. (If you know the ip of another computer running bitcoin, you can specify the -connect option to avoid using the nodelist).


No, it's enough if you're just connected to one single node, as long as it's got a copy of the longest block-chain.

OK So, I tried to set-up a sudo-anonymous crypto 'Bitcoin Bank' experiment using Tor.

Whilst it was mostly successful using the standard 9050 socks port 'default setup' i.e. I got connectivity to other Bitcoin nodes through Tor; I did encounter various issues and multiple Warning messages.

"Your application (using socks5 on port xxxx) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider
using Socks4A (e.g. via polipo or socat) instead."

https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#IkeepseeingthesewarningsaboutSOCKSandDNSandinformationleaks.ShouldIworry.3F

I eventually fixed this using Privoxy and Stunnel (because i'm more familiar with those) However, you could use polipo and Stunnel.

However, I still get occasional warnings for these ports 8333 (expected Bitcoin 'default') and 6667 (which if i'm not mistaken is an IRC port !?)

Connecting Bitcoin through Tor also makes Tor repeatedly change exit nodes looking to establish 'missing' connections to a [scrubbed] address. At first I assumed that this was because Tor exits might be blocking port 8333 or 6667, but that is mostly not the case !

Other P2P applications through Tor can 'ignore' IP addresses that they cannot connect to and the application can still get the job done without 'warning'. However, Bitcoin must try to connect with all nodes to check its not missing any blocks ! So, if an IP range where only 1 Bitcoin node is running is blocking Tor exit nodes, then presumably this will always be the case ?

This is problematic for many reasons.

I also run a Tor relay and exit node and had similar ideas for Tor integration with Bitcoin.

Tor can be very fast if you edit your config correctly. You just need to limit the connectivity with slow servers and only use the fastest nodes where possible. I also like to block any nodes in 'problem' internet countries, which also tend to have slower connectivity, this also increases overall privacy somewhat. I also block Unnamed, ididnteditheconfig, any servers that I don't like the name of and unstable servers.

This config. example is only good for non-relay / non-exit personal use. Although its great for P2P

AvoidDiskWrites 1

ExcludeNodes SlowServer,{sd},{pk},{tn},{ae},{by},{in},{bh},{th},{ye},{mm},{eg},{sg},{ma},{cu},{qa},{sa},{by},{md},{tm},{tr},{et},{jo},{sy},{om},{ir},{az},{uz},{kz},{kg},{af},{cn},{bd},{vn},{ng},{gh},{ro},{lb},{ru},{iq},{ly},{ve},{zw},{my},{mo},{kr},unnamed,ididnteditheconfig ...etc.

StrictEntryNodes 1

EntryNodes (Select Fast Entry and Authority Servers from http://trunk.torstatus.kgprog.com/index.php?Fast=0 )

StrictExitNodes 1

ExitNodes (Select Fast Exit Only from http://trunk.torstatus.kgprog.com/index.php?Fast=0 )

It's also a good idea to alter the time which Tor takes to automatically switch circuits and some other custom settings https://www.torproject.org/tor-manual.html

Hope this helps

Yeah, I2P is much easier to automate in that regard. I could setup some .onions manually and post them to the list to be used as seeds. I have always-on nodes that can just be tied to Tor with minimal effort.

I used to be a big advocate of Tor, but after I started using I2P I found it to be much, much better in a lot of ways. Biggest improvement is speed.   Too bad they wrote it in Java.

I've been thinking about that for a while.  I want to add the backend support for .onion addresses and connecting to them, then go from there.

There aren't many .onion addresses in use for anything because the user has to go through a number of steps to create one.  Configure TOR to generate a .onion address, restart TOR, configure it with the generated address.  Perhaps this is intentional to keep TOR so it can't be integrated into file sharing programs in any sufficiently automated way.

Hello,

I have had another idea.

It would be very cool to be able to have TOR and I2P seeds. For example: I could run BT within TOR-land on a .onion address. A client could connect their BT to TOR and have it seed from a .onion address and use it as a connected peer. (Likewise for I2P: someone could run a .i2p service that is -- well -- BC).

I might setup a couple of nodes in this fashion and post the tunnels on this forum. I already run a lot of I2P and TOR nodes so adding BC to the mix is quite trivial.

I support the idea of making BC compatible with TOR and I2P to increase the privacy of the system. I mean: why re-invent the wheel? There are thousands of mix network nodes just sitting there that can be used to enhance BC.

Cheers!