<html><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;font-size:16px"><div id="yui_3_16_0_1_1425519311352_10467" dir="ltr">Interesting!</div><div id="yui_3_16_0_1_1425519311352_10477" dir="ltr"><br></div><div id="yui_3_16_0_1_1425519311352_10479" dir="ltr">Thanks Kevin, I now need to research this and include such protections in my node. </div><div id="yui_3_16_0_1_1425519311352_10480"><br></div><div id="yui_3_16_0_1_1425519311352_10411" dir="ltr"><div id="yui_3_16_0_1_1425519311352_10410" style="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 tarpit nodes, for example.</div></div><div id="yui_3_16_0_1_1425519311352_10374"><br><div id="yui_3_16_0_1_1425519311352_10373">On Wed, Mar 4, 2015 at 6:13 PM, Kevin Greene <span id="yui_3_16_0_1_1425519311352_10412" dir="ltr"><<a tabindex="-1" id="yui_3_16_0_1_1425519311352_10431" href="mailto:kgreenek@gmail.com" target="_parent"><font id="yui_3_16_0_1_1425519311352_10430" color="#0066cc">kgreenek@gmail.com</font></a>></span> wrote:<br><blockquote id="yui_3_16_0_1_1425519311352_10372" style="margin: 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="yui_3_16_0_1_1425519311352_10371" dir="ltr"><div id="yui_3_16_0_1_1425519311352_10404" style="color: rgb(51, 102, 102);">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.</div><div id="yui_3_16_0_1_1425519311352_10422" style="color: rgb(51, 102, 102);"><br></div><div id="yui_3_16_0_1_1425519311352_10387" style="color: rgb(51, 102, 102);">From <a tabindex="-1" href="https://github.com/bitcoin/bitcoin/blob/master/src/addrman.h" target="_parent"><font color="#0066cc">addrman.h</font></a>:</div><div id="yui_3_16_0_1_1425519311352_10427" style="color: rgb(51, 102, 102);"><br></div><div id="yui_3_16_0_1_1425519311352_10370" style="color: rgb(51, 102, 102);"><div id="yui_3_16_0_1_1425519311352_10428">/** Stochastic address manager</div><div id="yui_3_16_0_1_1425519311352_10429"> *</div><div id="yui_3_16_0_1_1425519311352_10403"> * Design goals:</div><div id="yui_3_16_0_1_1425519311352_10432"> * * Keep the address tables in-memory, and asynchronously dump the entire to able in peers.dat.</div><div id="yui_3_16_0_1_1425519311352_10481"> * * Make sure no (localized) attacker can fill the entire table with his nodes/addresses.</div><div id="yui_3_16_0_1_1425519311352_10482"> *</div><div id="yui_3_16_0_1_1425519311352_10402"> * To that end:</div><div id="yui_3_16_0_1_1425519311352_10483"> * * Addresses are organized into buckets.</div><div> * * Address that have not yet been tried go into 256 "new" buckets.</div><div id="yui_3_16_0_1_1425519311352_10484"> * * Based on the address range (/16 for IPv4) of source of the information, 32 buckets are selected at random</div><div id="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 multiplicity decreases exponentially.</div><div id="yui_3_16_0_1_1425519311352_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 accessible 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, based 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 ones) is evicted from it, back to the "new" buckets.</div><div> * * Bucket selection is based on cryptographic hashing, using a randomly-generated 256-bit key, which should not</div><div> * be observable by adversaries.</div><div> * * Several indexes are kept for high performance. Defining DEBUG_ADDRMAN will introduce frequent (and expensive)</div><div> * consistency checks for the entire data structure.</div><div id="yui_3_16_0_1_1425519311352_10369"> */</div></div></div><div id="yui_3_16_0_1_1425519311352_10375"><br><div id="yui_3_16_0_1_1425519311352_10380"><span id="yui_3_16_0_1_1425519311352_10379">On Wed, Mar 4, 2015 at 5:40 PM, Thy Shizzle <span id="yui_3_16_0_1_1425519311352_10378" dir="ltr"><<a tabindex="-1" id="yui_3_16_0_1_1425519311352_10377" href="mailto:thashiznets@yahoo.com.au" target="_parent"><font id="yui_3_16_0_1_1425519311352_10376" color="#0066cc">thashiznets@yahoo.com.au</font></a>></span> wrote:<br></span><blockquote id="yui_3_16_0_1_1425519311352_10385" style="margin: 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="yui_3_16_0_1_1425519311352_10384"><div id="yui_3_16_0_1_1425519311352_10383"><div id="yui_3_16_0_1_1425519311352_10382" style="color: rgb(0, 0, 0); font-family: Helvetica Neue-Light,Helvetica Neue Light,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif; font-size: 16px; background-color: rgb(255, 255, 255);"><div id="yui_3_16_0_1_1425519311352_10381" dir="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 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 building 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, sponsored<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="-1" href="http://goparallel.sourceforge.net/" target="_parent"><font color="#0066cc">http://goparallel.sourceforge.net/</font></a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a tabindex="-1" href="mailto:Bitcoin-development@lists.sourceforge.net" target="_parent"><font color="#0066cc">Bitcoin-development@lists.sourceforge.net</font></a><br>
<a tabindex="-1" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_parent"><font color="#0066cc">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</font></a><br>
</blockquote></div><br></div>
</blockquote></div></div></div></body></html>