Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YTLIb-0007TX-QW for bitcoin-development@lists.sourceforge.net; Thu, 05 Mar 2015 02:14:05 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.45 as permitted sender) client-ip=209.85.213.45; envelope-from=kgreenek@gmail.com; helo=mail-yh0-f45.google.com; Received: from mail-yh0-f45.google.com ([209.85.213.45]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YTLIZ-000318-WA for bitcoin-development@lists.sourceforge.net; Thu, 05 Mar 2015 02:14:05 +0000 Received: by yhnv1 with SMTP id v1so7523290yhn.2 for ; Wed, 04 Mar 2015 18:13:58 -0800 (PST) X-Received: by 10.236.30.233 with SMTP id k69mr4798762yha.123.1425521638560; Wed, 04 Mar 2015 18:13:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.170.90.86 with HTTP; Wed, 4 Mar 2015 18:13:38 -0800 (PST) In-Reply-To: <1755215207.4498654.1425519657710.JavaMail.yahoo@mail.yahoo.com> References: <1755215207.4498654.1425519657710.JavaMail.yahoo@mail.yahoo.com> From: Kevin Greene Date: Wed, 4 Mar 2015 18:13:38 -0800 Message-ID: To: Thy Shizzle Content-Type: multipart/alternative; boundary=001a11c20276e2da2e0510811ec6 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: 1YTLIZ-000318-WA 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:14:06 -0000 --001a11c20276e2da2e0510811ec6 Content-Type: text/plain; charset=UTF-8 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 > > --001a11c20276e2da2e0510811ec6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bitcoind protects against this by storing the addresses it has learned a= bout 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 add= r message itself. The idea is that the bucketing is done in a randomized wa= y so that no attacker should be able to fill your database with his or her = own nodes.

Fr= om addrman.h:

/** Stochastic address = manager
=C2=A0*
=C2=A0* Design goals:
=C2=A0* = =C2=A0* Keep the address tables in-memory, and asynchronously dump the enti= re to able in peers.dat.
=C2=A0* =C2=A0* = Make sure no (localized) attacker can fill the 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* Address that have not yet been tried go into 25= 6 "new" buckets.
=C2=A0* =C2=A0= =C2=A0 =C2=A0* Based on the address range (/16 for IPv4) of source of the = information, 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 occ= ur in up to 4 different buckets, to increase selection chances for addresse= s that
=C2=A0* =C2=A0 =C2=A0 =C2=A0 =C2= =A0are seen frequently. The chance for increasing this multiplicity decreas= es exponentially.
=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 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 a= re known to be accessible go into 64 "tried" buckets.
=C2=A0* =C2=A0 =C2=A0 =C2=A0* Each address range sel= ects at random 4 of these buckets.
=C2=A0= * =C2=A0 =C2=A0 =C2=A0* The actual bucket is chosen from one of these, base= d on the full address.
=C2=A0* =C2=A0 =C2= =A0 =C2=A0* When adding a new good address to a full bucket, a randomly cho= sen entry (with a bias favoring less recently
=C2=A0* =C2=A0 =C2=A0 =C2=A0 =C2=A0tried ones) is evicted from it, bac= k 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 f= or high performance. Defining DEBUG_ADDRMAN will introduce frequent (and ex= pensive)
=C2=A0* =C2=A0 =C2=A0 =C2=A0cons= istency checks for the entire data structure.
=C2=A0*/

On Wed, Mar 4, 2015 at 5:40 PM, Thy Shizzle <thashizn= ets@yahoo.com.au> wrote:
Hi, so just a thought as my no= de 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 no= des that do nothing more than exchange version and relay addresses, except = I send addr messages with all 1000 addresses pointing to my useless nodes t= hat 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 addr= ess pool with enough addresses to dumb nodes and keep them really fresh tim= e wise, it could have a bit of an impact especially if all 8 outbound conne= ctions are used up by my dumb nodes right?

I don't want to do th= is obviously, I'm just thinking about it as I'm building my node, w= hat 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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a11c20276e2da2e0510811ec6--