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
|
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 1WueLg-0003ue-JG
for bitcoin-development@lists.sourceforge.net;
Wed, 11 Jun 2014 08:57:36 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.179 as permitted sender)
client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f179.google.com;
Received: from mail-ob0-f179.google.com ([209.85.214.179])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WueLf-0007qf-Jk
for bitcoin-development@lists.sourceforge.net;
Wed, 11 Jun 2014 08:57:36 +0000
Received: by mail-ob0-f179.google.com with SMTP id uz6so4071479obc.10
for <bitcoin-development@lists.sourceforge.net>;
Wed, 11 Jun 2014 01:57:30 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.114.229 with SMTP id jj5mr16234474obb.53.1402477050135;
Wed, 11 Jun 2014 01:57:30 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.162 with HTTP; Wed, 11 Jun 2014 01:57:29 -0700 (PDT)
In-Reply-To: <20140610170846.GB21293@savin>
References: <CAJHLa0OJffXU_LkmVhCJ80mphc5zEPuDZzuSKvpLkrNUWU7Y1w@mail.gmail.com>
<CANEZrP33n+UBE+0Zb_mh=+qjJA+C+Nny9quC5B0HpuLC1XygMA@mail.gmail.com>
<20140610170846.GB21293@savin>
Date: Wed, 11 Jun 2014 10:57:29 +0200
X-Google-Sender-Auth: c7w7dimssHOXAYwRO6vs5k4D_Y0
Message-ID: <CANEZrP14gOCvWyDqJPEC=XRYMYKEXNi2AhN=FPw=jH+vR_vG-w@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c2f644610b5c04fb8ba2ed
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: 1WueLf-0007qf-Jk
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bloom bait
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: Wed, 11 Jun 2014 08:57:36 -0000
--001a11c2f644610b5c04fb8ba2ed
Content-Type: text/plain; charset=UTF-8
>
> Is this any different from my bloom filter IO attack code? Nope.
>
It's obviously different; a thin client trying to obtain more privacy is
not attempting to deny service to anyone. You can't simply state that a
feature which uses resources for a legitimate reason is a DoS attack,
that's a spurious definition that would reclassify innocuous things like
web browser prefetching as DoS attacks too.
With respect to the work you're proposing, trying to retroactively make
Bloom filtering an optional part of the protocol is just wasting people's
time at this point:
- There is no evidence there's an actual problem today.
- There is no evidence there will be a problem any time soon, given the
meagre levels of traffic growth we have.
- It involves a complicated rollout strategy that would create work for
many people.
- Gavin, Wladimir and myself have all concluded it's not worth the cost.
- The only justification you have provided is that two node
implementations hardly anyone uses can't be bothered to implement Bloom
filtering, but want to advertise support in their ver message anyway. They
can simply lower the number they advertise in their ver message.
That said, if you want to implement better support for archival nodes then
that'd be great. The way to do it would be either to implement block ranges
in the addr announcements as has been discussed many times before, or
perhaps introduce a new protocol optimised for serving the chain. Nodes
that are CPU limited won't want to take part in the rest of the P2P
protocol anyway, it's not just Bloom filtering that uses CPU time but also
block and tx relay.
But until you have done these things, please stop attempting to reclassify
any feature you can imagine a more efficient version of as an "attack".
It's just silly.
--001a11c2f644610b5c04fb8ba2ed
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:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
<div class=3D"">Is this any different from my bloom filter IO attack code? =
Nope.</div></blockquote><div><br></div><div>It's obviously different; a=
thin client trying to obtain more privacy is not attempting to deny servic=
e to anyone. You can't simply state that a feature which uses resources=
for a legitimate reason is a DoS attack, that's a spurious definition =
that would reclassify innocuous things like web browser prefetching as DoS =
attacks too.</div>
<div><br></div><div>With respect to the work you're proposing, trying t=
o retroactively make Bloom filtering an optional part of the protocol is ju=
st wasting people's time at this point:</div><div><ul><li>There is no e=
vidence there's an actual problem today.</li>
<li>There is no evidence there will be a problem any time soon, given the m=
eagre levels of traffic growth we have.</li><li>It involves a complicated r=
ollout strategy that would create work for many people.</li><li>Gavin, Wlad=
imir and myself have all concluded it's not worth the cost.</li>
<li>The only justification you have provided is that two node implementatio=
ns hardly anyone uses can't be bothered to implement Bloom filtering, b=
ut want to advertise support in their ver message anyway. They can simply l=
ower the number they advertise in their ver message.</li>
</ul><div><div>That said, if you want to implement better support for archi=
val nodes then that'd be great. The way to do it would be either to imp=
lement block ranges in the addr announcements as has been discussed many ti=
mes before, or perhaps introduce a new protocol optimised for serving the c=
hain. Nodes that are CPU limited won't want to take part in the rest of=
the P2P protocol anyway, it's not just Bloom filtering that uses CPU t=
ime but also block and tx relay.=C2=A0</div>
<div><br></div><div>But until you have done these things, please stop attem=
pting to reclassify any feature you can imagine a more efficient version of=
as an "attack". It's just silly.=C2=A0</div></div></div></di=
v>
</div></div>
--001a11c2f644610b5c04fb8ba2ed--
|
