MaxCoin 0.9.2.x wont synchronize

[lukem512]

0.9.2.x wallets will synchronize and continue to do so if the steps at http://maxcoinnews.net/maxcoin-0-9-2-1-release/ are followed; stopping and restarting the wallet will leave it stuck, however.

[reorder]

There is still something I cannot explain with 79659c8. If I stop the wallet then restart, it stops syncing. The error looks like this (I have extended the log message a little):

ERROR: AcceptBlock() : incorrect proof of work 454510829 vs calc 453887681 prevheight 603559

The block is coming from another known node running the same version.

This means that for stored blocks 603559 and below KGW returns nBits 453887681 while running nodes have it at 454510829. I have checked stored blockchain on restarted node for 5-6 steps in depth and blocks match those on running nodes, so active chain must be stored correctly.

[lukem512]

I am experiencing the same issue with my wallet. I stopped it at 603553, where it was syncing correctly, restarted and got an incorrect proof of work error on 603554. The block was accepted by other nodes as seen at http://maxcoin.co.uk:2750/block/00000000000aa676f0b1d47a6f0eaed649a3b1b0c6afc189e2c8b839180bcd40

2014-09-07 11:16:33 received block 00000000000aa676f0b1d47a6f0eaed649a3b1b0c6afc189e2c8b839180bcd40
2014-09-07 11:16:33 Proof of work failed
2014-09-07 11:16:33 KGW returned 454407973 with 30s and 453824483 with 60s
2014-09-07 11:16:33 Calculated PoW is 453824483 (KGW)
2014-09-07 11:16:33 Stored PoW is 454428468 (nBits)
2014-09-07 11:16:33 ERROR: AcceptBlock() : incorrect proof of work
2014-09-07 11:16:33 ERROR: ProcessBlock() : AcceptBlock FAILED

[lukem512]

After running some more tests I have found this:

2014-09-07 19:37:16 received block 0000000000065c746629a3671efd065cdfdd78fc4836520a4c8f4debd16d291a
2014-09-07 19:37:16 Proof of work failed
2014-09-07 19:37:16 KGW returned 453468912 with 30s and 453125197 with 60s
2014-09-07 19:37:16 Calculated PoW is 453125197 (KGW)
2014-09-07 19:37:16 Stored PoW is 453468912 (nBits)
2014-09-07 19:37:16 ERROR: AcceptBlock() : incorrect proof of work
2014-09-07 19:37:16 ERROR: ProcessBlock() : AcceptBlock FAILED

This is alarming as it seems to suggest that 30s blocks are being accepted when reindexing and that 30s is used as the requisite interval.

The nBits for the previous block, the last one accepted by my client, here, also has the 30s nBits value.

2014-09-07 19:36:42 received block 0000000000029857a5d6cc3a9d70c30648db396c0da11724bad41e4d10cd619c
2014-09-07 19:36:42 KGW returned 453214911 with 30s and 453156508 with 60s
2014-09-07 19:36:42 Committing 10 changed transactions to coin database...
2014-09-07 19:36:42 SetBestChain: new best=0000000000029857a5d6cc3a9d70c30648db396c0da11724bad41e4d10cd619c  height=606126 log2_work=66.030513  tx=1653165  date=2014-09-07 19:38:12 progress=1.000001
2014-09-07 19:36:42 ProcessBlock: ACCEPTED

[reorder]

This makes no sense to me tbh:

getblocktemplate
{
...
"previousblockhash" : "000000000003454a677330f1b2fffda1c4178a9b11ff70df1960d732367a9f82"
...
}
getblock 000000000003454a677330f1b2fffda1c4178a9b11ff70df1960d732367a9f82
{
...
"height" : 606175,
...
}

The prevblock height is well above BLOCK_HEIGHT_FORK3 and GetNextWorkRequired_V2 should have called KGW with 60 seconds target anyway?

[reorder]

Does this line looking like a noop have any special meaning? https://github.com/Max-Coin/maxcoin/blob/master/src/main.cpp#L1216

[repsorp]

Does that mean we'll have to --reindex on every reboot ??

Le 06/09/2014 21:32, Luke a écrit :

0.9.2.x wallets will synchronize and continue to do so if the steps at
http://maxcoinnews.net/maxcoin-0-9-2-1-release/ are followed; stopping
and restarting the wallet will leave it stuck, however.

—
Reply to this email directly or view it on GitHub
#47.

[lukem512]

@repsorp no, we'll find a fix!

@reorder I don't think so (see Megacoin code here). The KGW code is pretty messy and there's a few places that commonly are unused. The BlockCreating variable doesn't get used beyond it being set.

As for your first comment, it makes no sense to me either. As you can see from my KGW port I set the target time based upon the block height (above or below 600k) so I have no idea why 30s blocks are being accepted beyond it. I'm reindexing once more with some more debugging information to try and track down the problem. I guess what I'll have to do is hard fork again with the next release and set all blocks past that point to 60s, ensuring that the rule is followed this time.

[lukem512]

I think the static keyword is to blame. I'm reindexing without static const here to test

[reorder]

Very likely to be true. In fact, default const is static anyway, I suggest removing it too.

[lukem512]

Yeah I have done. If the reindex stops at block 600k then I'll know this is the reason. I think what's happening is the value is being determined the first time it is seen - at 60s for any node started above 600k and at 30s for any node below, including one reindexing.

[krakerjaak]

Indeed! Great find Luke! It was right there in our face all this time :)

[reorder]

0.9.2 nodes still cannot communicate with 0.9.3. This is the error message on 0.9.2 side:

ProcessMessages(version, 104 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length

[lukem512]

@reorder 0.9.3.1 has just been released, it solves this problem

[reorder]

@lukem512 Sorry, still the same error (only message len is 106 bytes now)

[lukem512]

Are you testing this on your 0.9.2 wallet? I have connections to several from 0.9.3.1

{
"addr" : "203.67.219.15:8668",
"services" : "00000001",
"lastsend" : 1410554752,
"lastrecv" : 1410554704,
"bytessent" : 9497,
"bytesrecv" : 82340,
"conntime" : 1410554448,
"version" : 70003,
"subver" : "/Max:0.9.2.1/",
"inbound" : false,
"startingheight" : 620206,
"banscore" : 0
}

[reorder]

I was connecting to 0.9.2 (not .1) - the version that the pool is running. I have now added 203.67.219.15 and it works with 0.9.3.1 indeed.

[lukem512]

Great to hear. Has 1gh.com updated then?

[reorder]

Not yet, I have to ensure it synchronizes and then works properly first.

[lukem512]

Okay then. I hope it all goes smoothly

[reorder]

Actually I now get the same error for version message from mentioned host on my side:

2014-09-12 21:06:04 send version message: version 70005, blocks=598052, us=xxx.xxx.xxx.xxx:xxx, them=203.67.219.15:8668, peer=203.67.219.15:8668
2014-09-12 21:06:04 ProcessMessages(version, 98 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length

[reorder]

Eventually 0.9.3 nodes are found and provide sync source, so I have upgraded nodes successfully. 0.9.2 still appears to be incompatible with 0.9.3, but this is probably not so important at this point.