<p>It sounds like your hard drive was either experiencing a Read/Write failure (which can especially happen with SD cards after some time, or with external drives attached via USB), or your disk ran out of space during the synchronization. If you check the <code>debug.log</code>, you may find an error message with the rejection reason.</p>
<p>Either of these may lead to a Bitcoin Core node incorrectly classifying a block in the best chain as invalid. In this case, you can confirm that this is a mistake by checking the block hash</p>
<pre class="lang-json prettyprint-override"><code>    ...
    {
        &quot;height&quot;: 854868,
        &quot;hash&quot;: &quot;00000000000000000000d04c6def5cb8d3806ba47cd358a3c8bfdc7424d37a63&quot;,
         &quot;branchlen&quot;: 1,
         &quot;status&quot;: &quot;invalid&quot;   
    },
    ...
</code></pre>
<p>on another synced node or some block explorers which will indicate that the block is in fact valid and part of the best chain.</p>
<p>Once you have resolved the underlying issue (e.g. moved the bitcoin directory to a new/larger drive, or turned on pruning), you can instruct your node to take another stab at processing the best chain with the following procedure:</p>
<ol>
<li>Identify the predecessor block of the one incorrectly classified as invalid. Use this block’s hash to…</li>
<li>Call the hidden RPC <code>invalidateblock &lt;predecessor_block_hash&gt;</code></li>
<li>Call the hidden RPC <code>reconsiderblock &lt;predecessor_block_hash&gt;</code></li>
</ol>
<p>This should first make your node disregard the best chain and then process it as if it were seeing it for the first time. Given that the &quot;invalid&quot; block was a successor of the invalidated block, it should be reprocessed.</p>

CC BY-SA 4.0
2024-08-05T14:00:15.010Z
2024-08-06T17:50:32.547Z
2024-08-06T17:50:32.547Z
Murch
<p>My bitcoind of version 26.0.0 is stuck at a block roughly from August 1st:</p>
<p><code>bitcoin-cli getblockchaininfo</code>:</p>
<pre class="lang-json prettyprint-override"><code>{
  &quot;chain&quot;: &quot;main&quot;,
  &quot;blocks&quot;: 854867,
  &quot;headers&quot;: 854867,
  &quot;bestblockhash&quot;: &quot;00000000000000000002306fe4af061811447ce308b916432f7908d87daa2cd3&quot;,
  &quot;difficulty&quot;: 90666502495565.78,
  &quot;time&quot;: 1722468412,
  &quot;mediantime&quot;: 1722462709,
  &quot;verificationprogress&quot;: 0.9979858958925993,
  &quot;initialblockdownload&quot;: true,
  &quot;chainwork&quot;: &quot;0000000000000000000000000000000000000000867fc2389d22c1af602d8818&quot;,
  &quot;size_on_disk&quot;: 4020692120,
  &quot;pruned&quot;: true,
  &quot;pruneheight&quot;: 852759,
  &quot;automatic_pruning&quot;: true,
  &quot;prune_target_size&quot;: 4194304000,
  &quot;warnings&quot;: &quot;&quot;
}
</code></pre>
<p>even though it is connected to plenty peers that have a fresh view of the chain:</p>
<p><code>bitcoin-cli getpeerinfo</code>:</p>
<pre class="lang-json prettyprint-override"><code>[
  {
    ...
    &quot;startingheight&quot;: 855489,
    ...
  },
  ...
]
</code></pre>
<p>The output of <code>bitcoin-cli getchaintips</code>:</p>
<pre class="lang-json prettyprint-override"><code>[
  {
    &quot;height&quot;: 854868,
    &quot;hash&quot;: &quot;00000000000000000000d04c6def5cb8d3806ba47cd358a3c8bfdc7424d37a63&quot;,
    &quot;branchlen&quot;: 1,
    &quot;status&quot;: &quot;invalid&quot;
  },
  {
    &quot;height&quot;: 854867,
    &quot;hash&quot;: &quot;00000000000000000002306fe4af061811447ce308b916432f7908d87daa2cd3&quot;,
    &quot;branchlen&quot;: 0,
    &quot;status&quot;: &quot;active&quot;
  },
  {
    &quot;height&quot;: 853185,
    &quot;hash&quot;: &quot;0000000000000000000026c0346042277e9a464778417b70c81334d98d617fd9&quot;,
    &quot;branchlen&quot;: 1,
    &quot;status&quot;: &quot;valid-headers&quot;
  },
  {
    &quot;height&quot;: 853120,
    &quot;hash&quot;: &quot;000000000000000000019066a8be0724175e18539db741579622738f1ce1f2ee&quot;,
    &quot;branchlen&quot;: 1,
    &quot;status&quot;: &quot;valid-fork&quot;
  },
  {
    &quot;height&quot;: 853051,
    &quot;hash&quot;: &quot;000000000000000000007ad9be842fdb143133a8e5353627473006f94bcc086b&quot;,
    &quot;branchlen&quot;: 1,
    &quot;status&quot;: &quot;valid-fork&quot;
  },
  {
    &quot;height&quot;: 851248,
    &quot;hash&quot;: &quot;00000000000000000001b302a79f8db40c150cdbaccaf43666b1ecfac9560a69&quot;,
    &quot;branchlen&quot;: 1,
    &quot;status&quot;: &quot;valid-headers&quot;
  },
  {
    &quot;height&quot;: 849233,
    &quot;hash&quot;: &quot;0000000000000000000020ea4b48f075a066131024c242b6f83eb20724c642d1&quot;,
    &quot;branchlen&quot;: 1,
    &quot;status&quot;: &quot;valid-fork&quot;
  },
  {
    &quot;height&quot;: 848968,
    &quot;hash&quot;: &quot;000000000000000000006aade64c55965be1542f138da658dcdb93005e5c486b&quot;,
    &quot;branchlen&quot;: 1,
    &quot;status&quot;: &quot;valid-headers&quot;
  },
  {
    &quot;height&quot;: 848860,
    &quot;hash&quot;: &quot;000000000000000000003f620e65976fc1768e6f81705cc7fdf25cfcb421825a&quot;,
    &quot;branchlen&quot;: 1,
    &quot;status&quot;: &quot;valid-fork&quot;
  },
  {
    &quot;height&quot;: 848477,
    &quot;hash&quot;: &quot;00000000000000000002ad15f6680bf74febab1020128641fab0da4bdfa5b4bd&quot;,
    &quot;branchlen&quot;: 1,
    &quot;status&quot;: &quot;valid-fork&quot;
  },
  {
    &quot;height&quot;: 847849,
    &quot;hash&quot;: &quot;0000000000000000000327cda2d3d99ac20342aaaa6986837fbfa8903a7b2196&quot;,
    &quot;branchlen&quot;: 1,
    &quot;status&quot;: &quot;valid-fork&quot;
  },
  {
    &quot;height&quot;: 845627,
    &quot;hash&quot;: &quot;0000000000000000000011018adf88550ea5d3e90ed0cfba89976aebc4e7f098&quot;,
    &quot;branchlen&quot;: 1,
    &quot;status&quot;: &quot;valid-headers&quot;
  },
  {
    &quot;height&quot;: 841424,
    &quot;hash&quot;: &quot;000000000000000000010998fc2714f8ae10ffb73f1986eecc58f5afc457ee07&quot;,
    &quot;branchlen&quot;: 1,
    &quot;status&quot;: &quot;valid-headers&quot;
  },
  {
    &quot;height&quot;: 838792,
    &quot;hash&quot;: &quot;00000000000000000002af7214c8796e102b0e9074a5d469266d7afe5af2f087&quot;,
    &quot;branchlen&quot;: 1,
    &quot;status&quot;: &quot;valid-headers&quot;
  }
]
</code></pre>
<p>However, it is not fetching any new blocks. No other <code>debug.log</code> jumps out as unusual.</p>

