Tor is a distributed 'onion' network, that makes it more difficult for an adversary to track any one peer on the network. Tor also is very useful to access the 'uncensored' internet in countries such as China and Iran.
Bitcoin can run easily on the Tor network.
Tor installation & use
todo explain: onion routing (how tor network helps to anonymize), encryption used, exit nodes, routers
Please follow the instructions provided with installation files and read the list of warnings. Tor doesn't magically anonymize all your traffic just because you install it.
Down the page you can find examples how to configure applications to use Tor to anonymize the origin of your traffic.
This is a detailed installation guide for Windows. Before you setup Bitcoin or mIRC to use Tor, please install Tor and start in.
On the taskbar of your compute you'll see a small green onion when Tor is running.
Check "Connect through socks 4 proxy" with the address 127.0.0.1 and port 9050 (the Tor default port number)
Configuring an application to use Tor is also called to torify it. (needs a brief howto here)
the note about bitcoin-otc promote on a more appropriate place in this page? reference to trading and IRC Conducting business using bitcoin-otc can be done more anonymously when directly connected to a Freenode IRC hidden service.
Run bitcoind with -proxy=127.0.0.1:9050 (or whatever your SocksPort is).
These services are running within the tor network. You can connect to them for example using the -connect= parameter to bitcoind. Note that you do not need to use them - tor can also anonymize your normal internet traffic, including bitcoin connections. There are some technical reasons why hidden services may be beneficial, see the tor documentation if you're really interested.
Please add your service here if you run a stable bitcoin node under a tor hidden service.
mIRC is a popular IRC client. This is a guide how to connect to Freenode IRC using Tor + SASL + mIRC.
Register your nick with freenode nickserv
Freenode only allows SASL authenticated users to connect to the onion IRC server. SASL authentication works only with a registered nickname.
Connect to Freenode IRC without using tor & execute
/msg nickserv register <password> <email>
You will see something like this
-NickServ- An email containing nickname activation instructions has been sent to <email>
-NickServ- If you do not complete registration within one day, your nickname will expire.
To finish your nick registration go the provided email and copy/paste the command from e-mail to irc.
Add SASL support to your mIRC installation
Download the SASL.dll and sasl.mrc files and copy them to your mIRC installation directory
Load sasl.mrc script (Alt + R to open script editor, Ctrl + L to load file, browse to sasl.mrc, press OK or "save & exit").
Type /dialog -m SASL.main SASL.main to open the SASL connection manager.
Add Freenode entry.
Network is Freenode.
Username and NS Password must match your nickserv reservation.
Auth Type can be PLAIN
setup mIRC to use Tor
Add the entry for Freenode onion IRC server
Configure mIRC to use a Proxy (your local Tor proxy)
Now you should be able to connect.
Bitcoin forum where this topic is discussed
How Tor works
Unlike Freenet, I2P, etc., Tor's security is very well-defined. While weaknesses do exist (described below), they have been known since Tor was created, and new weaknesses of significance are not expected.
Tor sends TCP packets over 3 (normal) or 7 (hidden services) Tor relays. This is why it is so slow: your packet might have to go through 100 computers (counting Internet routers) before it reaches its destination. Tor uses multiple layers of encryption that are pulled away for each node. Hence the name The Onion Router, which is always capitalized as Tor, and never TOR or t.o.r.
Say that I want to connect to bitcoin.org through Tor. I first select three Tor relays that I know about. Then, I send a message to my ISP that looks like this:
Send to this IP: <IP of Relay1> <Encrypted data for Relay1>
When Relay1 receives this, he decrypts the payload using his private key. The payload contains this:
Send to this Tor node: <Relay2> <Encrypted data for Relay2>
Relay2 decrypts his payload:
Send to this Tor node: <Relay3> <Encrypted data for Relay3>
Relay3 receives the real TCP payload, which he sends to the destination:
Send to this IP: <IP of destination> <Unencrypted payload>
The payload is not and can not be further encrypted by Tor. However, if the protocol itself uses encryption (HTTPS, SSH, etc.), the data will be encrypted. This means that the last node (the exit node) can see everything you do on HTTP sites, and can steal your passwords if they are transmitted unencrypted. Many people become exit nodes just so they can view this information -- Tor is much more dangerous than open WiFi for snooping!
The encryption arrangement described above ensures that no single Tor node knows both the sender and the destination. Relay1 and your ISP know that you are using Tor and sending a packet at a certain time, but they don't know what you're sending or who you're sending to. Relay3 knows exactly what you're sending, but he can't determine who is sending it because Relay2 and Relay1 are blocking him. All three relays need to work together in order to conclusively connect the sender and the destination.
However, Tor is weak to a timing attack that allows only two participants in certain positions to determine the sender with high accuracy. Consider this Tor connection:
Sender <-> S-ISP <-> Relay1 <-> Relay2 <-> Relay3 <-> D-ISP <-> Destination
If the sender's ISP (S-ISP) and the destination are working together, they can record the size and times of packets sent and received. Over a large number of packets, they can determine with very high accuracy that the sender is, in fact, the person sending packets to the destination. This requires active surveillance or detailed logging by both sides. Relay1 can also perform the same role as S-ISP.
Additionally, more configurations are possible if the underlying connection is not encrypted (normal HTTP, for example):
- S-ISP & Relay3
- Relay1 & Relay3
- S-ISP & D-ISP
- Relay1 & D-ISP
This second set can always see that the sender is connected to the destination, but they can only see what the sender is doing on the site if the connection is not encrypted. (Pathnames are encrypted in HTTPS.)
Because the first relay (the entry node) is a weak point in the connection, Tor takes certain defensive measures. When you first start Tor, it chooses three entry guards that don't change for the entire time that you run Tor. You will always use one of those three unless one goes down. If all of those nodes are safe and your ISP is safe, then you are OK.
These timing attacks are of special importance to Bitcoin because anyone can be the "destination" in a connection. Packets are broadcast to every peer in the Bitcoin network. This might allow your ISP alone to associate your transactions to you without much difficulty. However, a timing attack relies on receiving at least several dozen packets from the sender, so the "destination" might actually have to be one of your direct Bitcoin peers. It's not too difficult to flood the Bitcoin network with peers, though. Because of this attack, it is wise to use an EWallet instead of the Bitcoin client when using Tor.
To discover Tor relays, Tor uses a centralized directory server model. There are nine authoritative directory servers. To become a relay, you register with one of these. The directory servers share their data and produce a network status consensus document every so often containing all Tor nodes. Tor clients don't connect directly to the authoritative directory servers -- they connect to one of many directory mirrors, which have a copy of the network status consensus. Since there is no peer-to-peer bootstrap mechanism in Tor, the entire network can be destroyed if half of the authoritative directory servers are destroyed, and the entire network can be subverted if half of the authoritative directory servers become evil.
Hidden services allow both the sender and destination to remain anonymous. A hidden service connection is made like this:
- The destination tells several Tor relays to act as introduction points for the hidden service. The destination stays connected to all of these introduction points through a regular three-node Tor circuit.
- The destination registers these introduction points on a Tor DHT. The introduction points are associated with the first 16 characters of an encoded SHA-1 hash of the destination's key. This is the information in .onion addresses. The use of SHA-1 is a possible weakness.
- The sender creates a four-node Tor circuit. The fourth node is called the rendezvous point.
- The sender searches the DHT for the introduction points of the desired hidden service. The sender connects to one through a regular three-node Tor circuit and, through the introduction point, tells the destination about the rendezvous point he has chosen.
- The destination connects to the rendezvous point over a three-node Tor circuit. The sender and destination are now in contact over a seven-node connection.
For clients, hidden services are more secure than encrypted Tor HTTPS connections because:
- If the destination remains anonymous, they are less likely to become controlled by an evil party.
- The destination's ISP isn't involved as they are in the HTTPS case. Only these configurations are possible for a timing attack:
- S-ISP & Destination
- Relay1 & Destination
Running a hidden service is more dangerous, however. A simple intersection attack can be performed by the hidden service's ISP alone:
- Your Internet service is cut off.
- If the hidden service went down at that exact moment, you are unmasked.
The same sort of timing attacks as above are also possible.
See the Tor design paper for more info.
External Tor Hidden Services
- MyBitcoin - A web-based transaction processor for Bitcoin
- The Bitcoin 4 Cash Service
- Freenode hidden service