user131859: In Eclipse Attacks on Bitcoin’s Peer-to-Peer Network 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?

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


new/tried table were introduced in #787. Counter measure 6 in the paper suggested more buckets and was implemented in this commit.


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 and old addresses periodically cleared.


v0.6.0 implemented #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 which replaced BDB managedaddr.dat with flat filepeers.dat. (because AddrMan could read/write it's own serialized data now.)

Design goals for the new/tried table design are mentioned here. I'm not sure what inspired this design though.



131859: <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>
 136416: <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="nofollow noreferrer">introduced</a> in <a href="https://github.com/bitcoin/bitcoin/pull/787" rel="nofollow 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="nofollow 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="nofollow noreferrer">received</a> and old addresses <a href="https://github.com/bitcoin/bitcoin/blob/v0.5.3rc4/src/main.cpp#L2558" rel="nofollow noreferrer">periodically cleared</a>.</li>
</ul>
</li>
<li><p>v0.6.0 implemented <a href="https://github.com/bitcoin/bitcoin/pull/787" rel="nofollow 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="nofollow 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="nofollow noreferrer">here</a>. I'm not sure what inspired this design though.</p>
</li>
</ul>
