So, I'm stucked on block 50561 again. It looks, that resync is waiting for me again. Rob, in few last days I've made more than 10 full resync (deleted everything from biblepaycore folder - like in Togos post) but it never took less than 2 hours for me.
Maybe it is problem of my PC, but we've talked about this before latest mandatory testnet.
May it be caused with mine huge activity in constant download of data from my peers? May I be blocked somehow?
Sometimes it starts withou problem, but after some time download fall to 10kB/s.
I can guarant that it is not caused with my internet connection.
I have now tho internet providers (300 Mbps and 500Mbps) and it is the same on both. So, it can be caused with my PC, but on my second PC it was the same. Slow connection with peers.
I have tried to set gen=0, but there is still problem with sync.
Here is part from my debug.log:
2019-04-28 13:55:37 ERROR: AcceptBlockHeader: block f5cbf4edfd4df18b3204ac8c72b44ba04296e0334d50a9d40e9b208f4f835913 is marked invalid
2019-04-28 13:55:37 ERROR: invalid header received
So, I'll start resync again with gen=0 and I'll see if the sync will be faster.
BTW: Rob, can you delete debug.log from WIN wallet install file?
It is in ...BiblepayEvolution\doc\ folder after install and it has more then 67MB 
I think that it is not neccessary for us 
There are some old logs from end of March.
So, I think I have reproduced the same problem that you have (Im syncing from zero to 50558). I'm running a deep analysis now with more logging to confirm the exact root cause at 50558.
In the mean time while I'm doing this, I think the speed problem has more to do with the latency from SK to the US servers (not the machine or the bandwidth). Its a chatty process to download each block with all the back and forth confirms.
I recommend doing this for now (as most likely in prod, people will not be regularly syncing from 0 - although Im not against making a snapshot file in the future but we still have a pretty small block file). Could you try this, delete all the normal files from earlier, and sync to block 50,000. When it hits 50,000 click on File | Exit (do not pkill it, otherwise the flush may be bad on the blocks). Then copy the "blocks","Chainstate" and "evodb" out to a subfolder (like /snapshot for instance).
Then when I post the resolution, just go back to 50K and start again for each testnet session. (You can start back at 50K by removing the blocks, chainstate, evodb- and then copying the contents of your subfolder back to the appdata directory).
What I believe happened yesterday is when I set the evodb chainheight abnheight param we were at around block 50558 and I set it for 50560, meaning it didnt have enough blocks to propogate past the minimum for a newly syncing user from 0. Meaning that I believe your node had memorized the prior height while checking the block (this is what Ive got running now in the background to double verify this before I release a fix). If this is the case, we will have to bump a couple params and make a new release and all ensure we synced up past this height.
Btw, once you encounter a bad block you can forget trying to test the abn feature and the antigpu, because the wallet cant find proper coin age when its out of sync (or should I say its trying to build on faulty blocks on the wrong height etc).
Show Posts
