1

When a bitcoin client downloads blocks from different peers, how does it determine the number of blocks to download from which peer?

3

Since Bitcoin Core 0.10, the following mechanism is used:

  • We start off by asking peers for their best headers, and thus learn the most-work chain's headers quickly, and which peers have which parts of it available.
  • In the background, we continually ask peers for their blocks, in sequential height order, under the following conditions:

    • If a block is already asked from another peer, we don't ask for it again.
    • If a peer's known best block's corresponding chain has less total work than our currently active (fully downloaded and validated and accepted) chain, we ignore that peer - they'd only get us onto a fork that's worse than what we have.
    • If the only available blocks from a given peers that aren't already being downloaded already, are more than 1024 blocks ahead of our currently active chain, we don't ask anything (more) from that peer.
    • If there are already 16 or more blocks in transit from a given peer, we don't ask any more blocks from that peer.

All of this is subject to various timeout rules. In particular, when we're waiting for blocks from a single peer before we can download more from everyone else (because every other block in the 1024 that succeed our active chain is already downloaded), we disconnect that peer, and mark all its in flight blocks are available for fetching again from others.

  • Thank you for your reply! In addition, I want to know how long does it take to wait for a timeout? – Trl Sep 25 '17 at 1:26
  • It's complicated... – Pieter Wuille Sep 25 '17 at 7:32
-1

At the start of a connection, you send a getblocks message containing the hash of the latest block you know about. If the peer doesn't think that this is the latest block, it will send an inv that contains up to 500 blocks ahead of the one you listed. You will then request all of these blocks with getdata, and the peer will send them to you with block messages. After you have downloaded and processed all of these blocks, you will send another getblocks, etc., until you have all of the blocks.

You will send the getblocks message to all the connected nodes. Say you have block height upto 100 and blockchain is upto 1000 height, you send a getdata request to connected nodes, and accept the first inv message you recieve, now you have data upto 600 height, and you send getdata request again, and first inv message you recieve will fill you blockchain to 1000 height this time. (This is how I think it works, i am not sure if first inv message is selected or it waits for more inv, hope someone clarifies that)

You can read more on network topology here: https://en.bitcoin.it/wiki/Network

  • We know that the client download blocks from peers is parallel. So, how does the client guarantee that no duplicate blocks will be downloaded? – Trl Sep 24 '17 at 11:14
  • updated the post relating to your query.. – Piyush Chittara Sep 24 '17 at 11:34
  • OK, I probably know something about it. Thank you very much! Let's wait for someone else to add more details. – Trl Sep 24 '17 at 12:19
  • 1
    This is how things used to work up to Bitcoin Core 0.9, which didn't support parallel block downloading (and actually did download the same block multiple times occasionally). By now this is very outdated (together with everything else on the bitcoin.it wiki - please don't use it). – Pieter Wuille Sep 24 '17 at 21:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.