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
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
|
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 <kgreenek@gmail.com>) id 1YTLL0-00011Y-QO
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Mar 2015 02:16:34 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.177 as permitted sender)
client-ip=209.85.160.177; envelope-from=kgreenek@gmail.com;
helo=mail-yk0-f177.google.com;
Received: from mail-yk0-f177.google.com ([209.85.160.177])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YTLKz-0000WY-Gp
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Mar 2015 02:16:34 +0000
Received: by yks20 with SMTP id 20so5055051yks.3
for <bitcoin-development@lists.sourceforge.net>;
Wed, 04 Mar 2015 18:16:28 -0800 (PST)
X-Received: by 10.170.41.16 with SMTP id 16mr4087281ykj.85.1425521787837; Wed,
04 Mar 2015 18:16:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.170.90.86 with HTTP; Wed, 4 Mar 2015 18:16:07 -0800 (PST)
In-Reply-To: <CAEY8wq701HBWQVmvch=dQF09WJ7cJQX0RZd2XKd-23w_AUTK=w@mail.gmail.com>
References: <1755215207.4498654.1425519657710.JavaMail.yahoo@mail.yahoo.com>
<CAEY8wq701HBWQVmvch=dQF09WJ7cJQX0RZd2XKd-23w_AUTK=w@mail.gmail.com>
From: Kevin Greene <kgreenek@gmail.com>
Date: Wed, 4 Mar 2015 18:16:07 -0800
Message-ID: <CAEY8wq78CeguA0QyGfud_CorhXA5j=vn--2tYOcYyE4x4eXVfA@mail.gmail.com>
To: Thy Shizzle <thashiznets@yahoo.com.au>
Content-Type: multipart/alternative; boundary=001a11c03310c8a40005108127b2
X-Spam-Score: -0.6 (/)
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
(kgreenek[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1YTLKz-0000WY-Gp
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Useless Address attack?
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: Thu, 05 Mar 2015 02:16:34 -0000
--001a11c03310c8a40005108127b2
Content-Type: text/plain; charset=UTF-8
Also (I am fuzzy on the details for this), Bitcoind will detect when a node
is misbehaving and (I believe) it will blacklist misbehaving nodes for a
period of time so it doesn't continually keep trying to connect to tarpit
nodes, for example.
On Wed, Mar 4, 2015 at 6:13 PM, Kevin Greene <kgreenek@gmail.com> wrote:
> Bitcoind protects against this by storing the addresses it has learned
> about in buckets. The bucket an address is stored in is chosen based on the
> IP of the peer that advertised the addr message, and the address in the
> addr message itself. The idea is that the bucketing is done in a randomized
> way so that no attacker should be able to fill your database with his or
> her own nodes.
>
> From addrman.h
> <https://github.com/bitcoin/bitcoin/blob/master/src/addrman.h>:
>
> /** Stochastic address manager
> *
> * Design goals:
> * * Keep the address tables in-memory, and asynchronously dump the
> entire to able in peers.dat.
> * * Make sure no (localized) attacker can fill the entire table with his
> nodes/addresses.
> *
> * To that end:
> * * Addresses are organized into buckets.
> * * Address that have not yet been tried go into 256 "new" buckets.
> * * Based on the address range (/16 for IPv4) of source of the
> information, 32 buckets are selected at random
> * * The actual bucket is chosen from one of these, based on the
> range the address itself is located.
> * * One single address can occur in up to 4 different buckets, to
> increase selection chances for addresses that
> * are seen frequently. The chance for increasing this multiplicity
> decreases exponentially.
> * * When adding a new address to a full bucket, a randomly chosen
> entry (with a bias favoring less recently seen
> * ones) is removed from it first.
> * * Addresses of nodes that are known to be accessible go into 64
> "tried" buckets.
> * * Each address range selects at random 4 of these buckets.
> * * The actual bucket is chosen from one of these, based on the full
> address.
> * * When adding a new good address to a full bucket, a randomly
> chosen entry (with a bias favoring less recently
> * tried ones) is evicted from it, back to the "new" buckets.
> * * Bucket selection is based on cryptographic hashing, using a
> randomly-generated 256-bit key, which should not
> * be observable by adversaries.
> * * Several indexes are kept for high performance. Defining
> DEBUG_ADDRMAN will introduce frequent (and expensive)
> * consistency checks for the entire data structure.
> */
>
> On Wed, Mar 4, 2015 at 5:40 PM, Thy Shizzle <thashiznets@yahoo.com.au>
> wrote:
>
>> Hi, so just a thought as my node relays addresses etc. If I wanted to
>> really slow down communication over the P2P network, what's stopping me
>> from popping up a heap of dummy nodes that do nothing more than exchange
>> version and relay addresses, except I send addr messages with all 1000
>> addresses pointing to my useless nodes that never send invs or respond to
>> getdata etc so clients connect to my dumb nodes instead of legit ones. I'm
>> thinking that if I fill up their address pool with enough addresses to dumb
>> nodes and keep them really fresh time wise, it could have a bit of an
>> impact especially if all 8 outbound connections are used up by my dumb
>> nodes right?
>>
>> I don't want to do this obviously, I'm just thinking about it as I'm
>> building my node, what is there to stop this happening?
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
--001a11c03310c8a40005108127b2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"color:#336666">Also =
(I am fuzzy on the details for this), Bitcoind will detect when a node is m=
isbehaving and (I believe) it will blacklist misbehaving nodes for a period=
of time so it doesn't continually keep trying to connect to tarpit nod=
es, for example.</div></div><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">On Wed, Mar 4, 2015 at 6:13 PM, Kevin Greene <span dir=3D"ltr">&=
lt;<a href=3D"mailto:kgreenek@gmail.com" target=3D"_blank">kgreenek@gmail.c=
om</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div class=3D"gmail_default" style=3D"color:rgb(51,102,102)">Bitcoind prot=
ects against this by storing the addresses it has learned about in buckets.=
The bucket an address is stored in is chosen based on the IP of the peer t=
hat advertised the addr message, and the address in the addr message itself=
. The idea is that the bucketing is done in a randomized way so that no att=
acker should be able to fill your database with his or her own nodes.</div>=
<div class=3D"gmail_default" style=3D"color:rgb(51,102,102)"><br></div><div=
class=3D"gmail_default" style=3D"color:rgb(51,102,102)">From <a href=3D"ht=
tps://github.com/bitcoin/bitcoin/blob/master/src/addrman.h" target=3D"_blan=
k">addrman.h</a>:</div><div class=3D"gmail_default" style=3D"color:rgb(51,1=
02,102)"><br></div><div class=3D"gmail_default" style=3D"color:rgb(51,102,1=
02)"><div class=3D"gmail_default">/** Stochastic address manager</div><div =
class=3D"gmail_default">=C2=A0*</div><div class=3D"gmail_default">=C2=A0* D=
esign goals:</div><div class=3D"gmail_default">=C2=A0* =C2=A0* Keep the add=
ress tables in-memory, and asynchronously dump the entire to able in peers.=
dat.</div><div class=3D"gmail_default">=C2=A0* =C2=A0* Make sure no (locali=
zed) attacker can fill the entire table with his nodes/addresses.</div><div=
class=3D"gmail_default">=C2=A0*</div><div class=3D"gmail_default">=C2=A0* =
To that end:</div><div class=3D"gmail_default">=C2=A0* =C2=A0* Addresses ar=
e organized into buckets.</div><div class=3D"gmail_default">=C2=A0* =C2=A0 =
=C2=A0* Address that have not yet been tried go into 256 "new" bu=
ckets.</div><div class=3D"gmail_default">=C2=A0* =C2=A0 =C2=A0 =C2=A0* Base=
d on the address range (/16 for IPv4) of source of the information, 32 buck=
ets are selected at random</div><div class=3D"gmail_default">=C2=A0* =C2=A0=
=C2=A0 =C2=A0* The actual bucket is chosen from one of these, based on the=
range the address itself is located.</div><div class=3D"gmail_default">=C2=
=A0* =C2=A0 =C2=A0 =C2=A0* One single address can occur in up to 4 differen=
t buckets, to increase selection chances for addresses that</div><div class=
=3D"gmail_default">=C2=A0* =C2=A0 =C2=A0 =C2=A0 =C2=A0are seen frequently. =
The chance for increasing this multiplicity decreases exponentially.</div><=
div class=3D"gmail_default">=C2=A0* =C2=A0 =C2=A0 =C2=A0* When adding a new=
address to a full bucket, a randomly chosen entry (with a bias favoring le=
ss recently seen</div><div class=3D"gmail_default">=C2=A0* =C2=A0 =C2=A0 =
=C2=A0 =C2=A0ones) is removed from it first.</div><div class=3D"gmail_defau=
lt">=C2=A0* =C2=A0 =C2=A0* Addresses of nodes that are known to be accessib=
le go into 64 "tried" buckets.</div><div class=3D"gmail_default">=
=C2=A0* =C2=A0 =C2=A0 =C2=A0* Each address range selects at random 4 of the=
se buckets.</div><div class=3D"gmail_default">=C2=A0* =C2=A0 =C2=A0 =C2=A0*=
The actual bucket is chosen from one of these, based on the full address.<=
/div><div class=3D"gmail_default">=C2=A0* =C2=A0 =C2=A0 =C2=A0* When adding=
a new good address to a full bucket, a randomly chosen entry (with a bias =
favoring less recently</div><div class=3D"gmail_default">=C2=A0* =C2=A0 =C2=
=A0 =C2=A0 =C2=A0tried ones) is evicted from it, back to the "new"=
; buckets.</div><div class=3D"gmail_default">=C2=A0* =C2=A0 =C2=A0* Bucket =
selection is based on cryptographic hashing, using a randomly-generated 256=
-bit key, which should not</div><div class=3D"gmail_default">=C2=A0* =C2=A0=
=C2=A0 =C2=A0be observable by adversaries.</div><div class=3D"gmail_defaul=
t">=C2=A0* =C2=A0 =C2=A0* Several indexes are kept for high performance. De=
fining DEBUG_ADDRMAN will introduce frequent (and expensive)</div><div clas=
s=3D"gmail_default">=C2=A0* =C2=A0 =C2=A0 =C2=A0consistency checks for the =
entire data structure.</div><div class=3D"gmail_default">=C2=A0*/</div></di=
v></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span cla=
ss=3D"">On Wed, Mar 4, 2015 at 5:40 PM, Thy Shizzle <span dir=3D"ltr"><<=
a href=3D"mailto:thashiznets@yahoo.com.au" target=3D"_blank">thashiznets@ya=
hoo.com.au</a>></span> wrote:<br></span><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
span class=3D""><div><div style=3D"color:#000;background-color:#fff;font-fa=
mily:Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Ari=
al,Lucida Grande,Sans-Serif;font-size:16px"><div dir=3D"ltr"> Hi, so just =
a thought as my node relays addresses etc. If I wanted to really slow down =
communication over the P2P network, what's stopping me from popping up =
a heap of dummy nodes that do nothing more than exchange version and relay =
addresses, except I send addr messages with all 1000 addresses pointing to =
my useless nodes that never send invs or respond to getdata etc so clients =
connect to my dumb nodes instead of legit ones. I'm thinking that if I =
fill up their address pool with enough addresses to dumb nodes and keep the=
m really fresh time wise, it could have a bit of an impact especially if al=
l 8 outbound connections are used up by my dumb nodes right?<br><br>I don&#=
39;t want to do this obviously, I'm just thinking about it as I'm b=
uilding my node, what is there to stop this happening?</div></div></div><br=
></span>-------------------------------------------------------------------=
-----------<br>
Dive into the World of Parallel Programming The Go Parallel Website, sponso=
red<br>
by Intel and developed in partnership with Slashdot Media, is your hub for =
all<br>
things parallel software development, from weekly thought leadership blogs =
to<br>
news, videos, case studies, tutorials and more. Take a look and join the<br=
>
conversation now. <a href=3D"http://goparallel.sourceforge.net/" target=3D"=
_blank">http://goparallel.sourceforge.net/</a><br>_________________________=
______________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
--001a11c03310c8a40005108127b2--
|