CC BY-SA 4.0
2024-08-05T10:47:11.257Z
The block 854868 your node says is invalid is actually perfectly valid. Do you have the debug.log line where the rejection reason is logged?
Vojtěch Strnad
CC BY-SA 4.0
2024-08-05T11:34:47.233Z
Smells like hardware failure. Since this is a recurring question on this site, and this question is particularly well formatted we could post an answer here and refer any future similar issue to this question.
Antoine Poinsot
CC BY-SA 4.0
2024-08-05T11:43:25.273Z
It was due to a full disk :/

Looks like I ended up with corrupt block data on the disk. What is the correct approach here? `invalidateblock` doesn't seem to be it because the hash is correct.
Dominik Spicher
<bitcoin-core><synchronization><full-node><block-validity>
bitcoind not downloading any new blocks
Dominik Spicher
# bitcoind not downloading any new blocks

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

My bitcoind of version 26.0.0 is stuck at a block roughly from August 1st:

`bitcoin-cli getblockchaininfo`:

```json
{
  "chain": "main",
  "blocks": 854867,
  "headers": 854867,
  "bestblockhash": "00000000000000000002306fe4af061811447ce308b916432f7908d87daa2cd3",
  "difficulty": 90666502495565.78,
  "time": 1722468412,
  "mediantime": 1722462709,
  "verificationprogress": 0.9979858958925993,
  "initialblockdownload": true,
  "chainwork": "0000000000000000000000000000000000000000867fc2389d22c1af602d8818",
  "size_on_disk": 4020692120,
  "pruned": true,
  "pruneheight": 852759,
  "automatic_pruning": true,
  "prune_target_size": 4194304000,
  "warnings": ""
}

```

even though it is connected to plenty peers that have a fresh view of the chain:

`bitcoin-cli getpeerinfo`:

```json
[
  {
    ...
    "startingheight": 855489,
    ...
  },
  ...
]

```

