bitcoind syncing headers but not blocks

Question

I have bitcoind version 23.0 running on a machine in regtest mode.

I then start another instance on another machine and perform addnode "x.x.x.x:xxxx" "add" to connect to the first instance.

The result: the new instance connects fine, syncs block headers, but not blocks.

getpeerinfo shows:

[
  {
    "id": 0,
<snip>
    "network": "ipv4",
    "services": "0000000000000408",
    "servicesnames": [
      "WITNESS",
      "NETWORK_LIMITED"
    ],
    "relaytxes": true,
    "last_transaction": 0,
    "last_block": 0,
    "bytessent": 1045,
    "bytesrecv": 1329,
    "timeoffset": 0,
    "version": 70016,
    "subver": "/Satoshi:23.0.0/",
    "inbound": false,
    "bip152_hb_to": false,
    "bip152_hb_from": false,
    "startingheight": 110,
    "synced_headers": 110,
    "synced_blocks": -1,
    "inflight": [
    ],
    "addr_relay_enabled": true,
    "addr_processed": 1,
    "addr_rate_limited": 0,
    "permissions": [
    ],
    "minfeefilter": 0.00001000,
<snip>
    "connection_type": "manual"
  }
]

My bitcoin.conf looks like this:

listen=1
server=1
prune=2000
regtest=1
rpcauth=<snip>
port=<snip>
rpcport=18443
rpcbind=127.0.0.1
rpcallowip=127.0.0.1

getblockcount returns 110 on the first machine and 0 on the second, confirming that no blocks were synced.

Why is this happening and how to get block sync going?

Answer 1

A synchronizing node will look for a peer that announces the NODE_NETWORK service flag which indicates that a node has all blocks and can serve them.

Pruned nodes will only ever serve the newest 288 blocks, which is signaled via the NODE_NETWORK_LIMITED service flag. Since pruned nodes tend to not have the earliest blocks (except if there are so few as in your test), a synchronizing node will not request blocks from a pruned node.

As you're running on regtest and your blocks are probably mostly empty anyway, you could mitigate your issue by turning off pruning.

peerbloomfilters turns on support for BIP37 bloom filters, which permits thin clients to request that a full node searches blocks for them and notifies them about relevant transactions. If both of your nodes are full node instances, this feature will not be used and should not impact your success.

Answer 2

Going to answer my own question.

Looks like it is the prune= option that disables the NETWORK service and stops the node from participating in block sync.

After removing it the setup started working as expected, headers and blocks are being synchronized correctly.

In addition, setting peerbloomfilters=1 resulted in connection_type: outbound-full-relay.