Discussions about using TOR and I2P for Bitcoin
2010 Jan 16
See all posts
Discussions about using TOR and I2P for Bitcoin @ Satoshi Nakamoto
- Author
-
Satoshi Nakamoto
- Email
-
satoshinakamotonetwork@proton.me
- Site
-
https://satoshinakamoto.network
The Madhatter
Number of connections?
January 16, 2010, 11:22:55 PM
Hello,
I have had another idea. Tongue~
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. Cheesy~
Cheers!
Satoshi Nakamoto
January 20, 2010, 10:05:28 PM
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.
The Madhatter
January 24, 2010, 08:52:59 PM
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. Wink Too bad they wrote it in Java.
Quote from: satoshi on January 20, 2010, 10:05:28 PM
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.
BitcoinFX
February 01, 2010, 09:36:47 PM
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 Smiley
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 Wink~
BitcoinFX
February 01, 2010, 10:08:54 PM
OK So, I tried to set-up a sudo-anonymous crypto ‘Bitcoin Bank'
experiment using Tor. Grin~
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. Huh~
riX
February 02, 2010, 10:36:56 PM
Quote from: BitcoinFX on February 01, 2010, 10:08:54 PM
"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."
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.
Quote from: BitcoinFX on February 01, 2010, 10:08:54 PM
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 !?)
Bitcoin is using port 8333, even though it's relaying it through tor
on port 9050.. Tongue 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).
Quote from: BitcoinFX on February 01, 2010, 10:08:54 PM
However, Bitcoin must try to connect with all nodes to check its not
missing any blocks !
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.
BitcoinFX
February 03, 2010, 03:31:33 PM
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 Wink~ ) 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. Grin~
Satoshi Nakamoto
February 04, 2010, 12:30:50 AM
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.
Discussions about using TOR and I2P for Bitcoin
2010 Jan 16 See all postsSatoshi Nakamoto
satoshinakamotonetwork@proton.me
https://satoshinakamoto.network
Hello,
I have had another idea. Tongue~
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. Cheesy~
Cheers!
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.
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. Wink Too bad they wrote it in Java.
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 Smiley
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 Wink~
OK So, I tried to set-up a sudo-anonymous crypto ‘Bitcoin Bank' experiment using Tor. Grin~
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. Huh~
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.. Tongue 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 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 Wink~ ) 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. Grin~
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.