Node not downloading recent blocks

Question

So I have 4 nodes, all connected to each other.

After doing some testing, i turns out that one of my node is simply not updating its blockchain anymore. It has the three other nodes as peers, the lastrecv timestamp in getpeerinfo is from a few seconds ago, but the last block height is at 1396 while the rest of the chain is at 1410.

Is this a known bug, and if yes is there a fix for it ?

Comments

Thanks for reporting this. We'd love your help in debugging it. If you're willing, can you please:

(a) tell us which version you are on
(b) post the full output of getpeerinfo on the node which is not downloading
(c) confirm if all the nodes agree on the hash of block 1396
(d) stop and restart the node stuck on block 1396
(e) if that does not help, and you're using beta 2, downgrade to beta 1 for that node and see if the problem still persists

Thank you in advance for any assistance.

---

I am using the 1.0 beta 2
The output of getpeerinfo on this node is as such, the last element being the master :
`[
    {
        "id" : 3,
        "addr" : "10.0.0.5:6301",
        "addrlocal" : "10.0.0.7:38828",
        "services" : "0000000000000001",
        "lastsend" : 1499678045,
        "lastrecv" : 1499678045,
        "bytessent" : 22144,
        "bytesrecv" : 22144,
        "conntime" : 1499674832,
        "pingtime" : 0.04861200,
        "version" : 70002,
        "subver" : "/MultiChain:0.1.0.8/",
        "handshakelocal" : "1DHh8XMT9hwXGscX2Lz7u7FFQUBR6SorX3eP4B",
        "handshake" : "1nwnNHZSB1cvUepxzfY41oxTQJREuL3gkzkYC",
        "inbound" : false,
        "startingheight" : 1398,
        "banscore" : 0,
        "synced_headers" : -1,
        "synced_blocks" : -1,
        "inflight" : [
        ],
        "whitelisted" : false
    },
    {
        "id" : 951,
        "addr" : "10.0.0.6:44164",
        "addrlocal" : "10.0.0.7:6301",
        "services" : "0000000000000001",
        "lastsend" : 1499678041,
        "lastrecv" : 1499678041,
        "bytessent" : 17443,
        "bytesrecv" : 17148,
        "conntime" : 1499675465,
        "pingtime" : 0.03735100,
        "version" : 70002,
        "subver" : "/MultiChain:0.1.0.8/",
        "handshakelocal" : "1DHh8XMT9hwXGscX2Lz7u7FFQUBR6SorX3eP4B",
        "handshake" : "1YzzXBboUWUGBzSaUfXJw8FVqZNr6Gc27h1LmL",
        "inbound" : true,
        "startingheight" : 1407,
        "banscore" : 0,
        "synced_headers" : -1,
        "synced_blocks" : -1,
        "inflight" : [
        ],
        "whitelisted" : false
    },
    {
        "id" : 1967,
        "addr" : "10.0.0.4:6301",
        "addrlocal" : "10.0.0.7:49066",
        "services" : "0000000000000001",
        "lastsend" : 1499678044,
        "lastrecv" : 1499678044,
        "bytessent" : 11972,
        "bytesrecv" : 11676,
        "conntime" : 1499676330,
        "pingtime" : 0.03496200,
        "version" : 70002,
        "subver" : "/MultiChain:0.1.0.8/",
        "handshakelocal" : "1DHh8XMT9hwXGscX2Lz7u7FFQUBR6SorX3eP4B",
        "handshake" : "1UVGcNoBizeeVyTXuxQpwK8NpD1p1ZtPbnLRks",
        "inbound" : false,
        "startingheight" : 1410,
        "banscore" : 0,
        "synced_headers" : -1,
        "synced_blocks" : -1,
        "inflight" : [
        ],
        "whitelisted" : false
    }
]`

It would appear that nodes don't agree on the block height, with the master having the higher one.

The hash of the block 1396 is apparently the same, on all the nodes but on the stuck node it doesn't show the `nextblockhash` variable.

Restarting the node didn't change anything, I'm going to try switching back to the beta 1.

Also if it helps, this happened when I started publishing around 1000tx/s on streams.

---

Thanks for that information - it's very helpful. We saw this one time ourselves last week when pushing a similarly high throughput, so that is probably the common reason. We'll prioritize fixing this and keep you updated.

---

Good to know, thank you !

Answer 1

This issue should be fixed in version 1.0 – please let us know.

Comments

I didn't get this problem since the 1.0 update, it seems to be fixed.

---

Great - thanks.