[Bitcoin-development] Tor hidden service support

2012-06-26 Thread Pieter Wuille
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


Hello everyone,
weve just merged tor hidden service support in git master, so it is now possible to have a bitcoin node that is reachable
-- 
Pieter

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Tor hidden service support

2012-06-26 Thread grarpamp
 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.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Tor hidden service support

2012-06-26 Thread Gregory Maxwell
On Tue, Jun 26, 2012 at 7:01 PM, grarpamp grarp...@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.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development