* [Bitcoin-development] Tor hidden service support
@ 2012-06-26 14:11 Pieter Wuille
2012-06-26 23:01 ` grarpamp
2012-06-27 8:47 ` [Bitcoin-development] " Andy Parkins
0 siblings, 2 replies; 6+ messages in thread
From: Pieter Wuille @ 2012-06-26 14:11 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 186 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] Tor hidden service support
2012-06-26 14:11 [Bitcoin-development] Tor hidden service support Pieter Wuille
@ 2012-06-26 23:01 ` grarpamp
2012-06-27 0:14 ` Gregory Maxwell
[not found] ` <CAD2Ti29tMRCoW0rBSH738=0LpMfnGSJoSGYubV2-qQ9a6SC=zQ@mail.gmail.com>
2012-06-27 8:47 ` [Bitcoin-development] " Andy Parkins
1 sibling, 2 replies; 6+ messages in thread
From: grarpamp @ 2012-06-26 23:01 UTC (permalink / raw)
To: bitcoin-development; +Cc: phantom-protocol
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] Tor hidden service support
2012-06-26 23:01 ` grarpamp
@ 2012-06-27 0:14 ` Gregory Maxwell
[not found] ` <CAD2Ti29tMRCoW0rBSH738=0LpMfnGSJoSGYubV2-qQ9a6SC=zQ@mail.gmail.com>
1 sibling, 0 replies; 6+ messages in thread
From: Gregory Maxwell @ 2012-06-27 0:14 UTC (permalink / raw)
To: grarpamp; +Cc: bitcoin-development, phantom-protocol
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] Tor hidden service support
2012-06-26 14:11 [Bitcoin-development] Tor hidden service support Pieter Wuille
2012-06-26 23:01 ` grarpamp
@ 2012-06-27 8:47 ` Andy Parkins
1 sibling, 0 replies; 6+ messages in thread
From: Andy Parkins @ 2012-06-27 8:47 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: Text/Plain, Size: 465 bytes --]
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
--
Dr Andy Parkins
andyparkins@gmail•com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Bitcoin-development] [tor-talk] Tor hidden service support
[not found] ` <CAD2Ti28hu6PccXpu4ObcbzWwFq+tchYaCoVY7S=9yakaB-nKjQ@mail.gmail.com>
@ 2012-06-27 9:25 ` grarpamp
0 siblings, 0 replies; 6+ messages in thread
From: grarpamp @ 2012-06-27 9:25 UTC (permalink / raw)
To: bitcoin-development
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bitcoin-development] Tor hidden service support
@ 2012-06-27 19:51 grarpamp
0 siblings, 0 replies; 6+ messages in thread
From: grarpamp @ 2012-06-27 19:51 UTC (permalink / raw)
To: bitcoin-development
Forward past automoderation...
> Reading https://github.com/bitcoin/bitcoin/blob/master/doc/Tor.txt
> 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?
The document (Tor.txt) assumes the bitcoin user has taken care of
that. So no bi-direction needed (I am not TorProject).
> 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?
Seems it's used only within bitcoin code to distinguish which proxy
or native IPvN path to send bitcoin traffic to (or receive from).
It might be simpler than managing onions, i2p's and whatever else
throughout the code and the private bitcoin p2p mesh.
Though I don't suspect it will conflict [1] with anyone's use of
OnionCat, GarliCat, or Phantom... it would just feel odd configuring
bitcoin to use Tor or I2P proxy ports (or Phantom native) when you
could conceivably just dump the IPv6 traffic to the OS stack for
handling once you have the *Cat shims and Phantom set up. They do
have a point about about ocat as a shim for their purposes. And
Phantom is a special case in that it's all native IPv6 interface,
no proxy or shim needed or provided.
I will quote an additional note from bitcoin-devel...
"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."
FYI. There have been a dozen or so onion:8333 nodes and maybe some
on I2P long before this work. But I think could only be used as
-connect or -addnode seeds with some extra host setup. Never tried
it since -proxy was sufficient. Seems this is a simpler and full
solution.
[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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-06-27 19:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-26 14:11 [Bitcoin-development] Tor hidden service support Pieter Wuille
2012-06-26 23:01 ` grarpamp
2012-06-27 0:14 ` Gregory Maxwell
[not found] ` <CAD2Ti29tMRCoW0rBSH738=0LpMfnGSJoSGYubV2-qQ9a6SC=zQ@mail.gmail.com>
[not found] ` <4FEAA936.10300@infosecurity.ch>
[not found] ` <CAD2Ti28hu6PccXpu4ObcbzWwFq+tchYaCoVY7S=9yakaB-nKjQ@mail.gmail.com>
2012-06-27 9:25 ` [Bitcoin-development] [tor-talk] " grarpamp
2012-06-27 8:47 ` [Bitcoin-development] " Andy Parkins
2012-06-27 19:51 grarpamp
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox