Scale up addrman

This change was suggested as Countermeasure 6 in
Eclipse Attacks on Bitcoin’s Peer-to-Peer Network, Ethan Heilman,
Alison Kendler, Aviv Zohar, Sharon Goldberg. ePrint Archive Report
2015/263. March 2015.

Rebased-From: 1d21ba2f5ecbf03086d0b65c4c4c80a39a94c2ee
Github-Pull: #5941

Conflicts:
	src/addrman.h

1 files changed, 30 insertions, 30 deletions

diff --git a/src/addrman.h b/src/addrman.h
index 5d49b99a6..916f4da4b 100644
--- a/src/addrman.h
+++ b/src/addrman.h
@@ -98,49 +98,49 @@ public:
 
 };
 
-// Stochastic address manager
-//
-// Design goals:
-//  * Only keep a limited number of addresses around, so that addr.dat and memory requirements do not grow without bound.
-//  * Keep the address tables in-memory, and asynchronously dump the entire to able in addr.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.
+/** 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 1024 "new" buckets.
+ *      * Based on the address range (/16 for IPv4) of source of the information, 64 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 8 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 256 "tried" buckets.
+ *      * Each address range selects at random 8 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.
+ */
 
 // total number of buckets for tried addresses
-#define ADDRMAN_TRIED_BUCKET_COUNT 64
+#define ADDRMAN_TRIED_BUCKET_COUNT 256
 
 // total number of buckets for new addresses
-#define ADDRMAN_NEW_BUCKET_COUNT 256
+#define ADDRMAN_NEW_BUCKET_COUNT 1024
 
 // maximum allowed number of entries in buckets for new and tried addresses
 #define ADDRMAN_BUCKET_SIZE 64
 
 // over how many buckets entries with tried addresses from a single group (/16 for IPv4) are spread
-#define ADDRMAN_TRIED_BUCKETS_PER_GROUP 4
+#define ADDRMAN_TRIED_BUCKETS_PER_GROUP 8
 
 // over how many buckets entries with new addresses originating from a single group are spread
-#define ADDRMAN_NEW_BUCKETS_PER_SOURCE_GROUP 32
+#define ADDRMAN_NEW_BUCKETS_PER_SOURCE_GROUP 64
 
 // in how many buckets for entries with new addresses a single address may occur
-#define ADDRMAN_NEW_BUCKETS_PER_ADDRESS 4
+#define ADDRMAN_NEW_BUCKETS_PER_ADDRESS 8
 
 // how old addresses can maximally be
 #define ADDRMAN_HORIZON_DAYS 30