The output of `bitcoin-cli getchaintips`:

```json
[
  {
    "height": 854868,
    "hash": "00000000000000000000d04c6def5cb8d3806ba47cd358a3c8bfdc7424d37a63",
    "branchlen": 1,
    "status": "invalid"
  },
  {
    "height": 854867,
    "hash": "00000000000000000002306fe4af061811447ce308b916432f7908d87daa2cd3",
    "branchlen": 0,
    "status": "active"
  },
  {
    "height": 853185,
    "hash": "0000000000000000000026c0346042277e9a464778417b70c81334d98d617fd9",
    "branchlen": 1,
    "status": "valid-headers"
  },
  {
    "height": 853120,
    "hash": "000000000000000000019066a8be0724175e18539db741579622738f1ce1f2ee",
    "branchlen": 1,
    "status": "valid-fork"
  },
  {
    "height": 853051,
    "hash": "000000000000000000007ad9be842fdb143133a8e5353627473006f94bcc086b",
    "branchlen": 1,
    "status": "valid-fork"
  },
  {
    "height": 851248,
    "hash": "00000000000000000001b302a79f8db40c150cdbaccaf43666b1ecfac9560a69",
    "branchlen": 1,
    "status": "valid-headers"
  },
  {
    "height": 849233,
    "hash": "0000000000000000000020ea4b48f075a066131024c242b6f83eb20724c642d1",
    "branchlen": 1,
    "status": "valid-fork"
  },
  {
    "height": 848968,
    "hash": "000000000000000000006aade64c55965be1542f138da658dcdb93005e5c486b",
    "branchlen": 1,
    "status": "valid-headers"
  },
  {
    "height": 848860,
    "hash": "000000000000000000003f620e65976fc1768e6f81705cc7fdf25cfcb421825a",
    "branchlen": 1,
    "status": "valid-fork"
  },
  {
    "height": 848477,
    "hash": "00000000000000000002ad15f6680bf74febab1020128641fab0da4bdfa5b4bd",
    "branchlen": 1,
    "status": "valid-fork"
  },
  {
    "height": 847849,
    "hash": "0000000000000000000327cda2d3d99ac20342aaaa6986837fbfa8903a7b2196",
    "branchlen": 1,
    "status": "valid-fork"
  },
  {
    "height": 845627,
    "hash": "0000000000000000000011018adf88550ea5d3e90ed0cfba89976aebc4e7f098",
    "branchlen": 1,
    "status": "valid-headers"
  },
  {
    "height": 841424,
    "hash": "000000000000000000010998fc2714f8ae10ffb73f1986eecc58f5afc457ee07",
    "branchlen": 1,
    "status": "valid-headers"
  },
  {
    "height": 838792,
    "hash": "00000000000000000002af7214c8796e102b0e9074a5d469266d7afe5af2f087",
    "branchlen": 1,
    "status": "valid-headers"
  }
]

```

However, it is not fetching any new blocks. No other `debug.log` jumps out as unusual.

**Tags:** bitcoin-core, synchronization, full-node, block-validity

> **Comments:**
> **username_1**: The block 854868 your node says is invalid is actually perfectly valid. Do you have the debug.log line where the rejection reason is logged?  
> **username_2**: Smells like hardware failure. Since this is a recurring question on this site, and this question is particularly well formatted we could post an answer here and refer any future similar issue to this question.  
> **username_0**: It was due to a full disk :/  Looks like I ended up with corrupt block data on the disk. What is the correct approach here? `invalidateblock` doesn't seem to be it because the hash is correct.  

---

## 1 answers

### Answer by username_3 on 2024-08-05. Score: 0 | Accepted answer

It sounds like your hard drive was either experiencing a Read/Write failure (which can especially happen with SD cards after some time, or with external drives attached via USB), or your disk ran out of space during the synchronization. If you check the `debug.log`, you may find an error message with the rejection reason.

Either of these may lead to a Bitcoin Core node incorrectly classifying a block in the best chain as invalid. In this case, you can confirm that this is a mistake by checking the block hash

```json
    ...
    {
        "height": 854868,
        "hash": "00000000000000000000d04c6def5cb8d3806ba47cd358a3c8bfdc7424d37a63",
         "branchlen": 1,
         "status": "invalid"   
    },
    ...

```

on another synced node or some block explorers which will indicate that the block is in fact valid and part of the best chain.

Once you have resolved the underlying issue (e.g. moved the bitcoin directory to a new/larger drive, or turned on pruning), you can instruct your node to take another stab at processing the best chain with the following procedure:

1. Identify the predecessor block of the one incorrectly classified as invalid. Use this block’s hash to…
2. Call the hidden RPC `invalidateblock <predecessor_block_hash>`
3. Call the hidden RPC `reconsiderblock <predecessor_block_hash>`

This should first make your node disregard the best chain and then process it as if it were seeing it for the first time. Given that the "invalid" block was a successor of the invalidated block, it should be reprocessed.


---

