<p>Peer 2184 is evidently a Bitcoin Cash node (<a href="https://www.bitcoinabc.org/" rel="nofollow noreferrer">Bitcoin ABC</a> is a Bitcoin Cash client).  It sent you a <a href="https://blockchair.com/bitcoin-cash/block/478577" rel="nofollow noreferrer">BCH block</a> which you quite properly rejected because it doesn't fit into the BTC blockchain.  You then disconnected and banned Peer 2184 for sending you an invalid BTC block, which again is understandable.   It looks like it tried to reconnect a few times, perhaps because it didn't know why you had disconnected, and you continued to refuse.  That seems normal.</p>
<p>It's interesting that this node has a 10.* IP address which is <a href="https://www.rfc-editor.org/rfc/rfc1918" rel="nofollow noreferrer">reserved</a> for private networks.  So either this machine is on your (or your organization's) internal network, or something is badly misconfigured.</p>
<p>It's not clear to me what this would have to do with your node appearing as &quot;down&quot;.  Could it be that your node had simply reached its connection limit and therefore refused the probe from bitnodes, even though it continued to be connected to other nodes?  Did you see a lot more log messages about disconnecting from other nodes?  Was there an unusually long gap between receiving new blocks (UpdateTip messages)?</p>

CC BY-SA 3.0
2017-09-28T03:24:15.527Z
The 10. address is because its running in Docker in Kubernetes, so yes in a private subnet, yes behind NAT.  But I have inbound port 8333 mapped through.
bladedoyle
CC BY-SA 3.0
2017-09-28T03:49:01.267Z
Its strange that the connections are from the gateway address?

I continued to fail the probe after restart so im not sure how it could be connection limit.  I'll check that if it happens again.

Is it normal to have 27344 banned connections in 16 hours?
bladedoyle
CC BY-SA 3.0
2017-09-28T03:55:16.757Z
@bladedoyle: I don't really know.
Nate Eldredge
CC BY-SA 3.0
2017-09-29T18:11:01.897Z
It seems like the way that you have it set up is that the gateway is acting as a proxy instead of passing through the connections. Thus Bitcoin Core thinks the connection came from your gateway instead of from where it actually came from. When your node banned the Bitcoin ABC node, it banned your gateway as it thought that was the bad node. This had the effect of then banning everything connected to you because they all connect through that gateway and the gateway was banned. It is fine today because the ban is only for 24 hours.
Ava Chow
CC BY-SA 3.0
2017-09-29T18:12:03.083Z
@AndrewChow: I bet you are right.  Would you like to add this as another answer?
Nate Eldredge
CC BY-SA 3.0
2017-09-29T18:13:55.423Z
I'll add it as an answer.
Ava Chow
CC BY-SA 3.0
2017-09-28T02:38:19.140Z
2017-09-28T02:38:19.140Z
2021-10-07T07:34:52.683Z
Nate Eldredge
<p>It should be possible to set up your NAT so that it is a one-way NAT. i.e. the internet addresses should still show as their original addresses, but 10.32.0.1 will be the default gateway. This way, when the ban happens, it won't ban the gateway itself, but the specific public IP address which correlates to the Bitcoin Cash node.</p>

CC BY-SA 3.0
2017-10-09T22:17:32.420Z
2017-10-09T22:17:32.420Z
Rebroad
<p>As Nate Eldredge said, the block that you received is a Bitcoin Cash block which is invalid to Bitcoin Core. Because of this, your node banned the Bitcoin Cash node that sent you the block. However, it seems like the way that you have your node set up is that the gateway is acting as a proxy instead of passing through the connections. Thus Bitcoin Core thinks the connection came from your gateway instead of from where it actually came from. When your node banned the Bitcoin ABC node, it banned your gateway as it thought that was the bad node. This had the effect of then banning everything connected to you because they all connect through that gateway and the gateway was banned. The connections are back today because the ban is only for 24 hours.</p>

<p>I highly suggest that you make sure that the connections are properly being passed through so that this does not happen in the future. To ensure that they are passed through, if you use <code>getpeerinfo</code> (or the Peers tab of the Debug Window if you are using the GUI) and look at the IP addresses of all of the nodes you are connected to, they should not be the IP address of your gateway.</p>

CC BY-SA 3.0
2017-10-02T20:43:04.837Z
Yes, this appears to correctly describe my situation.  Thanks!

