From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: <1755215207.4498654.1425519657710.JavaMail.yahoo@mail.yahoo.com> From: Kevin Greene Date: Wed, 4 Mar 2015 18:16:07 -0800 Message-ID: To: Thy Shizzle 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 Subject: Re: [Bitcoin-development] Useless Address attack? X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > : > > /** 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 > 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
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.

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

From addrman.h:

/** Stochastic address manager
=C2=A0*
=C2=A0* D= esign goals:
=C2=A0* =C2=A0* Keep the add= ress tables in-memory, and asynchronously dump the entire to able in peers.= dat.
=C2=A0* =C2=A0* Make sure no (locali= zed) attacker can fill the entire table with his nodes/addresses.
=C2=A0*
=C2=A0* = To that end:
=C2=A0* =C2=A0* Addresses ar= e organized into buckets.
=C2=A0* =C2=A0 = =C2=A0* Address that have not yet been tried go into 256 "new" bu= ckets.
=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
=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 occur in up to 4 differen= t 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.
<= 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
=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 accessib= le go into 64 "tried" buckets.
= =C2=A0* =C2=A0 =C2=A0 =C2=A0* Each address range selects at random 4 of the= se buckets.
=C2=A0* =C2=A0 =C2=A0 =C2=A0*= The actual bucket is chosen from one of these, based on the full address.<= /div>
=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
=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 based on cryptographic hashing, using a randomly-generated 256= -bit key, which 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. De= fining DEBUG_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 <<= a href=3D"mailto:thashiznets@yahoo.com.au" target=3D"_blank">thashiznets@ya= hoo.com.au> wrote:
<= span class=3D"">
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?

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?
-------------------------------------------------------------------= -----------
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-de= velopment



--001a11c03310c8a40005108127b2--