I think the easiest solution would be a mandatory update and do blockchain pruning that would cut out those blocks that we can't sync past.
Maybe that's what ICM has in mind already, I don't know..
Uh, no. You are I think misunderstanding why syncing takes awhile. It is not some block that you can't sync past (if that were the case, the network will have stopped). The UI progress bar appears to stall, but it is still sync'ing a ton of data in the background. The overhead of having the address index on all the time is causing it to take a long time. We only need address indexing going if we are running darkpoold. So I put a flag in there to turn it off by default.
Hi ICM,
no,it's not that.
If you download a clean wallet now,open it,you'll wait 1,2,3 days to get past that point and it'll never get.
I have tried that many times.
The only solution is to download a full blockchain.
Yes but the reason is this, which was also an issue in bitcoin:
https://github.com/bitcoin/bitcoin/issues/4431This was fixed in Bitcoin Core when they rewrote the entire sync mechanism. Our codebase is not quite close enough to Core to be able to use the entirely new headers first download mechanism with multiple sync nodes. However we can do some things like mentioned in pull request 4431.
But the address index is what is causing it to stretch out even longer. I tested it and tested a clean sync from scratch with it turned off. With it turned off by default I can sync the complete chain in something like 8 hours. Which is still long. With some other tweaks I am testing I think we can speed that up more.
I haven't really been focused on optimizing the address indexing because darkpool/blur has seen little use so far, so I backburnered it while focusing on the new wallet tech and the markets. One day, we will probably have headers first support which will make sync'ing far less of a headache. There are some proof-of-stake specific challenges that have to get figured out first in order to do headers first though.
