Re: [Bitcoin-development] Useless Address attack?

2015-03-04 Thread Kevin Greene
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
https://github.com/bitcoin/bitcoin/blob/master/src/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 thashizn...@yahoo.com.au
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


--
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


Re: [Bitcoin-development] Useless Address attack?

2015-03-04 Thread Kevin Greene
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 kgree...@gmail.com 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
 https://github.com/bitcoin/bitcoin/blob/master/src/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 thashizn...@yahoo.com.au
 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



--
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


Re: [Bitcoin-development] Useless Address attack?

2015-03-04 Thread Thy Shizzle
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 tarpit nodes, for 
example.
On Wed, Mar 4, 2015 at 6:13 PM, Kevin Greene kgree...@gmail.com 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 thashizn...@yahoo.com.au 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



--
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