Quote from: BitcoinPlusBus on June 14, 2018, 04:16:03 PM

Quote from: egghead123 on June 13, 2018, 10:01:05 PM

Quote from: BitcoinPlusBus on June 09, 2018, 11:10:56 AM

The 2.6 client gets the version message, parses it fine until it gets to the subver string then throws errors. As a result it cannot read the block height that comes after. The substr issue is the issue we are looking into, could be due to sending serialised string as the numbers before worked.

We have found the exact line of code where 0.13 stops syncing, basically PoS hash does not meet the target. The block is Decemeber 2017. Not sure if it is a bit of a rogue block or of the issue is with the new client.Peter Will get all values for CheckStakeKernelHash from 2.6 and compare tomorrow.

I can see where Peter has pushed a few commits to the xbcwalletsource repo to deal with compiler warnings during the compilation process. Wink

https://github.com/bitcoinplusorg/xbcwalletsource/commit/d933f8c010fd6034166ac16df3f66c6020461a5a

https://github.com/bitcoinplusorg/xbcwalletsource/commit/49d312bda6f0186308c6e34f26b3830966d50ba7

https://github.com/bitcoinplusorg/xbcwalletsource/commit/d893c88ecbeb9579a9dc016514e2705f4ffaf45b

https://github.com/bitcoinplusorg/xbcwalletsource/commit/f5e66f794ba81834a9aec249316650ffed6098ec

Some progress, we have found the issue for the blockchain sticking at block 472,474 but it now gets stuck at block 590,436 with the same error as before though the cause will be different as the previous issue is now resolved.

Also client version now displays correctly locally in the GUI.Peter spotted the issue where it got stuck previously, thought we were going to get a full sync but it stopped three weeks short. Adding additional logging to both 2.6 and 2.7 now.

Old clients were notoriously problematic like that but the 2.7 client will sync much better. The issue here is to do with the client rejecting a valid block for an invalid stake target.The block header sync completes fine with the whole chain, just whole block validation that fails.

We need to compare the values being used to compute the target and see where they differ between 2.6 and 2.7.We now have added the same level of debugging to CheckStakeKernelHash in 2.6 and are waiting for it to sync to the same point that 2.7 fails to see the output.

Also adding additional logging directly into the CheckStakeKernelHash function to see the state of every variable used to computer the PoS target.Will use git to compare diffs and presume that there will be a noticeable difference between variables in 2.6 and 2.7 as the CheckStakeKernelHash function is not the same as they cannot be the same due to the large differences between the codebases.