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
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1W3Zwz-0003o4-FO
for bitcoin-development@lists.sourceforge.net;
Wed, 15 Jan 2014 23:32:45 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.42 as permitted sender)
client-ip=209.85.219.42; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f42.google.com;
Received: from mail-oa0-f42.google.com ([209.85.219.42])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W3Zwy-0006tT-Aw
for bitcoin-development@lists.sourceforge.net;
Wed, 15 Jan 2014 23:32:45 +0000
Received: by mail-oa0-f42.google.com with SMTP id n16so2091617oag.1
for <bitcoin-development@lists.sourceforge.net>;
Wed, 15 Jan 2014 15:32:38 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.56.201 with SMTP id c9mr161283oeq.75.1389828758770; Wed,
15 Jan 2014 15:32:38 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.99.112 with HTTP; Wed, 15 Jan 2014 15:32:38 -0800 (PST)
In-Reply-To: <CANg-TZBCSvVeDTNKQSPV-Fw+uZ8np04WoE=o0J+8wULBHrsgKQ@mail.gmail.com>
References: <5747D5DF-879B-4A60-8BD6-18251E7D5F47@plan99.net>
<CANg-TZBCSvVeDTNKQSPV-Fw+uZ8np04WoE=o0J+8wULBHrsgKQ@mail.gmail.com>
Date: Thu, 16 Jan 2014 00:32:38 +0100
X-Google-Sender-Auth: ekAbehmi2UwWvzN9WeIIwDn0RZc
Message-ID: <CANEZrP1iP6J5gczrQ-+Lzq4uohys7Rrfa0c5F0r-cqx3OJMDGg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Brooks Boyd <boydb@midnightdesign.ws>
Content-Type: multipart/alternative; boundary=089e013a0ecc771da104f00ab934
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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
X-Headers-End: 1W3Zwy-0006tT-Aw
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Tor / SPV
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, 15 Jan 2014 23:32:45 -0000
--089e013a0ecc771da104f00ab934
Content-Type: text/plain; charset=UTF-8
>
> May need to modify the network address format to include the ability to
> differentiate IPv6 clearnet vs. Tor addresses
>
sipa already implemented some clever hack where the 80-bit Tor keys are
mapped to a subregion of reserved IPv6 space, giving magical IPv6 hidden
service addresses. So addr packets can and do already contain onion
addresses.
> but then you remove the implication that a node has to give both public
> and private IPs to a peer. If it's part of a batch of "addr"s, it could be
> my own hidden service ID, but it could also be one that I learned from
> someone else and is now propagating, for anyone to bootstrap with Tor
> hidden service peers if they'd like.
>
Hmm. So you mean that we pick a set of peers we believe to not be sybils of
each other, but they might give us hidden services run by other people? I
need to think about that. If they're getting the hidden services just from
addr announcements themselves, then you just punt the issue up a layer -
what stops me generating 10000 hidden service keys that all map to my same
malicious node, announcing them, and then waiting for the traffic to
arrive? If clearnet nodes inform of their own hidden service IDs, that
issue is avoided.
My goal here is not necessarily to hide P2P nodes - we still need lots of
clearnet P2P nodes for the forseeable future no matter what. Rather we're
just using hidden services as a way to get authentication and encryption.
Actually the 6-hop hidden service circuits are overkill for this
application, a 3-hop circuit would work just as well for most nodes that
aren't Tor-exclusive.
--089e013a0ecc771da104f00ab934
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">May =
need to modify the network address format to include the ability to differe=
ntiate IPv6 clearnet vs. Tor addresses</div>
</div></blockquote><div><br></div><div>sipa already implemented some clever=
hack where the 80-bit Tor keys are mapped to a subregion of reserved IPv6 =
space, giving magical IPv6 hidden service addresses. So addr packets can an=
d do already contain onion addresses.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra">but then you remove the implication that a node has to giv=
e both public and private IPs to a peer. If it's part of a batch of &qu=
ot;addr"s, it could be my own hidden service ID, but it could also be =
one that I learned from someone else and is now propagating, for anyone to =
bootstrap with Tor hidden service peers if they'd like.</div>
</div></blockquote><div><br></div><div>Hmm. So you mean that we pick a set =
of peers we believe to not be sybils of each other, but they might give us =
hidden services run by other people? I need to think about that. If they=
9;re getting the hidden services just from addr announcements themselves, t=
hen you just punt the issue up a layer - what stops me generating 10000 hid=
den service keys that all map to my same malicious node, announcing them, a=
nd then waiting for the traffic to arrive? If clearnet nodes inform of thei=
r own hidden service IDs, that issue is avoided.</div>
<div><br></div><div>My goal here is not necessarily to hide P2P nodes - we =
still need lots of clearnet P2P nodes for the forseeable future no matter w=
hat. Rather we're just using hidden services as a way to get authentica=
tion and encryption. Actually the 6-hop hidden service circuits are overkil=
l for this application, a 3-hop circuit would work just as well for most no=
des that aren't Tor-exclusive.=C2=A0</div>
</div></div></div>
--089e013a0ecc771da104f00ab934--
|
