On 2014-01-06 17:40, Noel Maersk wrote:

> On Mon, Jan 06, 2014 at 04:22:13PM +0000, Robert Williamson wrote:
> The issue is mostly visible when downloading the blockchain from block 1, since there's a lot of very small blocks, and all peers have them. This is why I think we need a special use case, connect to some nodes and if a good proportion of them are further than ~ 1000 blocks ahead, enter an initial download mode, where you only connect to a few nodes at once, send a getblocks, wait until they are all received, push them into the block writer and then send another request, until it is caught up.

Sounds just about right.

As long as the an overload protection logic is implemented more
centrally already, then as a nice secondary tweak just not to put
unnecessary load on the Bitcoin network, sure!

Remember that even a minimal number of nodes may deliver blocks to
libbitcoin at an incredible pace -

libbitcoin may be connecting to a local node/local nodes and get several
Gbps straight out of the RAM-based disk cache!