GUI sync progress starts from zero and confuses people #753

I understand the argument for making sync start from zero at restart— otherwise most users would only ever see very high numbers, which isn't exactly useful.

However, we have a real and obvious usability problem with the current behavior. New users, already frustrated by how long the sync takes shutdown and restart when they get to 80% or whatever, and when they start again it goes to 0. They believe that its going to take 18 hours to sync every startup and they give up in disgust. Sometimes they come and rant at us in IRC, it's even difficult to convince them that it's not really starting from zero. There are probably a number of ways to handle this, any of them would be better than the current behavior.

How do you propose we do this then, maxyboy?

LOL, I made it like that initially.

Then people came along complaining that, when restarting the client, it would always be almost full.

Feel free to change it back again, people will rant either way, I'm done with it, really...

It would be better to store a value like "lastCompleteSyncCount", which keeps track of the last block at which the client was 100% synced with the network. Clients that quit in the middle of a block download will keep their progress, which will reduce frustration. Additionally, clients that are synced when they were shut down will see their actual progress, instead of seeing 99% every time.

I simultaneously like and dislike gruez's suggestion. I like it in that it seems it would solve the need. I dislike it in that it makes the behavior more complicated to understand. ... it's certainly better than anything else I've got other than "use an eta"

@gruez Maybe you're using an old version, which still shows global progress, which would indeed be at 99% every time...

It was already changed to your suggestion. It starts from the last complete sync count, which means it looks like it starts from 0 every time, which is the reason @gmaxwell opened this issue.

Seems it sucks either way.

I think he's suggesting having an index which starts at zero who's position is only updated when the node's height is equal the the height it thinks is the top (according to the peers). E.g. this would stay zero until the node makes it up to 100% sync, then it jumps up to whatever that height is.

I think we're bikeshedding, and should make a step up the abstraction ladder. The larger issue is "why does it take &^!&^ 20 hours before the client is usable".

Packaging the block chain up to the last checkpoint with the executable might make sense.

It would be an incredible violation of the zero trust design of Bitcoin to include an opaque unvalidated blockchain.

It's never going to be instant so the report should be reasonable an not cause confusion. I've been working on the performance, — and I managed to get a speedup massive speedups on systems which aren't I/O limited, but most systems are so there is a long way to go still.

For the short term I'm going to revert to the old behaviour, to just show the global progress. Even though showing 99% at startup is "ugly" it is correct and clear.

I'm closing this issue as the title problem has been resolved. Of course, other solutions are still welcome but they should be less confusing, not more.

I think the progress bar should carry a text "N blocks left", and no percentage. The progress bar part conveys the notion of progress, but the only reliable way of informing people how much to do still, is telling them the number of blocks. If they see that decreasing, i believe little confusion will arise.