(Though, its not a misconfiguration problem - I believe thats just how these network overlays work.  I'll explore a bit further to try to find a workaround)
bladedoyle
CC BY-SA 3.0
2017-09-29T18:17:26.497Z
2017-09-29T18:17:26.497Z
Ava Chow
<p>Any idea what happened last night that caused my full node to fail with messages like this:   (full log available upon request)</p>
<pre>

2017-09-25 21:15:59 Bitcoin version v0.15.0.1
...

2017-09-25 21:32:33 UpdateTip: new best=00000000000000000079fb649dd2c7e35978bd6d7922b8661c1e3ae597f24191 height=486858 version=0x20000002 log2_work=87.166038 tx=256852323 date='2017-09-25 03:51:56' progress=0.999233 cache=370.8MiB(2762033txo) warning='2 of last 100 blocks have unexpected version'
...
2017-09-26 13:32:19 receive version message: /bitcoin-seeder:0.01/: version 60000, blocks=350000, us=108.196.200.233:8333, peer=2183
2017-09-26 13:32:52 receive version message: /Bitcoin ABC:0.14.4(EB8.0)/: version 70015, blocks=489424, us=108.196.200.233:8333, peer=2184
2017-09-26 13:32:55 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 000000000000000000639be19a0123a1c99d9fef89f0b8ac055a77f4ef86ae3b, bad-diffbits, incorrect proof of work (code 16)
2017-09-26 13:32:55 Misbehaving: 10.32.0.1:55716 peer=2184 (0 -> 100) BAN THRESHOLD EXCEEDED
2017-09-26 13:32:55 ERROR: invalid header received
2017-09-26 13:32:55 ProcessMessages(headers, 162003 bytes) FAILED peer=2184
2017-09-26 13:32:55 connection from 10.32.0.1:46684 dropped (banned)
2017-09-26 13:32:59 connection from 10.32.0.1:47442 dropped (banned)
2017-09-26 13:33:00 connection from 10.32.0.1:50695 dropped (banned)
2017-09-26 13:33:00 connection from 10.32.0.1:49700 dropped (banned)
2017-09-26 13:33:02 connection from 10.32.0.1:15754 dropped (banned)
2017-09-26 13:33:03 connection from 10.32.0.1:47560 dropped (banned)
...
...
</pre>
<p>At this point my node was seen as &quot;down&quot; by <a href="https://bitnodes.21.co/" rel="nofollow noreferrer">https://bitnodes.21.co/</a>
Today, it appears to be working normally again.</p>

<bitcoin-core><peer-discovery><block-validity>
Why was my full node knocked off the network last night?
bladedoyle
# Why was my full node knocked off the network last night?

(Asked by: username_0 on 2017-09-28)

Any idea what happened last night that caused my full node to fail with messages like this: (full log available upon request)

```

2017-09-25 21:15:59 Bitcoin version v0.15.0.1
...

2017-09-25 21:32:33 UpdateTip: new best=00000000000000000079fb649dd2c7e35978bd6d7922b8661c1e3ae597f24191 height=486858 version=0x20000002 log2_work=87.166038 tx=256852323 date='2017-09-25 03:51:56' progress=0.999233 cache=370.8MiB(2762033txo) warning='2 of last 100 blocks have unexpected version'
...
2017-09-26 13:32:19 receive version message: /bitcoin-seeder:0.01/: version 60000, blocks=350000, us=108.196.200.233:8333, peer=2183
2017-09-26 13:32:52 receive version message: /Bitcoin ABC:0.14.4(EB8.0)/: version 70015, blocks=489424, us=108.196.200.233:8333, peer=2184
2017-09-26 13:32:55 ERROR: AcceptBlockHeader: Consensus::ContextualCheckBlockHeader: 000000000000000000639be19a0123a1c99d9fef89f0b8ac055a77f4ef86ae3b, bad-diffbits, incorrect proof of work (code 16)
2017-09-26 13:32:55 Misbehaving: 10.32.0.1:55716 peer=2184 (0 -> 100) BAN THRESHOLD EXCEEDED
2017-09-26 13:32:55 ERROR: invalid header received
2017-09-26 13:32:55 ProcessMessages(headers, 162003 bytes) FAILED peer=2184
2017-09-26 13:32:55 connection from 10.32.0.1:46684 dropped (banned)
2017-09-26 13:32:59 connection from 10.32.0.1:47442 dropped (banned)
2017-09-26 13:33:00 connection from 10.32.0.1:50695 dropped (banned)
2017-09-26 13:33:00 connection from 10.32.0.1:49700 dropped (banned)
2017-09-26 13:33:02 connection from 10.32.0.1:15754 dropped (banned)
2017-09-26 13:33:03 connection from 10.32.0.1:47560 dropped (banned)
...
...

```

At this point my node was seen as "down" by <https://bitnodes.21.co/>
Today, it appears to be working normally again.

**Tags:** bitcoin-core, peer-discovery, block-validity


---

## 3 answers

### Answer by username_2 on 2017-09-29. Score: 4 | Accepted answer

As username_1 username_1 said, the block that you received is a Bitcoin Cash block which is invalid to Bitcoin Core. Because of this, your node banned the Bitcoin Cash node that sent you the block. However, it seems like the way that you have your node set up is that the gateway is acting as a proxy instead of passing through the connections. Thus Bitcoin Core thinks the connection came from your gateway instead of from where it actually came from. When your node banned the Bitcoin ABC node, it banned your gateway as it thought that was the bad node. This had the effect of then banning everything connected to you because they all connect through that gateway and the gateway was banned. The connections are back today because the ban is only for 24 hours.

I highly suggest that you make sure that the connections are properly being passed through so that this does not happen in the future. To ensure that they are passed through, if you use `getpeerinfo` (or the Peers tab of the Debug Window if you are using the GUI) and look at the IP addresses of all of the nodes you are connected to, they should not be the IP address of your gateway.

> **Comments:**
> **username_0**: Yes, this appears to correctly describe my situation.  Thanks!  (Though, its not a misconfiguration problem - I believe thats just how these network overlays work.  I'll explore a bit further to try to find a workaround)  

---

### Answer by username_1 on 2017-09-28. Score: 1

Peer 2184 is evidently a Bitcoin Cash node ([Bitcoin ABC](https://www.bitcoinabc.org/) is a Bitcoin Cash client). It sent you a [BCH block](https://blockchair.com/bitcoin-cash/block/478577) which you quite properly rejected because it doesn't fit into the BTC blockchain. You then disconnected and banned Peer 2184 for sending you an invalid BTC block, which again is understandable. It looks like it tried to reconnect a few times, perhaps because it didn't know why you had disconnected, and you continued to refuse. That seems normal.

It's interesting that this node has a 10.\* IP address which is [reserved](https://www.rfc-editor.org/rfc/rfc1918) for private networks. So either this machine is on your (or your organization's) internal network, or something is badly misconfigured.

It's not clear to me what this would have to do with your node appearing as "down". Could it be that your node had simply reached its connection limit and therefore refused the probe from bitnodes, even though it continued to be connected to other nodes? Did you see a lot more log messages about disconnecting from other nodes? Was there an unusually long gap between receiving new blocks (UpdateTip messages)?

> **Comments:**
> **username_0**: The 10. address is because its running in Docker in Kubernetes, so yes in a private subnet, yes behind NAT.  But I have inbound port 8333 mapped through.  
> **username_0**: Its strange that the connections are from the gateway address?  I continued to fail the probe after restart so im not sure how it could be connection limit.  I'll check that if it happens again.  Is it normal to have 27344 banned connections in 16 hours?  
> **username_1**: @username_0: I don't really know.  
> **username_2**: It seems like the way that you have it set up is that the gateway is acting as a proxy instead of passing through the connections. Thus Bitcoin Core thinks the connection came from your gateway instead of from where it actually came from. When your node banned the Bitcoin ABC node, it banned your gateway as it thought that was the bad node. This had the effect of then banning everything connected to you because they all connect through that gateway and the gateway was banned. It is fine today because the ban is only for 24 hours.  
> **username_1**: @AndrewChow: I bet you are right.  Would you like to add this as another answer?  
> **username_2**: I'll add it as an answer.  

---

### Answer by username_3 on 2017-10-09. Score: 0

It should be possible to set up your NAT so that it is a one-way NAT. i.e. the internet addresses should still show as their original addresses, but 10.32.0.1 will be the default gateway. This way, when the ban happens, it won't ban the gateway itself, but the specific public IP address which correlates to the Bitcoin Cash node.


---

