0.52.2a fresh node has high chance to create forked blockchain

[FL-Riko]

• create node with fresh codebase and fresh wallet adress
• load chain up to blockheight 7327 and node changed to status "synced"
• since block 7443 my node forked
• currently blockheight is 7563 i checked git pull again and is still actual codebase

I noticed this "fork behavior" at least 3 times.

[cyyber]

From the log provided by @FL-Riko, it is clear that he had an internet issue for more than 2 minutes. 2017-10-03 16:46:39,212 |synced| WARNING : verify_BK_hash Failed due to prevheaderhash mismatch, blockslen 6 2017-10-03 16:48:47,122 |synced| INFO : <<<Transmitting ST: 74 As these 2 logs line shows, that after 16:46:39, he received next data at 16:48:47. This must be because of some internet issue, due to which some blocks were missed resulting into fork.

I will add some codes to handle such issues.

[surg0r]

This is the final piece of the POS protocol to be completed with the latest POS algorithm update.

Solid reliable fork recovery and chain block buffer reorganisation is critical to a stable release.

A fix is coming soon.

[cyyber]

After looking into log provided by @randomusergenerator . I found that same problem happen with his Raspberry PI. Further investigating into logs, I found its taking around 2 minutes, to create the ST TXN, which freezes the node for 2 minutes.

Reason, during ST txn, slave XMSS is being created with tree height 10, which must be taking around 2 minutes.

[jleni]

I released a new qrllib with a feature that may help here. We will be integrating this into QRL today/tomorrow.

[FL-Riko]

created new node with codebase based on 5.10.2017 19:05 forked again shortly after synced status reached

[jleni]

PR #337 is likely to fix this problem. We will keep the issue open a few more days until this can be confirmed

[jleni]

Forking due to slow tree generation has been fixed and integrated. Other fork related issues should be opened as new issues. Closing this one.