<p>Since Bitcoin Core 0.10, the following mechanism is used:</p>

<ul>
<li>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.</li>
<li><p>In the background, we continually ask peers for their blocks, in sequential height order, under the following conditions:</p>

<ul>
<li>If a block is already asked from another peer, we don't ask for it again.</li>
<li>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.</li>
<li>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.</li>
<li>If there are already 16 or more blocks in transit from a given peer, we don't ask any more blocks from that peer.</li>
</ul></li>
</ul>

<p>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.</p>

CC BY-SA 3.0
2017-09-25T01:26:12.400Z
Thank you for your reply! In addition, I want to know how long does it take to wait for a timeout?
Trl
CC BY-SA 3.0
2017-09-25T07:32:21.807Z
It's complicated...
Pieter Wuille
CC BY-SA 3.0
2017-09-24T21:28:01.047Z
2017-09-24T21:28:01.047Z
Pieter Wuille
<p>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.</p>

<p>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)</p>

<p>You can read more on network topology here:
<a href="https://en.bitcoin.it/wiki/Network" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Network</a></p>

CC BY-SA 3.0
2017-09-24T11:14:02.747Z
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
CC BY-SA 3.0
2017-09-24T11:34:47.463Z
updated the post relating to your query..
Piyush Chittara
CC BY-SA 3.0
2017-09-24T12:19:39.057Z
OK, I probably know something about it. Thank you very much! Let's wait for someone else to add more details.
Trl
CC BY-SA 3.0
2017-09-24T21:12:24.340Z
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
CC BY-SA 3.0
2017-09-24T08:39:06.283Z
2017-09-24T11:34:21.463Z
2017-09-24T11:34:21.463Z
Piyush Chittara
<p>When a bitcoin client downloads blocks from different peers, how does it determine the number of blocks to download from which peer?</p>

<blockchain>
Bitcoin client downloads blocks from different peers
Trl
# Bitcoin client downloads blocks from different peers

(Asked by: username_0 on 2017-09-24)

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

**Tags:** blockchain


---

## 2 answers

### Answer by username_1 on 2017-09-24. Score: 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.

> **Comments:**
> **username_0**: Thank you for your reply! In addition, I want to know how long does it take to wait for a timeout?  
> **username_1**: It's complicated...  

---

### Answer by username_2 on 2017-09-24. Score: -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>

> **Comments:**
> **username_0**: We know that the client download blocks from peers is parallel. So, how does the client guarantee that no duplicate blocks will be downloaded?  
> **username_2**: updated the post relating to your query..  
> **username_0**: OK, I probably know something about it. Thank you very much! Let's wait for someone else to add more details.  
> **username_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).  

---

