<blockquote>
<p>Were the new and tried tables included in bitcoin from the beginning or added at a later date?</p>
</blockquote>
<ul>
<li>new/tried table were <a href="https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/addrman.h#L185-L195" rel="noreferrer">introduced</a> in <a href="https://github.com/bitcoin/bitcoin/pull/787" rel="noreferrer">#787</a>. Counter measure 6 in the paper suggested more buckets and was implemented in <a href="https://github.com/bitcoin/bitcoin/commit/1d21ba2f5ecbf03086d0b65c4c4c80a39a94c2ee" rel="noreferrer">this commit</a>.</li>
</ul>
<blockquote>
<p>What inspired the design of the address sharing mechanism between full nodes? / What is the &quot;Related Work&quot; for this design?</p>
</blockquote>
<ul>
<li><p>addresses in the earlier clients (before v0.6.0) were directly stored inside BDB managed <code>addr.dat</code>.</p>
<ul>
<li>simple implementation wherein new addresses were added into <code>addr.dat</code> when <code>ADDR</code> message was <a href="https://github.com/bitcoin/bitcoin/blob/v0.5.3rc4/src/main.cpp#L2005-L2050" rel="noreferrer">received</a> and old addresses <a href="https://github.com/bitcoin/bitcoin/blob/v0.5.3rc4/src/main.cpp#L2558" rel="noreferrer">periodically cleared</a>.</li>
</ul>
</li>
<li><p>v0.6.0 implemented <a href="https://github.com/bitcoin/bitcoin/pull/787" rel="noreferrer">#787</a> which introduced the address manager/<code>AddrMan</code> along with new and tried tables for better control/management of peer addresses.</p>
</li>
<li><p>v0.7.0 implemented <a href="https://github.com/bitcoin/bitcoin/pull/1198" rel="noreferrer">#1198</a> which replaced BDB managed<code>addr.dat</code> with flat file<code>peers.dat</code>. (because <code>AddrMan</code> could read/write it's own serialized data now.)</p>
</li>
<li><p>Design goals for the new/tried table design are mentioned <a href="https://github.com/bitcoin/bitcoin/blob/ffc22b7d42c6360223508293b8c1f88b1a1a468b/src/addrman.h#L57-L85" rel="noreferrer">here</a>. I'm not sure what inspired this design though.</p>
</li>
</ul>

CC BY-SA 4.0
2023-01-26T18:53:47.473Z
2023-01-26T18:53:47.473Z
stratospher
<p>In <a href="https://eprint.iacr.org/2015/263.pdf" rel="nofollow noreferrer">Eclipse Attacks on Bitcoin’s Peer-to-Peer Network</a> section 8 Related Work, the authors describe how some of the countermeasures to eclipse attacks were inspired by botnets. What inspired the design of the address sharing mechanism between full nodes? Were the new and tried tables included in bitcoin from the beginning or added at a later date? What is the &quot;Related Work&quot; for this design?</p>

<network><attack><peers><peer-discovery><eclipse-attack>
What is the prior work or inspiration for the new/tried table design?
vnprc
# What is the prior work or inspiration for the new/tried table design?

(Asked by: username_0 on 2022-02-04)

In [Eclipse Attacks on Bitcoin’s Peer-to-Peer Network](https://eprint.iacr.org/2015/263.pdf) section 8 Related Work, the authors describe how some of the countermeasures to eclipse attacks were inspired by botnets. What inspired the design of the address sharing mechanism between full nodes? Were the new and tried tables included in bitcoin from the beginning or added at a later date? What is the "Related Work" for this design?

**Tags:** network, attack, peers, peer-discovery, eclipse-attack


---

## 1 answers

### Answer by username_1 on 2023-01-26. Score: 5

> Were the new and tried tables included in bitcoin from the beginning or added at a later date?

* new/tried table were [introduced](https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/addrman.h#L185-L195) in [#787](https://github.com/bitcoin/bitcoin/pull/787). Counter measure 6 in the paper suggested more buckets and was implemented in [this commit](https://github.com/bitcoin/bitcoin/commit/1d21ba2f5ecbf03086d0b65c4c4c80a39a94c2ee).

> What inspired the design of the address sharing mechanism between full nodes? / What is the "Related Work" for this design?

* addresses in the earlier clients (before v0.6.0) were directly stored inside BDB managed `addr.dat`.

  + simple implementation wherein new addresses were added into `addr.dat` when `ADDR` message was [received](https://github.com/bitcoin/bitcoin/blob/v0.5.3rc4/src/main.cpp#L2005-L2050) and old addresses [periodically cleared](https://github.com/bitcoin/bitcoin/blob/v0.5.3rc4/src/main.cpp#L2558).
* v0.6.0 implemented [#787](https://github.com/bitcoin/bitcoin/pull/787) which introduced the address manager/`AddrMan` along with new and tried tables for better control/management of peer addresses.
* v0.7.0 implemented [#1198](https://github.com/bitcoin/bitcoin/pull/1198) which replaced BDB managed`addr.dat` with flat file`peers.dat`. (because `AddrMan` could read/write it's own serialized data now.)
* Design goals for the new/tried table design are mentioned [here](https://github.com/bitcoin/bitcoin/blob/ffc22b7d42c6360223508293b8c1f88b1a1a468b/src/addrman.h#L57-L85). I'm not sure what inspired this design though.


---

