search

kyuupichan / electrumx

Alternative implementation of spesmilo/electrum-server
Other
720 stars 732 forks source link

WARNING:BlockProcessor:daemon blocks do not form a chain; resetting the prefetcher (GINcoin) #834

Closed ghost closed 5 years ago

ghost commented 5 years ago

Hi everyone,

We're getting this when running electrumx with GINcoin.

May 27 10:04:05 electrum1 electrumx_server[15873]: INFO:Prefetcher:catching up to daemon height 311,488 (267,279 blocks behind)
May 27 10:04:05 electrum1 electrumx_server[15873]: WARNING:BlockProcessor:daemon blocks do not form a chain; resetting the prefetcher

It seems to measure the block height fine (block height number grows, as per the first line). It doesn't seem to fail on any new algorithm boundary (we've had three). I've added some debug logging lines to the header_hash() class override and I'm seeing lyra2z and neoscrypt just fine. Never makes it to x16rt. Seems like we're the only consumer of x16rt and lyra2z. Wondering if the issue might be in the lyra2z library, or if it was do you think it would throw a different error?.

Thank you for your time. Would appreciate any pointers on where to look next.

Sincerely,

Teran

kyuupichan commented 5 years ago

This means your blocks do not chain through the prev_hash field

ghost commented 5 years ago

Thanks for getting back to me. The blockchain and native client are running fine. Is it possible that electrumx is reading up a fork and getting confused? I am guessing there's some kind of hard fork that we did which needs to be listed.

Does that error get thrown as soon as one block doesn't match the previous one's hash? I think I'll want to add some more debugging around the main exception and see which block it doesn't like.

kyuupichan commented 5 years ago

It simply means the prev hash links are incorrect - the prev hash isn't the hash of the previous block. So either you're reading the prev hash field incorrectly, or you're calculating the block hash incorrectly.

ghost commented 5 years ago

Thank you!

Looks like the lyra2z implementation was bad.

https://github.com/LapoLab/lyra2z-py is working fine.

https://github.com/devwarrior777/lyra2z-py has unstable test output, even. Issue 1 talks about that.

Seems to be syncing now. I appreciate your time.