user132147: Bitcoin core states that an entry can be part of maximum 8 buckets. I don't understand how an entry can map to 8 buckets when the data in the entry is the same.
uint64_t hash1 = (CHashWriter(SER_GETHASH, 0) << nKey << GetGroup(asmap) << vchSourceGroupKey).GetCheapHash();

uint64_t hash2 = (CHashWriter(SER_GETHASH, 0) << nKey << vchSourceGroupKey << (hash1 % ADDRMAN_NEW_BUCKETS_PER_SOURCE_GROUP)).GetCheapHash();

return hash2 % ADDRMAN_NEW_BUCKET_COUNT;

When the input is the same, how can it return 8 different values?

user13866: That code is from src\addrman.cpp. The code's author has in the past pointed out the associated comments in addrman.h starting around line 91
You should refer to the original source but I'll quote the relevant comments here
(https://opensource.org/licenses/mit-license.php)
Stochastic address manager
Design goals:

Keep the address tables in-memory, and asynchronously dump the entire table to peers.dat.
Make sure no (localized) attacker can fill the entire table with his nodes/addresses.

To that end:

Addresses are organized into buckets that can each store up to 64 entries.

Addresses to which our node has not successfully connected go into 1024 "new" buckets.

Based on the address range (/16 for IPv4) of the source of information, or if an asmap is provided,
the AS it belongs to (for IPv4/IPv6), 64 buckets are selected at random.
The actual bucket is chosen from one of these, based on the range in which the address itself is located.
The position in the bucket is chosen based on the full address.
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 an occupied position of a bucket, it will not replace the existing entry
unless that address is also stored in another bucket or it doesn't meet one of several quality criteria
(see IsTerrible for exact criteria).
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 an occupied position of a bucket, a FEELER connection to the
old address is attempted. The old entry is only replaced and moved back to the "new" buckets if this
attempt was unsuccessful.


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. Setting m_consistency_check_ratio with the -checkaddrman
configuration option will introduce (expensive) consistency checks for the entire data structure.






I don't understand how an entry can map to 8 buckets when the data in the entry is the same.

To me, the comments suggest that, for tried nodes, the address range (e.g. 99.0/16) selects eight buckets but the whole address (e.g. 99.0.0.55) selects one of those eight.
I've no idea if that helps, but I think it ought to, and if not, someone more knowledgable will probably provide a better answer.

132147: <p>Bitcoin core states that an entry can be part of maximum 8 buckets. I don't understand how an entry can map to 8 buckets when the data in the entry is the same.</p>
<pre><code>uint64_t hash1 = (CHashWriter(SER_GETHASH, 0) &lt;&lt; nKey &lt;&lt; GetGroup(asmap) &lt;&lt; vchSourceGroupKey).GetCheapHash();

uint64_t hash2 = (CHashWriter(SER_GETHASH, 0) &lt;&lt; nKey &lt;&lt; vchSourceGroupKey &lt;&lt; (hash1 % ADDRMAN_NEW_BUCKETS_PER_SOURCE_GROUP)).GetCheapHash();

return hash2 % ADDRMAN_NEW_BUCKET_COUNT;
</code></pre>
<p>When the input is the same, how can it return 8 different values?</p>
 13866: <p>That code is from <code>src\addrman.cpp</code>. The code's author has in the past <a href="https://bitcointalk.org/index.php?topic=97297.0" rel="nofollow noreferrer">pointed out the associated comments</a> in <a href="https://github.com/bitcoin/bitcoin/blob/master/src/addrman.h#L91" rel="nofollow noreferrer"><code>addrman.h</code></a> starting around line 91</p>
<p>You should refer to the original source but I'll quote the relevant comments here</p>
<p>(<a href="https://opensource.org/licenses/mit-license.php" rel="nofollow noreferrer">https://opensource.org/licenses/mit-license.php</a>)</p>
<p>Stochastic address manager</p>
<p>Design goals:</p>
<ul>
<li>Keep the address tables in-memory, and asynchronously dump the entire table to peers.dat.</li>
<li>Make sure no (localized) attacker can fill the entire table with his nodes/addresses.</li>
</ul>
<p>To that end:</p>
<ul>
<li>Addresses are organized into buckets that can each store up to 64 entries.
<ul>
<li>Addresses to which our node has not successfully connected go into 1024 &quot;new&quot; buckets.
<ul>
<li>Based on the address range (/16 for IPv4) of the source of information, or if an asmap is provided,
the AS it belongs to (for IPv4/IPv6), 64 buckets are selected at random.</li>
<li>The actual bucket is chosen from one of these, based on the range in which the address itself is located.</li>
<li>The position in the bucket is chosen based on the full address.</li>
<li>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.</li>
<li>When adding a new address to an occupied position of a bucket, it will not replace the existing entry
unless that address is also stored in another bucket or it doesn't meet one of several quality criteria
(see IsTerrible for exact criteria).</li>
<li>Addresses of nodes that are known to be accessible go into 256 &quot;tried&quot; buckets.
<ul>
<li>Each address range selects at random 8 of these buckets.</li>
<li>The actual bucket is chosen from one of these, based on the full address.</li>
<li>When adding a new good address to an occupied position of a bucket, a FEELER connection to the
old address is attempted. The old entry is only replaced and moved back to the &quot;new&quot; buckets if this
attempt was unsuccessful.</li>
</ul>
</li>
<li>Bucket selection is based on cryptographic hashing, using a randomly-generated 256-bit key, which should not
be observable by adversaries.</li>
<li>Several indexes are kept for high performance. Setting m_consistency_check_ratio with the -checkaddrman
configuration option will introduce (expensive) consistency checks for the entire data structure.</li>
</ul>
</li>
</ul>
</li>
</ul>
<blockquote>
<p><strong>I don't understand how an entry can map to 8 buckets when the data in the entry is the same.</strong></p>
</blockquote>
<p>To me, the comments suggest that, for tried nodes, the address <em>range</em> (e.g. 99.0/16) selects eight buckets but the whole address (e.g. 99.0.0.55) selects one of those eight.</p>
<p>I've no idea if that helps, but I think it ought to, and if not, someone more knowledgable will probably provide a better answer.</p>
