1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <grarpamp@gmail.com>) id 1SjyGk-0006KX-AB
for bitcoin-development@lists.sourceforge.net;
Wed, 27 Jun 2012 19:51:18 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=grarpamp@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SjyGg-0002Ef-9f
for bitcoin-development@lists.sourceforge.net;
Wed, 27 Jun 2012 19:51:18 +0000
Received: by werg55 with SMTP id g55so1116441wer.34
for <bitcoin-development@lists.sourceforge.net>;
Wed, 27 Jun 2012 12:51:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.98.69 with SMTP id eg5mr7335155wib.3.1340826668093; Wed,
27 Jun 2012 12:51:08 -0700 (PDT)
Received: by 10.180.7.105 with HTTP; Wed, 27 Jun 2012 12:51:08 -0700 (PDT)
Date: Wed, 27 Jun 2012 15:51:08 -0400
Message-ID: <CAD2Ti28rUMwEOfHwkdoUOewHKr851BetC=o_=gcvEKrAZtysQQ@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.9 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(grarpamp[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.7 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SjyGg-0002Ef-9f
Subject: [Bitcoin-development] Tor hidden service support
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2012 19:51:18 -0000
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.
|
