No addresses returned by getnodeaddresses RPC call #16990

The issue

I am attempting to use the getnodeaddresses RPC call to return all addresses known by a node in a docker network. I'm using the regtest environment. The RPC call returns an empty array although nodes have been added on the referent node using the add RPC call.

Expected behavior <!--- What behavior did you expect? -->

The getnodeaddresses RPC call should return nodes added via the add RPC call.

Actual behavior <!--- What was the actual behavior (provide screenshots if the issue is GUI-related)? -->

No addresses are returned, i.e., an empty array is returned:

bitcoin-cli -regtest --datadir=/root/.bitcoin/ getnodeaddresses 5
[
]

Reproduction <!--- How reliably can you reproduce the issue, what are the steps to do so? -->

Setup a regtest network of 11 nodes. No mining has been done, and the ~/.bitcoin folder contains only bitcoin.conf with the following content:

[regtest]
regtest=1
server=1
rpcport=8332
port=8333

Connect to the referent node and run the command: bitcoin-cli -regtest --datadir=/root/.bitcoin/ addnode "$p:8333" add where p is the other node address for every node the referent node wants to add.

Run the commands on the referent node:

bitcoin-cli -regtest --datadir=/root/.bitcoin/ getconnectioncount
10

bitcoin-cli -regtest --datadir=/root/.bitcoin/ getpeerinfo       

[
  {
    "id": 2,
    "addr": "10.0.0.3:53378",
     # Cut out part of response
{
    "id": 11,
    "addr": "10.0.0.4:36236",
    "addrbind": "10.0.0.2:8333",
    "services": "000000000000040d",
    "relaytxes": true,
    "lastsend": 1569835448,
    "lastrecv": 1569835448,
    "bytessent": 464,
    "bytesrecv": 488,
    "conntime": 1569835207,
    "timeoffset": 0,
    "pingtime": 0.001063,
    "minping": 0.000456,
    "version": 70015,
    "subver": "/Satoshi:0.18.0/",
    "inbound": true,
    "addnode": false,
    "startingheight": 303,
    "banscore": 0,
    "synced_headers": -1,
    "synced_blocks": -1,
    "inflight": [
    ],
    "whitelisted": false,
    "minfeefilter": 0.00001000,
    "bytessent_per_msg": {
      "feefilter": 32,
      "ping": 96,
      "pong": 96,
      "sendcmpct": 66,
      "sendheaders": 24,
      "verack": 24,
      "version": 126
    },
    "bytesrecv_per_msg": {
      "feefilter": 32,
      "getaddr": 24,
      "ping": 96,
      "pong": 96,
      "sendcmpct": 66,
      "sendheaders": 24,
      "verack": 24,
      "version": 126
    }
  }
]

bitcoin-cli -regtest --datadir=/root/.bitcoin getnodeaddresses 5
[
]

Bitcoin core version <!-- What version of Bitcoin Core are you using, where did you get it (website, self-compiled, etc)? -->

bitcoin-cli -version
Bitcoin Core RPC client version v0.18.0.0-g2472733a24a9364e4c6233ccd04166a26a68cc65
bitcoind -version 
Bitcoin Core Daemon version v0.18.0.0-g2472733a24a9364e4c6233ccd04166a26a68cc65

Installed via the repository ppa:bitcoin/bitcoin

OS<!-- What type of machine are you observing the error on (OS/CPU and disk type)? -->

Docker container info:

lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.3 LTS
Release:	18.04
Codename:	bionic

Host info:

lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.3 LTS
Release:	18.04
Codename:	bionic

cat /proc/cpuinfo  | grep 'name'| uniq
model name	: Intel(R) Core(TM) i7-4600M CPU @ 2.90GHz

1 TB SSD disk

I think RFC 1918 addresses are not considered routable by addrman and thus not added

I think RFC 1918 addresses are not considered routable by addrman and thus not added

I was indeed using 10.0.0.0/16 as the docker network subnet, however changing the subnet to something else, e.g. 11.0.0.0/16 or 161.53.0.0/16 yields the same result.

Furthermore, in a network with the subnet 11.0.0.0/16 containing only two nodes, A and B when I replace the add option with the onetry option, I made an interesting observation:

1. A first mines blocks
2. B is not connected to A and has height set to 0
3. B then connects to A and immediately updates the block height to the one known to B
4. B runs the getnodeaddresses command and still the response is an empty array (same goes for A)

How come the nodes can exchange blocks but seem to not be connected?

How come the nodes can exchange blocks but seem to not be connected?

connection info can be retrieved with getnetworkinfo and getpeerinfo, not getnodeaddresses

changing the subnet to something else, e.g. 11.0.0.0/16 or 161.53.0.0/16 yields the same result.

Don't know about these, but you might want to check IsRoutable https://dev.visucore.com/bitcoin/doxygen/class_c_net_addr.html#a4e3b2fea2a6151c76684b3812df4a5c3

changing the subnet to something else, e.g. 11.0.0.0/16 or 161.53.0.0/16 yields the same result.

Don't know about these, but you might want to check IsRoutable https://dev.visucore.com/bitcoin/doxygen/class_c_net_addr.html#a4e3b2fea2a6151c76684b3812df4a5c3

I tried some debugging with lldb, and have used a subnet 144.217.240.0/24 in my docker setup, which I have derived from the address of bitcoin.sipa.be DNS seed. For example, 144.217.240.5 is declared routable (by IsRoutable), however it is still not returned by getnodeaddresses

How come the nodes can exchange blocks but seem to not be connected?

connection info can be retrieved with getnetworkinfo and getpeerinfo, not getnodeaddresses

Maybe I am misunderstanding the protocol, but shouldn't a node that is actively connected be declared as known and as such returned by getnodeaddresses - seems reasonable to me.

getnodeaddresses is specifically for returning addresses from addrman (the database), which might include addresses of nodes that are currently connected, but generally those sets are not equal.

I tried some debugging with lldb, and have used a subnet 144.217.240.0/24 in my docker setup, which I have derived from the address of bitcoin.sipa.be DNS seed. For example, 144.217.240.5 is declared routable (by IsRoutable), however it is still not returned by getnodeaddresses

Sorry, can't help here. My knowledge ends there.

Is this still an issue with a recent version of Bitcoin Core? If yes, what are the steps to reproduce?

I had the same issue with the latest version (0.20.1).
When I changed the value of consensus.nMinimumChainWork the problem solved.