node blockHeight stuck at 338832 #5660

I noticed that one of my Statoshi fork nodes (up-to-date with Bitcoin commit 4f73a8f64d1555b4053f2a0a5c79083e50a0ce21) got stuck at block height 338832: http://statoshi.info/#/dashboard/db/blocks?panelId=1&fullscreen&from=1421176623670&to=1421207099532

The Statoshi fork doesn't have any functional changes to the protocol; this shouldn't be a bug in Statoshi. Also, my other Statoshi nodes have continued running without getting stuck.

Here's my debug log from the period during which the block height became stuck: http://pastebin.com/9bk4ptfA

The node is still receiving block messages but doesn't seem to be processing them - I don't see any updateTip messages or block error messages in the log. I'm not sure what to make of this.

See http://sourceforge.net/p/bitcoin/mailman/message/33221963/

I have 488ed32f2ada1d1dd108fc245d025c4d5f252783 merged into Statoshi; shouldn't it be a non-issue? https://github.com/jlopp/statoshi/commits/master

If at first you had it running unpatched and it saw a problematic block with a non-canonical signature, the block is marked invalid and this is persisted on disk. Use the reconsiderblock RPC command with the hash of the following block (338833) to get it to try again and ultimately resume.

I patched my node ~3 days before it got stuck at this height. FWIW, I restarted the node and it continued on its way and is now synced.

Maybe this is a complete non-issue, but I found it troubling.

Have you picked up #5608 or #5647 ?

I haven't; I'll go ahead and merge them in.

The OpenSSL problem gets stuck earlier; ie see "Large valid fork found" , stuck at block 322082 #5645

I also don't see anything about forks or rejected blocks in the attached debug.log, just rejected transactions (which is normal). So it must be a pure network code issue.

Likely,, one of #5608 or #5647 will indeed solve this.

I agree. I had a Bitcoin node on one of my Ubuntu laptops get hit by the OpenSSL bug and I had to reconsider the block before the node would update the tip; that wasn't necessary with this issue, so it was likely the network.