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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
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 1V49FX-0003e2-DN
for bitcoin-development@lists.sourceforge.net;
Tue, 30 Jul 2013 12:41:59 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.49 as permitted sender)
client-ip=209.85.219.49; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f49.google.com;
Received: from mail-oa0-f49.google.com ([209.85.219.49])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V49FW-0002c0-Jq
for bitcoin-development@lists.sourceforge.net;
Tue, 30 Jul 2013 12:41:59 +0000
Received: by mail-oa0-f49.google.com with SMTP id n16so4518033oag.36
for <bitcoin-development@lists.sourceforge.net>;
Tue, 30 Jul 2013 05:41:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.141.36 with SMTP id rl4mr22729929oeb.43.1375188113214;
Tue, 30 Jul 2013 05:41:53 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.23.36 with HTTP; Tue, 30 Jul 2013 05:41:53 -0700 (PDT)
In-Reply-To: <FB36762E8B574F7AAB7D25618841CF01@grabhive.com>
References: <FB36762E8B574F7AAB7D25618841CF01@grabhive.com>
Date: Tue, 30 Jul 2013 14:41:53 +0200
X-Google-Sender-Auth: t7boWA1vHUL6RDYUhwnZBS2VGRI
Message-ID: <CANEZrP3rqTW_DEZ75B9tg6kNPtfX4ENBJupaJD1axSLsxMdCwQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bazyli Zygan <b@grabhive.com>
Content-Type: multipart/alternative; boundary=047d7b339fbffcd24204e2b9ee9d
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: 1V49FW-0002c0-Jq
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Tor and Bitcoin
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: Tue, 30 Jul 2013 12:41:59 -0000
--047d7b339fbffcd24204e2b9ee9d
Content-Type: text/plain; charset=UTF-8
Various ideas are possible:
* Use the Tor SOCKS proxy in such a way that it creates a guaranteed
independent circuit to a different exit node each time you connect. This
gets you back to the slightly stronger clearnet heuristic of "if I saw a
bunch of peers announce my tx, then it's probably valid". I don't know if
this is possible.
* Have a set of hard-coded long term stable hidden peers, that are run by
known community members who are not going to collaborate to defraud people.
Of course if they're run by people who are well known that rather defeats
the point of them being hidden, but you benefit from the fact that the
.onion names double as authentication tokens.
* Talk the Tor protocol directly and have the app explicitly pick its own
diverse set of exit nodes, one per p2p connection. This is likely to be
complicated. Last time I looked Tor doesn't provide any kind of library or
API.
I agree that it's a kind of theoretical attack right now, but then again,
I'm not aware of any countries that block Bitcoin either. The thing with
Thailand seems like it might be the result of some confusion over who
exactly can make laws in that country. I'd be more concerned about
Argentina, but we're a long way from ISPs searching for people to arrest by
looking for port 8333.
Supporting SOCKS (really: blocking sockets) would be a good thing anyway.
Using blocking sockets also means we'd get SSL support, so if at some point
Bitcoin nodes start supporting SSL we'd be able to use it more easily.
--047d7b339fbffcd24204e2b9ee9d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Various ideas are possible:<div><br></div><div class=3D"gm=
ail_extra">* Use the Tor SOCKS proxy in such a way that it creates a guaran=
teed independent circuit to a different exit node each time you connect. Th=
is gets you back to the slightly stronger clearnet heuristic of "if I =
saw a bunch of peers announce my tx, then it's probably valid". I =
don't know if this is possible.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">* Have a se=
t of hard-coded long term stable hidden peers, that are run by known commun=
ity members who are not going to collaborate to defraud people. Of course i=
f they're run by people who are well known that rather defeats the poin=
t of them being hidden, but you benefit from the fact that the .onion names=
double as authentication tokens.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">* Talk the =
Tor protocol directly and have the app explicitly pick its own diverse set =
of exit nodes, one per p2p connection. This is likely to be complicated. La=
st time I looked Tor doesn't provide any kind of library or API.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I agree tha=
t it's a kind of theoretical attack right now, but then again, I'm =
not aware of any countries that block Bitcoin either. The thing with Thaila=
nd seems like it might be the result of some confusion over who exactly can=
make laws in that country. I'd be more concerned about Argentina, but =
we're a long way from ISPs searching for people to arrest by looking fo=
r port 8333.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Supporting =
SOCKS (really: blocking sockets) would be a good thing anyway. Using blocki=
ng sockets also means we'd get SSL support, so if at some point Bitcoin=
nodes start supporting SSL we'd be able to use it more easily.</div>
<div class=3D"gmail_extra"><br></div></div>
--047d7b339fbffcd24204e2b9ee9d--
|
