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
|
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 <mh.in.england@gmail.com>) id 1Xy1eU-0007CK-5o
for bitcoin-development@lists.sourceforge.net;
Mon, 08 Dec 2014 16:59:14 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.179 as permitted sender)
client-ip=209.85.212.179; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f179.google.com;
Received: from mail-wi0-f179.google.com ([209.85.212.179])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Xy1eS-00053N-PW
for bitcoin-development@lists.sourceforge.net;
Mon, 08 Dec 2014 16:59:14 +0000
Received: by mail-wi0-f179.google.com with SMTP id ex7so5419134wid.6
for <bitcoin-development@lists.sourceforge.net>;
Mon, 08 Dec 2014 08:59:06 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.76.239 with SMTP id n15mr18338522wiw.66.1418057946735;
Mon, 08 Dec 2014 08:59:06 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.9 with HTTP; Mon, 8 Dec 2014 08:59:06 -0800 (PST)
In-Reply-To: <20141208161514.6C492E1B59B@quidecco.de>
References: <CAJHLa0N6+hpwNECpHUSiKuj4-BYohh=Wr1DP=67Ff8xVBsi8-Q@mail.gmail.com>
<54760A50.201@riseup.net> <20141127020947.A13D2E19A09@quidecco.de>
<CAAS2fgRSxBmyDg5R7WgisB-XmhrpGVKHXQpchtL-Ow0xDQAziA@mail.gmail.com>
<CANEZrP2JLUu9V4HGSLWr1Mg37qmTFVuihTQhJeJ4iyQPxrqsMQ@mail.gmail.com>
<20141208161514.6C492E1B59B@quidecco.de>
Date: Mon, 8 Dec 2014 17:59:06 +0100
X-Google-Sender-Auth: bMlElvLdJH88xR6T6o4gpx2uc08
Message-ID: <CANEZrP1Wh_98+47PmmHwSTDoSASw96R+Xnh5qWzROdmxPwO0Gw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Isidor Zeuner <cryptocurrencies@quidecco.de>
Content-Type: multipart/alternative; boundary=f46d043749b32faa800509b7586e
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: 1Xy1eS-00053N-PW
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P
network paper
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: Mon, 08 Dec 2014 16:59:14 -0000
--f46d043749b32faa800509b7586e
Content-Type: text/plain; charset=UTF-8
>
> Finally, distributors of consumer wallets can use this research in
> order to distribute their wallet with policies which may be less prone
> to Tor-specific attacks. Or leave this out altogether if their
> audience has different expectations for connecting to Bitcoin.
>
Sure. I guess there will be wallets for all kinds of people in future,
sharing a common core that they can customise (this is certainly the vision
and general direction for bitcoinj, and it's working out OK).
To clarify, my comments above were for mainstream granny-focused wallets.
Wallets designed for crypto geeks can and should expose all the knobs to
let people run wild.
One possible direction to go is to use Tor for writing to the network and
use general link encryption and better Bloom filtering for reading it. Thus
new transactions would pop out of Tor exits, but there isn't much they can
do that's malicious there except mutate them or block them entirely. If you
insert the same transaction into the P2P network via say 10 randomly chosen
exits, the worst a malicious mutator can do is race the real transaction
and that's no different to a malicious P2P node. Even in a world where an
attacker has DoS-banned a lot of nodes and now controls your TX submission
path entirely, it's hard to see how it helps them.
The nice thing about the above approach is that it solves the latency
problems. Startup speed is really an issue for reading from the network:
just syncing the block chain is already enough of a speed hit without
adding consensus sync as well. But if you're syncing the block chain via
the clearnet you can connect to Tor in parallel so that by the time the
user has scanned a QR code, verified the details on the screen and then
pressed the Pay button, you have a warm connection and can upload the TX
through that. It reduces the level of startup time optimisation needed,
although Tor consensus download is still too slow even to race a QR code
scan at the moment. I think tuning the consensus caching process and
switching to a fresh one on the fly might be the way to go.
When BIP70 is in use, you wouldn't write the tx to the network yourself but
you could download the PaymentRequest and upload the Payment message via an
SSLd Tor connection to the merchant. Then malicious exits can only DoS you
but not do anything else so there's no need for multiple exit paths
simultaneously.
--f46d043749b32faa800509b7586e
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">Finally, distributors of consumer wallets can us=
e this research in<br>
order to distribute their wallet with policies which may be less prone<br>
to Tor-specific attacks. Or leave this out altogether if their<br>
audience has different expectations for connecting to Bitcoin.<br></blockqu=
ote><div><br></div><div>Sure. I guess there will be wallets for all kinds o=
f people in future, sharing a common core that they can customise (this is =
certainly the vision and general direction for bitcoinj, and it's worki=
ng out OK).</div><div><br></div><div>To clarify, my comments above were for=
mainstream granny-focused wallets. Wallets designed for crypto geeks can a=
nd should expose all the knobs to let people run wild.</div><div>=C2=A0</di=
v><div>One possible direction to go is to use Tor for writing to the networ=
k and use general link encryption and better Bloom filtering for reading it=
. Thus new transactions would pop out of Tor exits, but there isn't muc=
h they can do that's malicious there except mutate them or block them e=
ntirely. If you insert the same transaction into the P2P network via say 10=
randomly chosen exits, the worst a malicious mutator can do is race the re=
al transaction and that's no different to a malicious P2P node. Even in=
a world where an attacker has DoS-banned a lot of nodes and now controls y=
our TX submission path entirely, it's hard to see how it helps them.</d=
iv><div><br></div><div>The nice thing about the above approach is that it s=
olves the latency problems. Startup speed is really an issue for reading fr=
om the network: just syncing the block chain is already enough of a speed h=
it without adding consensus sync as well. But if you're syncing the blo=
ck chain via the clearnet you can connect to Tor in parallel so that by the=
time the user has scanned a QR code, verified the details on the screen an=
d then pressed the Pay button, you have a warm connection and can upload th=
e TX through that. It reduces the level of startup time optimisation needed=
, although Tor consensus download is still too slow even to race a QR code =
scan at the moment. I think tuning the consensus caching process and switch=
ing to a fresh one on the fly might be the way to go.</div><div><br></div><=
div>When BIP70 is in use, you wouldn't write the tx to the network your=
self but you could download the PaymentRequest and upload the Payment messa=
ge via an SSLd Tor connection to the merchant. Then malicious exits can onl=
y DoS you but not do anything else so there's no need for multiple exit=
paths simultaneously.</div></div><br></div><div class=3D"gmail_extra"><br>=
</div></div>
--f46d043749b32faa800509b7586e--
|
