<blockquote>
<pre><code>2024-02-05 21:16:51.769 [INF] SYNC: Rejected block 0000000000000000000202b00ad6c08ae74632e1355c7919e1b0ef34d6c93361 from 69.4.94.226:8333 (outbound): previous block 00000000000000000002af7f6d56ec5a25f7e8f6772b1c5e0ed6c74af94b7e87 is known to be invalid
</code></pre>
</blockquote>
<p>Looks like the software you use incorrectly implements the Bitcoin consensus rules: it treated block <a href="https://blockstream.info/block/00000000000000000002af7f6d56ec5a25f7e8f6772b1c5e0ed6c74af94b7e87" rel="nofollow noreferrer"><code>00000000000000000002af7f6d56ec5a25f7e8f6772b1c5e0ed6c74af94b7e87</code></a> as invalid although it's perfectly valid.</p>
<p>Alternative Bitcoin clients have tried, and failed, to correctly re-implement Bitcoin consensus rules since its inception. I'd recommend using <a href="https://bitcoincore.org/" rel="nofollow noreferrer">Bitcoin Core</a> instead.</p>

CC BY-SA 4.0
2024-02-06T15:39:23.583Z
Surprisingly forkmonitor didn't detect this: https://forkmonitor.info/nodes/btc.
Antoine Poinsot
CC BY-SA 4.0
2024-02-06T15:57:04.400Z
Maybe just a hardware failure. @r1ky what are you running this node on?
Antoine Poinsot
CC BY-SA 4.0
2024-02-07T04:24:15.320Z
Thanks for your reply sir. I'm running btcd in a Docker container running alpine:3.16.  I'm a bit of a Go nerd so had an initial interest in running btcd since at least I have some hope of understanding the code. I've restarted from scratch and will resist restarting the server as I did in my first kick at the can. Will see if I get stuck on the same block and report back...
r1ky
CC BY-SA 4.0
2024-02-10T16:51:20.780Z
I've now tried both v0.23.3 and v0.24.0. Both exhibit the same behavior. After about 36h of IBD I catch up to the head of chain. And then syncing just stops and block count freezes. As I mentioned earlier - the logs show the same issue:

