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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bazyli@314t.com>) id 1V48cf-0006hc-Ub
for bitcoin-development@lists.sourceforge.net;
Tue, 30 Jul 2013 12:01:50 +0000
X-ACL-Warn:
Received: from mail-we0-f171.google.com ([74.125.82.171])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V48ce-0008RX-0O
for bitcoin-development@lists.sourceforge.net;
Tue, 30 Jul 2013 12:01:49 +0000
Received: by mail-we0-f171.google.com with SMTP id q55so5007987wes.16
for <bitcoin-development@lists.sourceforge.net>;
Tue, 30 Jul 2013 05:01:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=sender:date:from:to:message-id:subject:x-mailer:mime-version
:content-type:x-gm-message-state;
bh=H7I4SyEs6Wdowc1WAzHS5katzFSslx5bVi8KS65meHQ=;
b=F28OUjA7EJz2M55y5huPyikQi2N/wAx5XgyN/ODljDfQS5Jf1tLm22D9uHJy4DLnKz
QQFRCf/oxcdXvCfzXZoAJ1ql5rFOEqtksD0F2dvTDjCedeWdPcbElOUhXpEebnQjIsAT
jyVNqHWGOpVN0cYxi0MUHfRkzhR8wHbY/g2krY7dDd01Y1UccINa4Hqc3zSyJoY98lHW
SMBOk0Sv5uj0qPHu/WsMf2GyJqQJ6nBOIuBD6Q8MmmHLVPDTMR7+4C70k+acWz/Vkj+S
vP8NW+Li4YdxGAH7SyW6wx5SstzTKY6DJC/WWN8viBcKqo8/Li+VQp0dKYPovx4YIS4H
ONBw==
X-Received: by 10.194.110.39 with SMTP id hx7mr45741829wjb.4.1375185701649;
Tue, 30 Jul 2013 05:01:41 -0700 (PDT)
Received: from [10.0.1.6] (dynamic-78-8-156-39.ssp.dialog.net.pl.
[78.8.156.39]) by mx.google.com with ESMTPSA id
s19sm28027435wik.11.2013.07.30.05.01.40
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Tue, 30 Jul 2013 05:01:40 -0700 (PDT)
Sender: Bazyli Zygan <bazyli@314t.com>
Date: Tue, 30 Jul 2013 14:01:39 +0200
From: Bazyli Zygan <b@grabhive.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <FB36762E8B574F7AAB7D25618841CF01@grabhive.com>
X-Mailer: sparrow 1.6.4 (build 1178)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="51f7ab23_532c34a5_c6"
X-Gm-Message-State: ALoCoQkzSlUGk9Wr3fNCmUlHGHo5WtFs5Qd5dVyKctEzSumARmPwpfXI5OAqjG5ssCkgrQcWeT8F
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1V48ce-0008RX-0O
Subject: [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:01:50 -0000
--51f7ab23_532c34a5_c6
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi everyone,
We at Hive had plans to make our wallet proxy through Tor by default. When it became apparent that this was not presently possible because bitcoinj lacks SOCKS support, it opened a minor discussion suggesting that this is perhaps not advisable practice for SPV wallets in the first place. To quote Mike Hearn:
> I think you have to be careful with Tor and Bitcoin. It isn't a no-brainer move. Virtually all people today don't have hacked internet connections. However when you connect outbound from Tor you have to pretty much assume your traffic is being packet logged and sometimes automatically MITMd by exit nodes, which in turn means you can be transparently connected to a sybil network. If you connect to a hidden service the issue is less problematic because you're authenticating the connection and can pick peers you have reason to believe are independent.
>
> Whilst it's unlikely an attacker would actually try to auto-sybil SPV connections made out of a Tor exit node, if they did, they could make the person connecting out believe in fake pending/unconfirmed transactions. For instance if you're meeting with someone to do a currency trade and you happen to run an exit node that has a lot of bandwidth and an exit policy that allows only Bitcoin, there's a chance the other persons Tor client will pick your exit. You can then swap the cash, give them a fake transaction and when it doesn't confirm, apologise and say you can't wait and have to go. Walk out with the cash and it'll take a while for the victim to realize that the transaction never did actually get broadcast at all, it was just an illusion.
>
> (this scenario worries me for mobile clients but instead of tor, the issue is an attacker controlled open wifi hotspot).
>
> I think to support Tor really well [in bitcoinj], we'd need not only to make SOCKS work, but also add a way to use hidden peers and then try and come up with an anti-sybil heuristic. Unfortunately it's unclear what such a heuristic would look like. Bitcoin-Qt uses different /16s as a rule of thumb when on the clearnet, but no such technique is usable on Tor because by definition you aren't supposed to know anything about the hidden peers.
While the scenario outlined seems unlikely, it's best to be prepared... What do you all think? How can this be done properly?
As we said to Mike, if Thailand has actually made Bitcoin illegal, then packet filtering may not be far off for certain regions, and it would nice to be proactive and prepared. At the moment, Thailand already has cruder, URL-based filtering... But vendors like Cisco are no doubt constantly selling them on the virtues of more advanced censorship technologies.
Gregory Maxwell is the person who wrote the hidden service support for bitcoind, right? It might be interesting to get his comments here.
/b
grabhive.com (http://grabhive.com) | twitter.com/grabhive (http://twitter.com/grabhive) | gpg: A1D5047E
--51f7ab23_532c34a5_c6
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
<div>
<span style=3D=22font-size: 13px; =22>Hi everyone,</s=
pan><br style=3D=22font-size: 13px; =22><br style=3D=22font-size: 13px; =22=
><span style=3D=22font-size: 13px; =22>We at Hive had plans to make our w=
allet proxy through Tor by default. When it became apparent that this was=
not presently possible because bitcoinj lacks SOCKS support, it opened a=
minor discussion suggesting that this is perhaps not advisable practice =
for SPV wallets in the first place. To quote Mike Hearn:</span><br style=3D=
=22font-size: 13px; =22><br style=3D=22font-size: 13px; =22><blockquote t=
ype=3D=22cite=22 style=3D=22font-size: 13px; =22>I think you have to be c=
areful with Tor and Bitcoin. It isn't a no-brainer move. Virtually all pe=
ople today don't have hacked internet connections. However when you conne=
ct outbound from Tor you have to pretty much assume your traffic is being=
packet logged and sometimes automatically MITMd by exit nodes, which in =
turn means you can be transparently connected to a sybil network. If you =
connect to a hidden service the issue is less problematic because you're =
authenticating the connection and can pick peers you have reason to belie=
ve are independent.<br><br>Whilst it's unlikely an attacker would actuall=
y try to auto-sybil SPV connections made out of a Tor exit node, if they =
did, they could make the person connecting out believe in fake pending/un=
confirmed transactions. =46or instance if you're meeting with someone to =
do a currency trade and you happen to run an exit node that has a lot of =
bandwidth and an exit policy that allows only Bitcoin, there's a chance t=
he other persons Tor client will pick your exit. You can then swap the ca=
sh, give them a fake transaction and when it doesn't confirm, apologise a=
nd say you can't wait and have to go. Walk out with the cash and it'll ta=
ke a while for the victim to realize that the transaction never did actua=
lly get broadcast at all, it was just an illusion.<br><br>(this scenario =
worries me for mobile clients but instead of tor, the issue is an attacke=
r controlled open wifi hotspot).<br><br>I think to support Tor really wel=
l =5Bin bitcoinj=5D, we'd need not only to make SOCKS work, but also add =
a way to use hidden peers and then try and come up with an anti-sybil heu=
ristic. Unfortunately it's unclear what such a heuristic would look like.=
Bitcoin-Qt uses different /16s as a rule of thumb when on the clearnet, =
but no such technique is usable on Tor because by definition you aren't s=
upposed to know anything about the hidden peers.<br></blockquote><br styl=
e=3D=22font-size: 13px; =22><span style=3D=22font-size: 13px; =22>While t=
he scenario outlined seems unlikely, it's best to be prepared... What do =
you all think=3F How can this be done properly=3F</span><br style=3D=22fo=
nt-size: 13px; =22><br style=3D=22font-size: 13px; =22><span style=3D=22f=
ont-size: 13px; =22>As we said to Mike, if Thailand has actually made Bit=
coin illegal, then packet filtering may not be far off for certain region=
s, and it would nice to be proactive and prepared. At the moment, Thailan=
d already has cruder, URL-based filtering... But vendors like Cisco are n=
o doubt constantly selling them on the virtues of more advanced censorshi=
p technologies.</span><br style=3D=22font-size: 13px; =22><br style=3D=22=
font-size: 13px; =22><span style=3D=22font-size: 13px; =22>Gregory Maxwel=
l is the person who wrote the hidden service support for bitcoind, right=3F=
It might be interesting to get his comments here.</span>
</div>
<div><div><br></div><div>/b</div><div><br></div><div><a h=
ref=3D=22http://grabhive.com=22 style=3D=22color: rgb(0, 106, 227); backg=
round-color: rgb(255, 255, 255); =22>grabhive.com</a><span style=3D=22bac=
kground-color: rgb(255, 255, 255); =22> =7C </span><a href=3D=22=
http://twitter.com/grabhive=22 style=3D=22color: rgb(0, 106, 227); backgr=
ound-color: rgb(255, 255, 255); =22>twitter.com/grabhive</a><span style=3D=
=22background-color: rgb(255, 255, 255); font-size: 10pt; =22> =7C&n=
bsp;</span><span style=3D=22font-size: 13px; =22>gpg: A1D5047E</span></di=
v><div><br></div></div>
--51f7ab23_532c34a5_c6--
|
