downloading blocks is too slow

[TierNolan]

The way the initial block download works, your client goes and asks somebody, "what's the current block", and they say, BLOCK ID XXXXX.  And then since you don't have XXXXX, you ask them for that and they send it to you, but after you download it, then you look at its block header and discover that the previous block was WWWWW - and you don' t have that one either!  So you ask, "Hey could you give me  a copy of Block WWWWW?"  And they send that, and you look at it, and its parent was VVVVVV, and you don' t have that either, so you ask.....  and so on, back to the Genesis block.

No it doesn't.

If you had blocks from 0 to 10000, you would send something like.

I have (hashes of)

block 10000
block 9999
block 9998
....
block 9990
block 9900
block 9000
block 8000
block 5000
block 2000
block 500
block 0

The peer then scans the list and starts with the one first on the main chain.  If your block 10000 wasn't on the main chain, but block 9990 was, then it would start at block 9990.

Normally, it starts from the most recent block you have, unless you are somehow on a fork of the main chain.

Then there's a CPU bottleneck to worry about.  Your peer does all kinds of cryptographic checks on each downloaded block, so if your CPU is slow, that may even dominate the latency time.  

This is generally the big one.

[zvs]

Then there's a CPU bottleneck to worry about.  Your peer does all kinds of cryptographic checks on each downloaded block, so if your CPU is slow, that may even dominate the latency time.  

Maybe it's 'cause I have a fast CPU (i7-4700), but my problem was getting peers that uploaded too slow.  Each time it requests blocks from some peer w/ little or no upstream, you waste several minutes..

That's why it's better to just connect to one fast peer.

[DeathAndTaxes]

You would need a really slow CPU for it to be the bottleneck.  zvs is right, your bootstrapping speed will depend heavily based on the peer you connect to.  If that client has sub dialup speed uploads bandwidth (maybe because they are "leet" and have 860 inbound connections on their 1Mbps DSL line).  

It hasn't gotten much focus because it works and it isn't a critical upgrade but as the network becomes larger and the bootstrap times longer the clients will need to become better multitaskers.  Queueing up blocks, analyzing peer connection speeds, downloading in parallel, etc.   Optimally there should be a solid queue of blocks building up because other bottlenecks (probably disk unless you have a fast SSD) can't keep up.  Other ideas to explore would be to download headers only first, find, and verify the best chain.  The node now has a complete set of validated headers from the genesis block to current and can request block bodies from multiple peers and fill in the framework.  It also would make sense to throttle the number of connections a peer has based on its connectivity and maybe have peers distinguish between up to date nodes and bootstrapping nodes (like seeder and leacher terms used in bittorrent).  For a given amount of upstream bandwidth a node can support more "synced" peers than it can "bootstrapping" peers.   One could define the difference as a node who is more than two hours behind the best chain as bootstrapping and nodes would share that with other nodes when the status changes.  

[Sukrim]

Headers first sync is now talked about for a long time, apparently sipa is working on it at the moment (or not, he didn't push commits regarding this to github in the last 2 weeks). Hopefully it'll be ready for 0.10.0, it was already rumored to be in 0.9 but apparently didn't make the cut.