[tor-talk] [Bitcoin-development] Tor hidden service support

[Fabio Pietrosanti (naif)]

Is bitcoin software going to incorporate tor binaries within the
application standard application and automatically create a Tor Hidden
Service on behalf of end-user?

Are there any direction regarding this kind of integration?

Regarding the addressing, why not use directly the .onion address?

They represent in parallel:
 - Routing information (providing a path to the destination)
 - Proof of identity (owning the private RSA key)

Which is the reason to map it to an IPv6 address?

-naif

p.s. Reading https://github.com/bitcoin/bitcoin/blob/master/doc/Tor.txt

On 6/27/12 1:04 AM, grarpamp wrote:
> /// Meanwhile, on bitcoin-devel...
> 
> 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.
> 
> --
> Pieter