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
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1W3k8b-00084x-GW
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Jan 2014 10:25:25 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.174 as permitted sender)
client-ip=209.85.214.174; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f174.google.com;
Received: from mail-ob0-f174.google.com ([209.85.214.174])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W3k8Z-0001QW-Ka
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Jan 2014 10:25:25 +0000
Received: by mail-ob0-f174.google.com with SMTP id wo20so2501781obc.5
for <bitcoin-development@lists.sourceforge.net>;
Thu, 16 Jan 2014 02:25:18 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.65.5 with SMTP id t5mr6341553oes.19.1389867918257; Thu,
16 Jan 2014 02:25:18 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.99.112 with HTTP; Thu, 16 Jan 2014 02:25:18 -0800 (PST)
In-Reply-To: <CANg-TZAyr8LyRQ5e4DpQA8fXEbGq6kxv=peB9oYB+bU_xA98ww@mail.gmail.com>
References: <5747D5DF-879B-4A60-8BD6-18251E7D5F47@plan99.net>
<CANg-TZBCSvVeDTNKQSPV-Fw+uZ8np04WoE=o0J+8wULBHrsgKQ@mail.gmail.com>
<CANEZrP1iP6J5gczrQ-+Lzq4uohys7Rrfa0c5F0r-cqx3OJMDGg@mail.gmail.com>
<CANg-TZAyr8LyRQ5e4DpQA8fXEbGq6kxv=peB9oYB+bU_xA98ww@mail.gmail.com>
Date: Thu, 16 Jan 2014 11:25:18 +0100
X-Google-Sender-Auth: VdZzdqEFSuw9Dx6HSxwTjqpCKXw
Message-ID: <CANEZrP3ZmahH8tY4zyLK5wCUVsj2e+w8wfCHz5Z4_w5GXTiqPA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Brooks Boyd <boydb@midnightdesign.ws>
Content-Type: multipart/alternative; boundary=001a11c1d6a88d772f04f013d747
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: 1W3k8Z-0001QW-Ka
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: Thu, 16 Jan 2014 10:25:25 -0000
--001a11c1d6a88d772f04f013d747
Content-Type: text/plain; charset=UTF-8
Yes correct, using hidden services just as a kind of more complicated, out
of process/sandboxable SSL.
> would the overall transactions/second the Bitcoin network could handle go
> down?
>
If all nodes talked to each other all the time over Tor, probably yes
because Bitcoin is quite sensitive to latency. But what I'm proposing here
is less ambitious. It's just about protecting (parts of)
end-user-to-network communication, which is a much less risky sort of
change. P2P nodes would still talk to each other in the clear.
SSL for everything is still an idea I like, but it's true that increasing
bitcoind attack surface area is not something to take lightly.
Considering that the clearnet sybil protection also relies on scaling
> up the resource requirements for an attacker, why not require hidden
> service addresses following a certain pattern, like a fixed prefix?
I'm sure we can come up with all kinds of neat anti-sybil techniques, but
IMHO they are separate projects. I'm trying to find an upgrade that's small
enough to be easily switched on by default for lots of users, today, that
is low risk for the network overall. Later on we can add elaborations.
The SPV node could connect to the IP using Tor. It would preserve the
> privacy of the SPV node - hard to see it's running Bitcoin. It also
> reduces the ability of an attacker to MITM because the routing varies
> with each exit node.
Right so the key question is, to what extent does Tor open you up to MITM
attacks? I don't have a good feel for this. I read about exit nodes
routinely doing very naughty things, but I don't know how widespread that
is. Probably you're right that with random selection of exits you're not
excessively likely to get MITMd.
How does Tor itself manage anti-sybil? I know they have the directory
consensus and they measure nodes to ensure they're delivering the resources
they claim to have. Punting anti-sybil up to the Tor people and letting
them worry about it is quite an attractive idea.
--001a11c1d6a88d772f04f013d747
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"><div=
>Yes correct, using hidden services just as a kind of more complicated, out=
of process/sandboxable SSL.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra">would the overall transactions/=
second the Bitcoin network could handle go down?</div></div></blockquote><d=
iv><br></div><div>If all nodes talked to each other all the time over Tor, =
probably yes because Bitcoin is quite sensitive to latency. But what I'=
m proposing here is less ambitious. It's just about protecting (parts o=
f) end-user-to-network communication, which is a much less risky sort of ch=
ange. P2P nodes would still talk to each other in the clear.</div>
<div><br></div><div>SSL for everything is still an idea I like, but it'=
s true that increasing bitcoind attack surface area is not something to tak=
e lightly.</div><div><br></div><div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">
Considering that the clearnet sybil protection also relies on scaling<br>up=
the resource requirements for an attacker, why not require hidden<br>servi=
ce addresses following a certain pattern, like a fixed prefix?</blockquote>
</div><div><br></div><div>I'm sure we can come up with all kinds of nea=
t anti-sybil techniques, but IMHO they are separate projects. I'm tryin=
g to find an upgrade that's small enough to be easily switched on by de=
fault for lots of users, today, that is low risk for the network overall. L=
ater on we can add elaborations.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><span style=3D"color:rgb(80,0,80);font-fami=
ly:arial,sans-serif;font-size:13px">The SPV node could connect to the IP us=
ing Tor. =C2=A0It would preserve the<br>
</span><span style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;font-=
size:13px">privacy of the SPV node - hard to see it's running Bitcoin. =
=C2=A0It also<br></span><span style=3D"color:rgb(80,0,80);font-family:arial=
,sans-serif;font-size:13px">reduces the ability of an attacker to MITM beca=
use the routing varies<br>
</span><span style=3D"color:rgb(80,0,80);font-family:arial,sans-serif;font-=
size:13px">with each exit node.</span></blockquote><div><br></div><div>Righ=
t so the key question is, to what extent does Tor open you up to MITM attac=
ks? =C2=A0I don't have a good feel for this. I read about exit nodes ro=
utinely doing very naughty things, but I don't know how widespread that=
is. Probably you're right that with random selection of exits you'=
re not excessively likely to get MITMd.</div>
<div><br></div><div>How does Tor itself manage anti-sybil? I know they have=
the directory consensus and they measure nodes to ensure they're deliv=
ering the resources they claim to have. Punting anti-sybil up to the Tor pe=
ople and letting them worry about it is quite an attractive idea.</div>
<div><br></div></div></div></div>
--001a11c1d6a88d772f04f013d747--
|
