<p>In case of a collision of addrs in the new table, the existing address will normally stay (and nothing changes) - unless</p>
<ul>
<li>the existing entry is already present somewhere else in the new table (an address can be in up to 8 different buckets/positions at the same time), or</li>
<li>if the existing entry is of bad quality (&quot;terrible&quot;)</li>
</ul>
<p>In these two cases the existing entry will be replaced by the new one.
There are several criteria by which a node can be terrible, roughly:</p>
<ul>
<li>if its timestamp is too far in the future or too far in the past from the current time.</li>
<li>if we unsuccessfully tried to connect to it too often in the past</li>
</ul>
<p>See <a href="https://github.com/bitcoin/bitcoin/blob/aa6fb37accc6445855c81b6b236e574586df9c28/src/addrman.cpp#L67" rel="nofollow noreferrer">Addrman::IsTerrible()</a> for details / exact limits.
It may also be worth to mention that the behavior in case of collisions in the tried table is very different from this (&quot;test before evict&quot;).</p>

CC BY-SA 4.0
2022-10-13T05:23:49.500Z
2022-10-14T19:10:36.340Z
2022-10-14T19:10:36.340Z
Lightlike
<p>What does the bitcoin protocol do to handle collisions when adding addresses to the new table?</p>

CC BY-SA 4.0
2022-10-08T20:26:09.027Z
What addresses and what new table?
Vojtěch Strnad
CC BY-SA 4.0
2022-10-08T20:29:45.110Z
The addresses that are in the addr message are placed into the new table of bitcoin core.
Vinay Shetty
CC BY-SA 4.0
2022-10-08T20:53:24.397Z
Surely addr entries can't collide because there is no expectation that each peer has no peers in common. If two peers report a common addr entry wouldn't you just keep the common value in your table?
RedGrittyBrick
<bitcoin-core><peers><p2p><eclipse-attack>
Collisions when adding an address entry to the new table
Vinay Shetty
# Collisions when adding an address entry to the new table

(Asked by: username_0 on 2022-10-08)

What does the bitcoin protocol do to handle collisions when adding addresses to the new table?

**Tags:** bitcoin-core, peers, p2p, eclipse-attack

> **Comments:**
> **username_1**: What addresses and what new table?  
> **username_0**: The addresses that are in the addr message are placed into the new table of bitcoin core.  
> **username_2**: Surely addr entries can't collide because there is no expectation that each peer has no peers in common. If two peers report a common addr entry wouldn't you just keep the common value in your table?  

---

## 1 answers

### Answer by username_3 on 2022-10-13. Score: 1 | Accepted answer

In case of a collision of addrs in the new table, the existing address will normally stay (and nothing changes) - unless

* the existing entry is already present somewhere else in the new table (an address can be in up to 8 different buckets/positions at the same time), or
* if the existing entry is of bad quality ("terrible")

In these two cases the existing entry will be replaced by the new one.
There are several criteria by which a node can be terrible, roughly:

* if its timestamp is too far in the future or too far in the past from the current time.
* if we unsuccessfully tried to connect to it too often in the past

See [Addrman::IsTerrible()](https://github.com/bitcoin/bitcoin/blob/aa6fb37accc6445855c81b6b236e574586df9c28/src/addrman.cpp#L67) for details / exact limits.
It may also be worth to mention that the behavior in case of collisions in the tried table is very different from this ("test before evict").


---

