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
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <harro84@yahoo.com.au>) id 1YTMMN-00031I-9S
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Mar 2015 03:22:03 +0000
Received: from nm34-vm1.bullet.mail.ne1.yahoo.com ([98.138.229.81])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YTMMK-0001rl-Tb
for bitcoin-development@lists.sourceforge.net;
Thu, 05 Mar 2015 03:22:03 +0000
Received: from [127.0.0.1] by nm34.bullet.mail.ne1.yahoo.com with NNFMP;
05 Mar 2015 03:21:55 -0000
Received: from [98.138.100.111] by nm34.bullet.mail.ne1.yahoo.com with NNFMP;
05 Mar 2015 03:18:57 -0000
Received: from [66.196.81.172] by tm100.bullet.mail.ne1.yahoo.com with NNFMP;
05 Mar 2015 03:18:55 -0000
Received: from [98.139.212.203] by tm18.bullet.mail.bf1.yahoo.com with NNFMP;
05 Mar 2015 03:18:55 -0000
Received: from [127.0.0.1] by omp1012.mail.bf1.yahoo.com with NNFMP;
05 Mar 2015 03:18:55 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 595774.18119.bm@omp1012.mail.bf1.yahoo.com
X-YMail-OSG: 1BwNzCcVM1n6st4S2NmnATWDHfNteapxFwwsugRUnHITaJrhkPkgNRcp3vF8k0R
wJHgDMl_S0SGjm15yqGZofQUdmIFE0Y.GJIPZqG9vivg_5unW0gx_B_sc_rIZXVw3MR0w0v5fXbl
ATPiSnQc84UfbYaJOWfD1.J8jjUHa8lU82oTl7R_PVfj6El4U_ArOtnaMe6FKQr2gZQ5IH.DdDKz
ZBxEKgxOeM2sjmryk_Pkbc3KcmYHT.fjIE9HGpE1yfYFgKUxGi7ozQmB0I6NzotKbkjZ8hclYXiN
zS6DL43e7V9lwx.qLqDAmkahyV7jWRbkVEYM0_uvBZ9BroZFZeYw8thD24lDDNGljOQQBQyrhzkQ
56P3nhMzRtEaIVsl6BsU.74BMokZmPN7BthwIceFgTgMHRSzcVIRKYsXeCBLXf7v9a.MS0uOtMoL
pwb1Bdw1oKirBovtDFrz4QYAIh79Lyxf2VEzA6K.ruIQuHRQXUc7TQPIEX9azUxRfsQndS4f4Uqs
IFStMRKY9CjV_.Jg_O0nb6pTubKKSlA9tkvu75okKZpYv11qxtPb5gNWYq1EuTekuxW6bRW2.VLT
PkWBHB1B.qToqVHGjN5f6XNWMmV97VE9Ke2o2P4vj9dld5J4ZLVyL4ISh1NWguInqg.BfQOYHqi_
6kVtY2bxL4eD_i.qhpyGdhNldUlJzC4vTCPDsMVhJfLmFTS6kr3uXeVK8h2CRflk-
Received: by 66.196.81.108; Thu, 05 Mar 2015 03:18:55 +0000
Date: Thu, 5 Mar 2015 03:18:54 +0000 (UTC)
From: Thy Shizzle <thashiznets@yahoo.com.au>
To: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Message-ID: <2100721077.4566193.1425525534301.JavaMail.yahoo@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_4566192_381640236.1425525534291"
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(harro84[at]yahoo.com.au)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [98.138.229.81 listed in list.dnswl.org]
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (harro84[at]yahoo.com.au)
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: 1YTMMK-0001rl-Tb
Subject: Re: [Bitcoin-development] Useless Address attack?
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Thy Shizzle <thashiznets@yahoo.com.au>
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 03:22:03 -0000
------=_Part_4566192_381640236.1425525534291
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Interesting!
Thanks Kevin, I now need to research this and include such protections in m=
y node.=C2=A0
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 p=
eriod of time so it doesn't continually keep trying to connect to tarpit no=
des, 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 abou=
t 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 m=
essage itself. The idea is that the bucketing is done in a randomized way s=
o that no attacker should be able to fill your database with his or her own=
nodes.
From addrman.h:
/** Stochastic address manager=C2=A0*=C2=A0* Design goals:=C2=A0* =C2=A0* K=
eep the address tables in-memory, and asynchronously dump the entire to abl=
e in peers.dat.=C2=A0* =C2=A0* Make sure no (localized) attacker can fill t=
he entire table with his nodes/addresses.=C2=A0*=C2=A0* To that end:=C2=A0*=
=C2=A0* Addresses are organized into buckets.=C2=A0* =C2=A0 =C2=A0* Addres=
s that have not yet been tried go into 256 "new" buckets.=C2=A0* =C2=A0 =C2=
=A0 =C2=A0* Based on the address range (/16 for IPv4) of source of the info=
rmation, 32 buckets are selected at random=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.=C2=A0* =C2=A0 =C2=A0 =C2=A0* One single address can occu=
r in up to 4 different buckets, to increase selection chances for addresses=
that=C2=A0* =C2=A0 =C2=A0 =C2=A0 =C2=A0are seen frequently. The chance for=
increasing this multiplicity decreases exponentially.=C2=A0* =C2=A0 =C2=A0=
=C2=A0* When adding a new address to a full bucket, a randomly chosen entr=
y (with a bias favoring less recently seen=C2=A0* =C2=A0 =C2=A0 =C2=A0 =C2=
=A0ones) is removed from it first.=C2=A0* =C2=A0 =C2=A0* Addresses of nodes=
that are known to be accessible go into 64 "tried" buckets.=C2=A0* =C2=A0 =
=C2=A0 =C2=A0* Each address range selects at random 4 of these buckets.=C2=
=A0* =C2=A0 =C2=A0 =C2=A0* The actual bucket is chosen from one of these, b=
ased on the full address.=C2=A0* =C2=A0 =C2=A0 =C2=A0* When adding a new go=
od address to a full bucket, a randomly chosen entry (with a bias favoring =
less recently=C2=A0* =C2=A0 =C2=A0 =C2=A0 =C2=A0tried ones) is evicted from=
it, back to the "new" buckets.=C2=A0* =C2=A0 =C2=A0* Bucket selection is b=
ased on cryptographic hashing, using a randomly-generated 256-bit key, whic=
h should not=C2=A0* =C2=A0 =C2=A0 =C2=A0be observable by adversaries.=C2=A0=
* =C2=A0 =C2=A0* Several indexes are kept for high performance. Defining DE=
BUG_ADDRMAN will introduce frequent (and expensive)=C2=A0* =C2=A0 =C2=A0 =
=C2=A0consistency checks for the entire data structure.=C2=A0*/
On Wed, Mar 4, 2015 at 5:40 PM, Thy Shizzle <thashiznets@yahoo.com.au> wrot=
e:
Hi, so just a thought as my node relays addresses etc. If I wanted to real=
ly slow down communication over the P2P network, what's stopping me from po=
pping up a heap of dummy nodes that do nothing more than exchange version a=
nd relay addresses, except I send addr messages with all 1000 addresses poi=
nting 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 kee=
p 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 buildi=
ng my node, what is there to stop this happening?
---------------------------------------------------------------------------=
---
Dive into the World of Parallel Programming The Go Parallel Website, sponso=
red
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
------=_Part_4566192_381640236.1425525534291
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><body><div style=3D"color:#000; background-color:#fff; font-family:He=
lvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial,=
Lucida Grande, Sans-Serif;font-size:16px"><div id=3D"yui_3_16_0_1_14255193=
11352_10467" dir=3D"ltr">Interesting!</div><div id=3D"yui_3_16_0_1_14255193=
11352_10477" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1425519311352_10=
479" dir=3D"ltr">Thanks Kevin, I now need to research this and include such=
protections in my node. </div><div id=3D"yui_3_16_0_1_1425519311352_1=
0480"><br></div><div id=3D"yui_3_16_0_1_1425519311352_10411" dir=3D"ltr"><d=
iv id=3D"yui_3_16_0_1_1425519311352_10410" style=3D"color: rgb(51, 102, 102=
);">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 tarpi=
t nodes, for example.</div></div><div id=3D"yui_3_16_0_1_1425519311352_1037=
4"><br><div id=3D"yui_3_16_0_1_1425519311352_10373">On Wed, Mar 4, 2015 at =
6:13 PM, Kevin Greene <span id=3D"yui_3_16_0_1_1425519311352_10412" dir=3D"=
ltr"><<a tabindex=3D"-1" id=3D"yui_3_16_0_1_1425519311352_10431" href=3D=
"mailto:kgreenek@gmail.com" target=3D"_parent"><font id=3D"yui_3_16_0_1_142=
5519311352_10430" color=3D"#0066cc">kgreenek@gmail.com</font></a>></span=
> wrote:<br><blockquote id=3D"yui_3_16_0_1_1425519311352_10372" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204=
, 204); border-left-width: 1px; border-left-style: solid;"><div id=3D"yui_3=
_16_0_1_1425519311352_10371" dir=3D"ltr"><div id=3D"yui_3_16_0_1_1425519311=
352_10404" style=3D"color: rgb(51, 102, 102);">Bitcoind protects against th=
is 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 t=
hat 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.</div><div id=3D"yui_=
3_16_0_1_1425519311352_10422" style=3D"color: rgb(51, 102, 102);"><br></div=
><div id=3D"yui_3_16_0_1_1425519311352_10387" style=3D"color: rgb(51, 102, =
102);">From <a tabindex=3D"-1" href=3D"https://github.com/bitcoin/bitcoin/b=
lob/master/src/addrman.h" target=3D"_parent"><font color=3D"#0066cc">addrma=
n.h</font></a>:</div><div id=3D"yui_3_16_0_1_1425519311352_10427" style=3D"=
color: rgb(51, 102, 102);"><br></div><div id=3D"yui_3_16_0_1_1425519311352_=
10370" style=3D"color: rgb(51, 102, 102);"><div id=3D"yui_3_16_0_1_14255193=
11352_10428">/** Stochastic address manager</div><div id=3D"yui_3_16_0_1_14=
25519311352_10429"> *</div><div id=3D"yui_3_16_0_1_1425519311352_10403=
"> * Design goals:</div><div id=3D"yui_3_16_0_1_1425519311352_10432">&=
nbsp;* * Keep the address tables in-memory, and asynchronously dump t=
he entire to able in peers.dat.</div><div id=3D"yui_3_16_0_1_1425519311352_=
10481"> * * Make sure no (localized) attacker can fill the entir=
e table with his nodes/addresses.</div><div id=3D"yui_3_16_0_1_142551931135=
2_10482"> *</div><div id=3D"yui_3_16_0_1_1425519311352_10402"> * =
To that end:</div><div id=3D"yui_3_16_0_1_1425519311352_10483"> * &nbs=
p;* Addresses are organized into buckets.</div><div> * * =
Address that have not yet been tried go into 256 "new" buckets.</div><div i=
d=3D"yui_3_16_0_1_1425519311352_10484"> * * Based =
on the address range (/16 for IPv4) of source of the information, 32 bucket=
s are selected at random</div><div id=3D"yui_3_16_0_1_1425519311352_10401">=
* * The actual bucket is chosen from one of these=
, based on the range the address itself is located.</div><div> *  =
; * One single address can occur in up to 4 different buckets,=
to increase selection chances for addresses that</div><div> * =
are seen frequently. The chance for increasing this mul=
tiplicity decreases exponentially.</div><div id=3D"yui_3_16_0_1_14255193113=
52_10400"> * * When adding a new address to a full=
bucket, a randomly chosen entry (with a bias favoring less recently seen</=
div><div> * ones) is removed from it first.=
</div><div> * * Addresses of nodes that are known to be a=
ccessible go into 64 "tried" buckets.</div><div> *  =
;* Each address range selects at random 4 of these buckets.</div><div> =
;* * The actual bucket is chosen from one of these, bas=
ed on the full address.</div><div> * * When adding=
a new good address to a full bucket, a randomly chosen entry (with a bias =
favoring less recently</div><div> * tried o=
nes) is evicted from it, back to the "new" buckets.</div><div> *  =
; * Bucket selection is based on cryptographic hashing, using a rando=
mly-generated 256-bit key, which should not</div><div> * =
be observable by adversaries.</div><div> * * Sever=
al indexes are kept for high performance. Defining DEBUG_ADDRMAN will intro=
duce frequent (and expensive)</div><div> * consist=
ency checks for the entire data structure.</div><div id=3D"yui_3_16_0_1_142=
5519311352_10369"> */</div></div></div><div id=3D"yui_3_16_0_1_1425519=
311352_10375"><br><div id=3D"yui_3_16_0_1_1425519311352_10380"><span id=3D"=
yui_3_16_0_1_1425519311352_10379">On Wed, Mar 4, 2015 at 5:40 PM, Thy Shizz=
le <span id=3D"yui_3_16_0_1_1425519311352_10378" dir=3D"ltr"><<a tabinde=
x=3D"-1" id=3D"yui_3_16_0_1_1425519311352_10377" href=3D"mailto:thashiznets=
@yahoo.com.au" target=3D"_parent"><font id=3D"yui_3_16_0_1_1425519311352_10=
376" color=3D"#0066cc">thashiznets@yahoo.com.au</font></a>></span> wrote=
:<br></span><blockquote id=3D"yui_3_16_0_1_1425519311352_10385" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204=
, 204); border-left-width: 1px; border-left-style: solid;"><span id=3D"yui_=
3_16_0_1_1425519311352_10384"><div id=3D"yui_3_16_0_1_1425519311352_10383">=
<div id=3D"yui_3_16_0_1_1425519311352_10382" style=3D"color: rgb(0, 0, 0); =
font-family: Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helve=
tica,Arial,Lucida Grande,Sans-Serif; font-size: 16px; background-color: rgb=
(255, 255, 255);"><div id=3D"yui_3_16_0_1_1425519311352_10381" dir=3D"ltr">=
Hi, so just a thought as my node relays addresses etc. If I wanted to rea=
lly slow down communication over the P2P network, what's stopping me from p=
opping 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 po=
inting to my useless nodes that never send invs or respond to getdata etc s=
o 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 ke=
ep 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?<br><br>I=
don't want to do this obviously, I'm just thinking about it as I'm buildin=
g my node, what is there to stop this happening?</div></div></div><br></spa=
n>-------------------------------------------------------------------------=
-----<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 tabindex=3D"-1" href=3D"http://goparallel.sourceforge.=
net/" target=3D"_parent"><font color=3D"#0066cc">http://goparallel.sourcefo=
rge.net/</font></a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a tabindex=3D"-1" href=3D"mailto:Bitcoin-development@lists.sourceforge.net=
" target=3D"_parent"><font color=3D"#0066cc">Bitcoin-development@lists.sour=
ceforge.net</font></a><br>
<a tabindex=3D"-1" href=3D"https://lists.sourceforge.net/lists/listinfo/bit=
coin-development" target=3D"_parent"><font color=3D"#0066cc">https://lists.=
sourceforge.net/lists/listinfo/bitcoin-development</font></a><br>
</blockquote></div><br></div>
</blockquote></div></div></div></body></html>
------=_Part_4566192_381640236.1425525534291--
|
