<p>Bitcoin Core does not immediately broadcast a new <code>addr</code> message to nodes with each new connection it gets. On average, those broadcasts are every 30 seconds, but they could happen sooner or later than that as the delay follows a Poisson distribution. You should wait a few minutes before checking again. Furthermore, just because they know about the address does not mean that the nodes will actually choose to connect to them.</p>

CC BY-SA 3.0
2018-02-03T09:07:52.453Z
What are the checks a node does to 'choose' to connect to another node, or is it entirely random? I think it has something to do with both the protection against the sybil attack (https://en.bitcoin.it/wiki/Weaknesses) as well as the fact that not all addresses have a valid timestamp (https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery). 

However, I tried giving the nodes a different /16 address, and the issue remains (even after 30 minutes of waiting).
Michael
CC BY-SA 3.0
2018-02-03T17:19:18.477Z
The nodes are selected randomly and must not meet the conditions checked here: https://github.com/bitcoin/bitcoin/blob/master/src/addrman.cpp#L33
Ava Chow
CC BY-SA 3.0
2018-02-04T09:54:24.693Z
Interesting, this led me to information about the Eclipse attack.  https://medium.com/mit-security-seminar/eclipse-attacks-on-bitcoin-s-peer-to-peer-network-e0da797302c2 and https://eprint.iacr.org/2015/263.pdf provide more detail. It seems it's not that easy to test peer discovery after all.
Michael
CC BY-SA 3.0
2018-02-03T01:20:35.813Z
2018-02-03T01:20:35.813Z
Ava Chow
<p>I want to test peer discovery in regtest mode of bitcoin core, running in Docker. 
However, I noticed in the source code of bitcoin core that there is a check if the address is routable before answering to a getaddr message. So I first create a network with routable addresses (IsRFC6598):</p>

<pre><code>docker network create -d bridge --subnet 100.64.0.0/10 bridge_sharedrange
</code></pre>

<p>Then I launch four Docker machines with bitcoind installed (and using the bridge_sharedrange network, with different /16 addresses). The bitcoin daemon is then started in all of these four machines with:</p>

<pre><code>bitcoind -regtest -daemon
</code></pre>

<p>Running ifconfig on these nodes show that they are running on 100.64.0.2, 100.65.0.2, 100.66.0.2, 100.67.0.2. From the first machine (100.64.0.2) I then execute the command:</p>

<pre><code>bitcoin-cli addnode 100.65.0.2 add
</code></pre>

<p>From the third machine (100.66.0.2) I then execute the command:</p>

<pre><code>bitcoin-cli addnode 100.65.0.2 add
</code></pre>

<p>So basically, the node with address 100.65.0.2 now has two peers (checked with bitcoin-cli getpeerinfo). I would expect now that </p>

<ul>
<li>100.64.0.2 learned about 100.66.0.2 &amp;</li>
<li>100.66.0.2 learned about 100.64.0.2</li>
</ul>

<p>But that is not the case. They only know 100.65.0.2. Is this normal behaviour? I read on <a href="https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery#Command_Line_Provided_Addresses" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery#Command_Line_Provided_Addresses</a> that it might have to do with the timestamp of the addr, but I'm not certian this can be the cause, and how can circumvent that.</p>

<p>BTW, I also tested with</p>

<pre><code>bitcoind -regtest -daemon -discover=1
</code></pre>

<hr>

<p><strong>Update</strong>: It seems this feature of discovering local LAN nodes is under discussion: <a href="https://github.com/bitcoin/bitcoin/issues/3802" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/issues/3802</a> , however I would think that the WAN rules apply to my situation, as I use RFC6598 addresses in my test set-up.</p>

<bitcoind><network><regtest>
Regtest automated peer discovery
Michael
# Regtest automated peer discovery

(Asked by: username_0 on 2018-02-02)

I want to test peer discovery in regtest mode of bitcoin core, running in Docker. 
However, I noticed in the source code of bitcoin core that there is a check if the address is routable before answering to a getaddr message. So I first create a network with routable addresses (IsRFC6598):
docker network create -d bridge --subnet 100.64.0.0/10 bridge_sharedrange

Then I launch four Docker machines with bitcoind installed (and using the bridge_sharedrange network, with different /16 addresses). The bitcoin daemon is then started in all of these four machines with:
bitcoind -regtest -daemon

Running ifconfig on these nodes show that they are running on 100.64.0.2, 100.65.0.2, 100.66.0.2, 100.67.0.2. From the first machine (100.64.0.2) I then execute the command:
bitcoin-cli addnode 100.65.0.2 add

From the third machine (100.66.0.2) I then execute the command:
bitcoin-cli addnode 100.65.0.2 add

So basically, the node with address 100.65.0.2 now has two peers (checked with bitcoin-cli getpeerinfo). I would expect now that 

100.64.0.2 learned about 100.66.0.2 &
100.66.0.2 learned about 100.64.0.2

But that is not the case. They only know 100.65.0.2. Is this normal behaviour? I read on https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery#Command_Line_Provided_Addresses that it might have to do with the timestamp of the addr, but I'm not certian this can be the cause, and how can circumvent that.
BTW, I also tested with
bitcoind -regtest -daemon -discover=1


Update: It seems this feature of discovering local LAN nodes is under discussion: https://github.com/bitcoin/bitcoin/issues/3802 , however I would think that the WAN rules apply to my situation, as I use RFC6598 addresses in my test set-up.

**Tags:** bitcoind, network, regtest


---

## 1 answers

### Answer by username_1 on 2018-02-03. Score: 1 | Accepted answer

Bitcoin Core does not immediately broadcast a new `addr` message to nodes with each new connection it gets. On average, those broadcasts are every 30 seconds, but they could happen sooner or later than that as the delay follows a Poisson distribution. You should wait a few minutes before checking again. Furthermore, just because they know about the address does not mean that the nodes will actually choose to connect to them.

> **Comments:**
> **username_0**: What are the checks a node does to 'choose' to connect to another node, or is it entirely random? I think it has something to do with both the protection against the sybil attack (https://en.bitcoin.it/wiki/Weaknesses) as well as the fact that not all addresses have a valid timestamp (https://en.bitcoin.it/wiki/Satoshi_Client_Node_Discovery).   However, I tried giving the nodes a different /16 address, and the issue remains (even after 30 minutes of waiting).  
> **username_1**: The nodes are selected randomly and must not meet the conditions checked here: https://github.com/bitcoin/bitcoin/blob/master/src/addrman.cpp#L33  
> **username_0**: Interesting, this led me to information about the Eclipse attack.  https://medium.com/mit-security-seminar/eclipse-attacks-on-bitcoin-s-peer-to-peer-network-e0da797302c2 and https://eprint.iacr.org/2015/263.pdf provide more detail. It seems it's not that easy to test peer discovery after all.  

---

