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
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
|
Return-Path: <hearn@vinumeris.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E4E93A3F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2015 15:21:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com
[209.85.213.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C889F178
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2015 15:21:47 +0000 (UTC)
Received: by igbjg10 with SMTP id jg10so63812917igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Aug 2015 08:21:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=vinumeris.com; s=google;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=Es3/gxxB0yczcM4q86DwMfppf78OZ9QZL2VP6psxUzs=;
b=PLImgnUaDuEcoiGwqoXmW15zsVdG/0cwoVyn1gezm/xuTO8V90ObGZ25gmDh32P2eN
eM28mV72xYpoqXy43Liwj5cuKbUdttYs6qIDjFemuOVNDy6c5DeP/HY546kUNWQX5S9b
lideDWsgvLw8o1MLmM1hJicB0vU0zCQMKAohQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=Es3/gxxB0yczcM4q86DwMfppf78OZ9QZL2VP6psxUzs=;
b=Londfic//3Cxm6ubnyWAZ36X0Q2U72i0Ymjt8nXZWyRiAbq08TNskwWDW4fWgRgEBs
YRITWgWcl71D5YEdPIPHVBEdTYTIFfl5zauOl8nFNU1ZCPy1W4dpQnHtJLNGi5I3eLRZ
gsCO3Pfc3vomweDJQ24j1DHo3o1zbKltRXgvBVz1vMkX6HczQMjyA7IvppfIv3ebzedI
HhLCuApAcIF/mln16N1Ldzy1OB/r4WZqN6BUu0/DO8Js9fAu+G/S4GUZp3kn0zPCGwoo
rgAaXl9lLTJTcfvrXdF2loI/fpAqSVZ7ledlDCjgj9opHlQ77bEUzR2oP4oW+WTfvQx1
mbtA==
X-Gm-Message-State: ALoCoQkWaVN8CDm797JAL2+7l2CnPsJr6HQMxZxw/phOQVSHP7E3ELVAutCGQqe4hrzbsVahN9Xo
MIME-Version: 1.0
X-Received: by 10.50.12.34 with SMTP id v2mr9181937igb.69.1440429707152; Mon,
24 Aug 2015 08:21:47 -0700 (PDT)
Received: by 10.50.208.7 with HTTP; Mon, 24 Aug 2015 08:21:47 -0700 (PDT)
In-Reply-To: <55D7AF85.2020707@thinlink.com>
References: <55D6AD19.10305@mattcorallo.com>
<CADm_WcZJEe4fz4dLYKeOzC0CWbM=-o92BvEF0qiGvNwyMjrEiA@mail.gmail.com>
<20150821055534.GA27259@muck>
<CADm_WcanqF7oHn7huKuYP8iFWmY4XE58tG01M_Nqg9qx6YFu9A@mail.gmail.com>
<20150821060716.GA31674@muck> <55D7AF85.2020707@thinlink.com>
Date: Mon, 24 Aug 2015 17:21:47 +0200
Message-ID: <CA+w+GKSy5oEy-pS_JsoaGBEp3Fn=x5HZSiFAEVnmkQi5=qhP5Q@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Tom Harding <tomh@thinlink.com>
Content-Type: multipart/alternative; boundary=089e0122efea04f6b0051e102d2a
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Revisiting NODE_BLOOM: Proposed BIP
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Aug 2015 15:21:49 -0000
--089e0122efea04f6b0051e102d2a
Content-Type: text/plain; charset=UTF-8
NACK: stated rationales are invalid: both privacy and DoS (see below for
experimental data).
1 - Bloom filtering doesn't add privacy for node operators, it adds privacy
for lightweight wallets. And in fact, with a high FP rate it does do that.
Most users want both low bandwidth usage *and* query scrambling, which is
harder to do but not impossible. There is a clear roadmap for how to
implement that with smarter clients: no protocol changes are needed.
So the first stated rationale is spurious: disabling Bloom filtering
doesn't improve privacy for anyone. It can only hurt.
2 - SPV usage is rising, not falling.
Peter's data is flawed because he ignored the fact that SPV clients tend to
connect, sync, then disconnect. They don't remain connected all the time.
So merely examining a random snapshot of what's connected at a single point
in time will give wildly varying and almost random results.
A more scientifically valid approach is to check the number of actual
connections over a long span of time. Here's the data from my node:
mike@plan99:~/.bitcoin$ grep -Po 'receive version message: ([^:]*):'
debug.log |sort |uniq -c|sort -n|tac|head -n 10
11027 receive version message: /getaddr.bitnodes.io:
6264 receive version message: /bitcoinseeder:
4944 receive version message: /bitcoinj:
2531 receive version message: /Snoopy:
2362 receive version message: /breadwallet:
1127 receive version message: /Satoshi:
204 receive version message: /Bitcoin XT:
128 receive version message: /BitCoinJ:
97 receive version message: /Bither1.3.8/:
82 receive version message: /Bitaps:
Once crawlers are removed, SPV wallets (bitcoinj, breadwallet) make up the
bulk of all P2P clients. This is very far from 1% and falling, as Todd
wrongly suggests.
3 - It is said that there is a DoS attack possible. This claim does not
seem to have been researched.
I decided to test it out for real, so I implemented a DoS attack similar to
the one we've seen against XT nodes: it sends getdata for large (1mb)
filtered blocks over and over again as fast as possible.
As was reported and makes sense, CPU usage goes to 100%. However I couldn't
see any other effects. RPCs still react immediately, the Qt GUI is fully
responsive, I was even able to sync another SPV client to that node and it
proceeded at full speed. It's actually pretty nice to see how well it held
up.
Most importantly transactions and blocks continued to be relayed without
delay. I saw my VPS node receive a block only eight seconds after my local
node, which is well within normal propagation delays.
There's another very important point here: I profiled my local node whilst
it was under this attack. It turns out that Bloom filtering is extremely
fast. 90% of the CPU time is spent on loading and deserializing the data
from disk. Only 10% of the CPU time was spent actually filtering.
Thus you can easily trigger exactly the same DoS attack by just using
regular getdata requests on large blocks over and over. You don't need
Bloom filtering. If you don't want to actually download the blocks just
don't TCP ACK the packets and then FIN after a few seconds .... the data
will all have been loaded and be sitting in the send buffers.
So even if I refine the attack and find a way to actually deny service to
someone, the fix would have to apply to regular non-filtered block fetches
too, which cannot be disabled.
In summary: this BIP doesn't solve anything, but does create a big upgrade
headache.
--089e0122efea04f6b0051e102d2a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">NACK: stated rationales are inv=
alid: both privacy and DoS (see below for experimental data).</div><div cla=
ss=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">1 - Bloom filtering doesn't add privacy for node oper=
ators, it adds privacy for lightweight wallets. And in fact, with a high FP=
rate it does do that. Most users want both low bandwidth usage <i><b>and</=
b></i>=C2=A0query scrambling, which is harder to do but not impossible. The=
re is a clear roadmap for how to implement that with smarter clients: no pr=
otocol changes are needed.=C2=A0</div><div class=3D"gmail_extra"><br></div>=
<div class=3D"gmail_extra">So the first stated rationale is spurious: disab=
ling Bloom filtering doesn't improve privacy for anyone. It can only hu=
rt.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><b=
r></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">2 -=
SPV usage is rising, not falling.</div><div class=3D"gmail_extra"><br></di=
v><div class=3D"gmail_extra">Peter's data is flawed because he ignored =
the fact that SPV clients tend to connect, sync, then disconnect. They don&=
#39;t remain connected all the time. So merely examining a random snapshot =
of what's connected at a single point in time will give wildly varying =
and almost random results.</div><div class=3D"gmail_extra"><br></div><div c=
lass=3D"gmail_extra">A more scientifically valid approach is to check the n=
umber of actual connections over a long span of time. Here's the data f=
rom my node:</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_=
extra"><div class=3D"gmail_extra">mike@plan99:~/.bitcoin$ grep -Po 'rec=
eive version message: ([^:]*):' debug.log |sort |uniq -c|sort -n|tac|he=
ad -n 10</div><div class=3D"gmail_extra">=C2=A0 11027 receive version messa=
ge: /<a href=3D"http://getaddr.bitnodes.io" target=3D"_blank">getaddr.bitno=
des.io</a>:</div><div class=3D"gmail_extra">=C2=A0 =C2=A06264 receive versi=
on message: /bitcoinseeder:</div><div class=3D"gmail_extra">=C2=A0 =C2=A049=
44 receive version message: /bitcoinj:</div><div class=3D"gmail_extra">=C2=
=A0 =C2=A02531 receive version message: /Snoopy:</div><div class=3D"gmail_e=
xtra">=C2=A0 =C2=A02362 receive version message: /breadwallet:</div><div cl=
ass=3D"gmail_extra">=C2=A0 =C2=A01127 receive version message: /Satoshi:</d=
iv><div class=3D"gmail_extra">=C2=A0 =C2=A0 204 receive version message: /B=
itcoin XT:</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 128 receive versio=
n message: /BitCoinJ:</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A09=
7 receive version message: /Bither1.3.8/:</div><div class=3D"gmail_extra">=
=C2=A0 =C2=A0 =C2=A082 receive version message: /Bitaps:</div><div><br></di=
v><div>Once crawlers are removed, SPV wallets (bitcoinj, breadwallet) make =
up the bulk of all P2P clients. This is very far from 1% and falling, as To=
dd wrongly suggests.</div><div><br></div><div><br></div><div><br></div><div=
>3 - It is said that there is a DoS attack possible. This claim does not se=
em to have been researched.</div><div><br></div><div>I decided to test it o=
ut for real, so I implemented a DoS attack similar to the one we've see=
n against XT nodes: it sends getdata for large (1mb) filtered blocks over a=
nd over again as fast as possible.</div><div><br></div><div>As was reported=
and makes sense, CPU usage goes to 100%. However I couldn't see any ot=
her effects. RPCs still react immediately, the Qt GUI is fully responsive, =
I was even able to sync another SPV client to that node and it proceeded at=
full speed. It's actually pretty nice to see how well it held up.</div=
><div><br></div><div>Most importantly transactions and blocks continued to =
be relayed without delay. I saw my VPS node receive a block only eight seco=
nds after my local node, which is well within normal propagation delays.</d=
iv><div><br></div><div>There's another very important point here: I pro=
filed my local node whilst it was under this attack. It turns out that Bloo=
m filtering is extremely fast. 90% of the CPU time is spent on loading and =
deserializing the data from disk. Only 10% of the CPU time was spent actual=
ly filtering.</div><div><br></div><div>Thus you can easily trigger exactly =
the same DoS attack by just using regular getdata requests on large blocks =
over and over. You don't need Bloom filtering. If you don't want to=
actually download the blocks just don't TCP ACK the packets and then F=
IN after a few seconds .... the data will all have been loaded and be sitti=
ng in the send buffers.</div><div><br></div><div>So even if I refine the at=
tack and find a way to actually deny service to someone, the fix would have=
to apply to regular non-filtered block fetches too, which cannot be disabl=
ed.</div><div><br></div><div><br></div><div>In summary: this BIP doesn'=
t solve anything, but does create a big upgrade headache.</div></div></div>
--089e0122efea04f6b0051e102d2a--
|
