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.