<p>A synchronizing node will look for a peer that announces the <code>NODE_NETWORK</code> service flag which indicates that a node has all blocks and can serve them.</p>
<p>Pruned nodes will only ever serve the newest 288 blocks, which is signaled via the <code>NODE_NETWORK_LIMITED</code> 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.</p>
<p>As you're running on regtest and your blocks are probably mostly empty anyway, you could mitigate your issue by turning off pruning.</p>
<p><code>peerbloomfilters</code> 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.</p>

CC BY-SA 4.0
2022-08-05T20:18:09.057Z
2022-08-05T20:18:09.057Z
Murch
<p>Going to answer my own question.</p>
<p>Looks like it is the <code>prune=</code> option that disables the <code>NETWORK</code> service and stops the node from participating in block sync.</p>
<p>After removing it the setup started working as expected, headers and blocks are being synchronized correctly.</p>
<p>In addition, setting <code>peerbloomfilters=1</code> resulted in <code>connection_type: outbound-full-relay</code>.</p>

CC BY-SA 4.0
2022-08-05T19:18:42.563Z
2022-08-05T19:18:42.563Z
rustyx
<p>I have <code>bitcoind</code> version 23.0 running on a machine in <code>regtest</code> mode.</p>
<p>I then start another instance on another machine and perform <code>addnode &quot;x.x.x.x:xxxx&quot; &quot;add&quot;</code> to connect to the first instance.</p>
<p>The result: the new instance connects fine, syncs block headers, but not blocks.</p>
<p><code>getpeerinfo</code> shows:</p>
<pre><code>[
  {
    &quot;id&quot;: 0,
&lt;snip&gt;
    &quot;network&quot;: &quot;ipv4&quot;,
    &quot;services&quot;: &quot;0000000000000408&quot;,
    &quot;servicesnames&quot;: [
      &quot;WITNESS&quot;,
      &quot;NETWORK_LIMITED&quot;
    ],
    &quot;relaytxes&quot;: true,
    &quot;last_transaction&quot;: 0,
    &quot;last_block&quot;: 0,
    &quot;bytessent&quot;: 1045,
    &quot;bytesrecv&quot;: 1329,
    &quot;timeoffset&quot;: 0,
    &quot;version&quot;: 70016,
    &quot;subver&quot;: &quot;/Satoshi:23.0.0/&quot;,
    &quot;inbound&quot;: false,
    &quot;bip152_hb_to&quot;: false,
    &quot;bip152_hb_from&quot;: false,
    &quot;startingheight&quot;: 110,
    &quot;synced_headers&quot;: 110,
    &quot;synced_blocks&quot;: -1,
    &quot;inflight&quot;: [
    ],
    &quot;addr_relay_enabled&quot;: true,
    &quot;addr_processed&quot;: 1,
    &quot;addr_rate_limited&quot;: 0,
    &quot;permissions&quot;: [
    ],
    &quot;minfeefilter&quot;: 0.00001000,
&lt;snip&gt;
    &quot;connection_type&quot;: &quot;manual&quot;
  }
]
</code></pre>
<p>My <code>bitcoin.conf</code> looks like this:</p>
<pre><code>listen=1
server=1
prune=2000
regtest=1
rpcauth=&lt;snip&gt;
port=&lt;snip&gt;
rpcport=18443
rpcbind=127.0.0.1
rpcallowip=127.0.0.1
</code></pre>
<p><code>getblockcount</code> returns <code>110</code> on the first machine and <code>0</code> on the second, confirming that no blocks were synced.</p>
<p>Why is this happening and how to get block sync going?</p>

<bitcoin-core><bitcoind>
bitcoind syncing headers but not blocks
rustyx
# bitcoind syncing headers but not blocks

(Asked by: username_0 on 2022-08-05)

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?

**Tags:** bitcoin-core, bitcoind


---

## 2 answers

### Answer by username_1 on 2022-08-05. Score: 2 | Accepted answer

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 by username_0 on 2022-08-05. Score: 1

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`.


---

