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 ) 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 To: "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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
Interesting!

Thanks Kevin, I now need to research this and include such= protections in my node. 

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.

On Wed, Mar 4, 2015 at = 6:13 PM, Kevin Greene <kgreenek@gmail.com> wrote:
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.


/** Stochastic address manager
 *
 * Design goals:
&= nbsp;*  * Keep the address tables in-memory, and asynchronously dump t= he entire to able in peers.dat.
 *  * Make sure no (localized) attacker can fill the entir= e table with his nodes/addresses.
 *
 * = To that end:
 * &nbs= p;* 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 bucket= s 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 mul= tiplicity 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 a= ccessible go into 64 "tried" buckets.
 *      = ;* Each address range selects at random 4 of these buckets.
 = ;*      * The actual bucket is chosen from one of these, bas= ed 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 o= nes) is evicted from it, back to the "new" buckets.
 *  = ;  * Bucket selection is based on cryptographic hashing, using a rando= mly-generated 256-bit key, which should not
 *    =  be observable by adversaries.
 *    * Sever= al indexes are kept for high performance. Defining DEBUG_ADDRMAN will intro= duce frequent (and expensive)
 *      consist= ency checks for the entire data structure.
 */

On Wed, Mar 4, 2015 at 5:40 PM, Thy Shizz= le <thashiznets@yahoo.com.au> wrote= :
=
= 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?

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?

-------------------------------------------------------------------------= -----
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.sourcefo= rge.net/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sour= ceforge.net
https://lists.= sourceforge.net/lists/listinfo/bitcoin-development

------=_Part_4566192_381640236.1425525534291--