Tor hidden service support

Hello everyone,

a few days ago we merged Tor hidden service support in mainline. This means that it's now possible to run a hidden service bitcoin node, and connect to other bitcoin hidden services (via a Tor proxy) when running git HEAD. See doc/Tor.txt for more information. This is expected to be included in the 0.7 release.

Additionally, such addresses are exchanged and relayed via the P2P network. To do so, we reused the fd87:d87e:eb43::/48 IPv6 range. Each address in this 80-bit range is mapped to an onion address, and treated as belonging to a separate network. This network range is the same as used by the OnionCat application (though we do not use OnionCat in any way), and is part of the RFC4193 Unique Local IPv6 range, which is normally not globally routable.

Other clients that wish to implement similar functionality, can use this test case: 5wyqrzbvrdsumnok.onion == FD87:D87E:EB43:edb1:8e4:3588:e546:35ca. The conversion is simply decoding the base32 onion address, and storing the resulting 80 bits of data as low-order bits of an IPv6 address, prefixed by fd87:d87e:eb43:. As this range is not routable, there should be no compatibility problems: any unaware IPv6-capable code will immediately fail when trying to connect.

> Additionally, such addresses are exchanged and relayed via the P2P network.
> To do so, we reused the fd87:d87e:eb43::/48 IPv6 range. Each address in this
> 80-bit range is mapped to an onion address, and treated as belonging to a
> separate network. This network range is the same as used by the OnionCat
> application (though we do not use OnionCat in any way), and is part of the
> RFC4193 Unique Local IPv6 range, which is normally not globally routable.
>
> Other clients that wish to implement similar functionality, can use this
> test case: 5wyqrzbvrdsumnok.onion == FD87:D87E:EB43:edb1:8e4:3588:e546:35ca.
> The conversion is simply decoding the base32 onion address, and storing the
> resulting 80 bits of data as low-order bits of an IPv6 address, prefixed by
> fd87:d87e:eb43:. As this range is not routable, there should be no
> compatibility problems: any unaware IPv6-capable code will immediately fail
> when trying to connect.

You are going to want to include the block of the Phatom project as well: https://code.google.com/p/phantom/ fd00:2522:3493::/48

And the one for 'garlicat' for I2P, which might be more complex due to I2P's addressing: fd60:db4d:ddb5::/48

Note that while these blocks are not expected to be routable, that people may in fact have interfaces, routing tables and packet filters on their machines configured with up to all three of those networks for the purposes therein.

On Tue, Jun 26, 2012 at 7:01 PM, grarpamp <grarpamp@gmail•com> wrote:

> You are going to want to include the block of the Phatom project as well:
> https://code.google.com/p/phantom/
> fd00:2522:3493::/48

Perhaps some argument to add blocks to the IsRoutable check is in order? Then people who use overlay networks that are actually routable but which use otherwise private space can just add the relevant blocks.

> Note that while these blocks are not expected to be routable, that
> people may in fact have interfaces, routing tables and packet filters
> on their machines configured with up to all three of those networks
> for the purposes therein.

Note that while the hidden service support in bitcoin uses a compatible IPv6 mapping with onioncat, it is _not_ onioncat, does not use onioncat, does not need onioncat, and wouldn't benefit from onioncat. The onioncat style advertisement is used because our protocol already relays IPv6 addresses. The connections are regular tor hidden service connections, not the more-risky and low performance ip in tcp onioncat stuff.

On 2012 June 26 Tuesday, Pieter Wuille wrote:

> Additionally, such addresses are exchanged and relayed via the P2P network.
> To do so, we reused the fd87:d87e:eb43::/48 IPv6 range. Each address in

Yuck. Can't we pinch a few of the addr.services bits to store an address family? AF_INET, AF_INET6, AF_CUSTOM_TOR, and leave space for a few more would be, say, four bits out of 64 mostly unused.

Andy

GregM, wasn't sure how to answer your question, and as to conflicts [1]. I think I grasped it in my reply to something on tor-talk, which is on its way here pending moderation due to bcc. I put that part below. The FYI referred to seednodes as they exist on Tor / I2P today.

> You are going to want to include the block of the Phatom project as well:
>> https://code.google.com/p/phantom/
>> fd00:2522:3493::/48

> Perhaps some argument to add blocks to the IsRoutable check is in
> order?  Then people who use overlay networks that are actually
> routable but which use otherwise private space can just add the
> relevant blocks.

/ [1] Well bitcoin wouldn't know to offload traffic to any of those / blocks, or a specific host on them, if you had them set up locally / via *Cat or Phantom... for bitcoin use. It would probably end up / half useful similar to the above FYI. But that would just affect / bitcoin, not whatever else you were running on them.