2

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.

3 Answers 3

4

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.

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.

1
  • 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
    Commented Oct 2, 2017 at 20:43
1

Peer 2184 is evidently a Bitcoin Cash node (Bitcoin ABC is a Bitcoin Cash client). It sent you a BCH block 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 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)?

6
  • 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
    Commented Sep 28, 2017 at 3:24
  • 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
    Commented Sep 28, 2017 at 3:49
  • @bladedoyle: I don't really know. Commented Sep 28, 2017 at 3:55
  • 1
    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
    Commented Sep 29, 2017 at 18:11
  • @AndrewChow: I bet you are right. Would you like to add this as another answer? Commented Sep 29, 2017 at 18:12
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.