```
2024-02-10 16:45:43.516 [INF] SYNC: Rejected block 00000000000000000003b3480ed47cd0d435069efcc1eccdbcd84629a9e912ae from 47.63.181.85:8333 (outbound): previous block 00000000000000000001a9931d3181dcad10319187e0b668fc2db0f8dff656c9 is known to be invalid
```
r1ky
CC BY-SA 4.0
2024-02-11T15:27:13.753Z
Weird. I see you've commented on an issue at BTCD. Feel free to edit my answer or add another answer once you've gotten an answer from them. (For the lurkers: https://github.com/btcsuite/btcd/issues/2090).
Antoine Poinsot
CC BY-SA 4.0
2024-02-06T15:33:57.967Z
2024-02-06T15:33:57.967Z
Antoine Poinsot
<p>Newb question. I have just started running btcsuite/btcd. After spending a couple days initializing the blockchain it no longer appears to be writing new blocks. btcctl getblockcount reports 828835 which today (2024-02-05) is about 36 hours behind.</p>
<p>The logs seem to show valid activity</p>
<pre><code>2024-02-05 21:16:48.101 [INF] SYNC: New valid peer 209.222.252.235:30340 (inbound) (/Bitcoin ABC:0.14.6(EB8.0)/)
2024-02-05 21:16:50.996 [INF] SYNC: Lost peer 207.154.205.24:57960 (inbound)
2024-02-05 21:16:50.996 [INF] SYNC: Syncing to block height 829096 from peer 69.4.94.226:8333
2024-02-05 21:16:51.769 [INF] SYNC: Rejected block 0000000000000000000202b00ad6c08ae74632e1355c7919e1b0ef34d6c93361 from 69.4.94.226:8333 (outbound): previous block 00000000000000000002af7f6d56ec5a25f7e8f6772b1c5e0ed6c74af94b7e87 is known to be invalid
2024-02-05 21:16:51.832 [INF] CHAN: Adding orphan block 000000000000000000024ef5fe9fa06e137c4194468485e053b5cbbf54adaec8 with parent 00000000000000000000e0fd16374c0b72e7827b1625bb3f5d4476bf8caafcda
</code></pre>
<p>Checking the database file directory reveals the issue as well:</p>
<pre><code>root@meta-01:/data/btcd-data/data/mainnet/blocks_ffldb# ls -lt  | head
total 533918380
drwxr-xr-x 2 root root   1892352 Feb  5 13:18 metadata
-rw-r--r-- 1 root root 285130543 Feb  3 21:41 000001019.fdb
-rw-r--r-- 1 root root 536651991 Feb  3 21:38 000001018.fdb
-rw-r--r-- 1 root root 536626098 Feb  3 21:33 000001017.fdb
</code></pre>
<p>Anyone know what might be causing this? Is my server off on some dead-end fork? Can I roll the chain back to the &quot;last good block?&quot;</p>

CC BY-SA 4.0
2024-02-16T13:37:15.630Z
Are you running a pruned btcd node? I reported a similar problem with my pruned (monitoring) node in https://github.com/btcsuite/btcd/issues/2121
0xb10c
CC BY-SA 4.0
2024-02-28T17:00:27.260Z
Nope. This happens immediately after a full IBD.
r1ky
<btcd>
btcd stopped updating blocks database for 36 hours
r1ky
# btcd stopped updating blocks database for 36 hours

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

Newb question. I have just started running btcsuite/btcd. After spending a couple days initializing the blockchain it no longer appears to be writing new blocks. btcctl getblockcount reports 828835 which today (2024-02-05) is about 36 hours behind.

The logs seem to show valid activity

```
2024-02-05 21:16:48.101 [INF] SYNC: New valid peer 209.222.252.235:30340 (inbound) (/Bitcoin ABC:0.14.6(EB8.0)/)
2024-02-05 21:16:50.996 [INF] SYNC: Lost peer 207.154.205.24:57960 (inbound)
2024-02-05 21:16:50.996 [INF] SYNC: Syncing to block height 829096 from peer 69.4.94.226:8333
2024-02-05 21:16:51.769 [INF] SYNC: Rejected block 0000000000000000000202b00ad6c08ae74632e1355c7919e1b0ef34d6c93361 from 69.4.94.226:8333 (outbound): previous block 00000000000000000002af7f6d56ec5a25f7e8f6772b1c5e0ed6c74af94b7e87 is known to be invalid
2024-02-05 21:16:51.832 [INF] CHAN: Adding orphan block 000000000000000000024ef5fe9fa06e137c4194468485e053b5cbbf54adaec8 with parent 00000000000000000000e0fd16374c0b72e7827b1625bb3f5d4476bf8caafcda

```

Checking the database file directory reveals the issue as well:

```
root@meta-01:/data/btcd-data/data/mainnet/blocks_ffldb# ls -lt  | head
total 533918380
drwxr-xr-x 2 root root   1892352 Feb  5 13:18 metadata
-rw-r--r-- 1 root root 285130543 Feb  3 21:41 000001019.fdb
-rw-r--r-- 1 root root 536651991 Feb  3 21:38 000001018.fdb
-rw-r--r-- 1 root root 536626098 Feb  3 21:33 000001017.fdb

```

Anyone know what might be causing this? Is my server off on some dead-end fork? Can I roll the chain back to the "last good block?"

**Tags:** btcd

> **Comments:**
> **username_1**: Are you running a pruned btcd node? I reported a similar problem with my pruned (monitoring) node in https://github.com/btcsuite/btcd/issues/2121  
> **username_0**: Nope. This happens immediately after a full IBD.  

---

## 1 answers

### Answer by username_2 on 2024-02-06. Score: 0

> ```
> 2024-02-05 21:16:51.769 [INF] SYNC: Rejected block 0000000000000000000202b00ad6c08ae74632e1355c7919e1b0ef34d6c93361 from 69.4.94.226:8333 (outbound): previous block 00000000000000000002af7f6d56ec5a25f7e8f6772b1c5e0ed6c74af94b7e87 is known to be invalid
>
> ```

Looks like the software you use incorrectly implements the Bitcoin consensus rules: it treated block [`00000000000000000002af7f6d56ec5a25f7e8f6772b1c5e0ed6c74af94b7e87`](https://blockstream.info/block/00000000000000000002af7f6d56ec5a25f7e8f6772b1c5e0ed6c74af94b7e87) as invalid although it's perfectly valid.

Alternative Bitcoin clients have tried, and failed, to correctly re-implement Bitcoin consensus rules since its inception. I'd recommend using [Bitcoin Core](https://bitcoincore.org/) instead.

> **Comments:**
> **username_2**: Surprisingly forkmonitor didn't detect this: https://forkmonitor.info/nodes/btc.  
> **username_2**: Maybe just a hardware failure. @username_0 what are you running this node on?  
> **username_0**: Thanks for your reply sir. I'm running btcd in a Docker container running alpine:3.16.  I'm a bit of a Go nerd so had an initial interest in running btcd since at least I have some hope of understanding the code. I've restarted from scratch and will resist restarting the server as I did in my first kick at the can. Will see if I get stuck on the same block and report back...  
> **username_0**: I've now tried both v0.23.3 and v0.24.0. Both exhibit the same behavior. After about 36h of IBD I catch up to the head of chain. And then syncing just stops and block count freezes. As I mentioned earlier - the logs show the same issue:  ``` 2024-02-10 16:45:43.516 [INF] SYNC: Rejected block 00000000000000000003b3480ed47cd0d435069efcc1eccdbcd84629a9e912ae from 47.63.181.85:8333 (outbound): previous block 00000000000000000001a9931d3181dcad10319187e0b668fc2db0f8dff656c9 is known to be invalid ```  
> **username_2**: Weird. I see you've commented on an issue at BTCD. Feel free to edit my answer or add another answer once you've gotten an answer from them. (For the lurkers: https://github.com/btcsuite/btcd/issues/2090).  

---

