<p>Yes, more peers may reduce the time it takes for you to receive the most recently mined block.</p>

<p>When a new block is mined, the miner (or the pool) sends an <a href="https://bitcoin.org/en/developer-reference#inv" rel="nofollow"><code>inv</code> message</a> to all of its peers announcing the new block.  Those peers all send a <a href="https://bitcoin.org/en/developer-reference#getdata" rel="nofollow"><code>getdata</code> message</a> to the miner requesting the block.  The miner replies with a <a href="https://bitcoin.org/en/developer-reference#block" rel="nofollow"><code>block</code> message</a> sending the block to each of the peers which requested it.  (This part can be optimized to not send an entire block.)  </p>

<p>Then the peers each validate the block.  Once validated, they send an <code>inv</code> message to all of their peers announcing the new block.  Any of those peers which haven't received the block yet send a <code>getdata</code> message requesting the block.  The <code>block</code> message follows, and the cycle repeats until all peers on the network have the block.  (Or, in the case of SPV clients, just the parts of the block they need.)</p>

<p>The more peers you have, the greater the chance you'll be connected to the miner when he makes his initial announcement with an <code>inv</code> message, allowing you to be one of the first to request the block with the <code>getdata</code> message.</p>

<p>However, if the peer you send the <code>getdata</code> message to is bogged down in data transfer, it may take you longer to finish downloading the block than if you had started downloading from a different peer, so having more connections isn't a guarantee that you'll be able to download recently-mined blocks faster.  In short, there's an element of luck involved.</p>

CC BY-SA 3.0
2014-11-20T01:38:34.627Z
Thank you, David. your description gave me a clear blueprint.
Eleven
CC BY-SA 3.0
2014-11-20T01:41:40.767Z
IF the upcoming version is in parallel to fetching blocks, do you think change the max outbound bigger will be better?
Eleven
CC BY-SA 3.0
2014-11-20T02:02:06.580Z
Yes, but the advantage will be less significant in absolute terms.  For example: if peer A is connected to the miner and peer B is connected to peer A, it might take 5 seconds for peer A to download and verify the block from the miner and then 5 more seconds for peer B to download and verify the block from peer A (10 seconds total).  If an improvement allows the block to be downloaded and verified in 4 seconds, peer A will still get the block in half as much time, but the total time peer B has to wait is only 8 seconds.
David A. Harding
CC BY-SA 3.0
2014-11-19T16:54:17.247Z
2014-11-19T16:54:17.247Z
David A. Harding
<p>Up until the latest release (v0.9.3), more peers actually means slower synchronization typically, because we only really fetched from a single peer.</p>

<p>The upcoming release (v0.10.0) has a completely rewritten block fetching/validation mechanism, which first validates headers, and then fetches the blocks from all peers in parallel. The result should be much faster synchronization.</p>

CC BY-SA 3.0
2014-11-20T01:33:54.393Z
Hi, Pieter . First Thank your answer very much. I don't know what doses the parallel exactly mean. I checked the source code and found every peer can fetch at most 16 blocks and then fetch from another. Is the parallel processing as you said? Or am I  wrong. Thank you.
Eleven
CC BY-SA 3.0
2014-11-20T09:35:27.243Z
Wait, I assumed your question was about synchronization from scratch to the latest block. If you're talking about just receiving the latest block when you're already caught up there is little to do but being connected to good peers.
Pieter Wuille
CC BY-SA 3.0
2014-11-19T16:36:54.137Z
2014-11-19T16:36:54.137Z
Pieter Wuille
<p>I am running a full node on the Bitcoin network. Sometimes, I find that it takes a while until I get the newest block.<br>
I checked the source code, and found that every node can at most connect to eight peers. Would it help to increase the number of connections, to reduce the time until I receive the newest block?</p>

<protocol><network>
How can I reduce the time until I get the newest block ? Does the number of the outbound peers affect the speed?
Eleven
# How can I reduce the time until I get the newest block ? Does the number of the outbound peers affect the speed?

(Asked by: username_0 on 2014-11-19)

I am running a full node on the Bitcoin network. Sometimes, I find that it takes a while until I get the newest block.  
I checked the source code, and found that every node can at most connect to eight peers. Would it help to increase the number of connections, to reduce the time until I receive the newest block?

**Tags:** protocol, network


---

## 2 answers

### Answer by username_1 on 2014-11-19. Score: 2

Yes, more peers may reduce the time it takes for you to receive the most recently mined block.

When a new block is mined, the miner (or the pool) sends an [`inv` message](https://bitcoin.org/en/developer-reference#inv) to all of its peers announcing the new block. Those peers all send a [`getdata` message](https://bitcoin.org/en/developer-reference#getdata) to the miner requesting the block. The miner replies with a [`block` message](https://bitcoin.org/en/developer-reference#block) sending the block to each of the peers which requested it. (This part can be optimized to not send an entire block.)

Then the peers each validate the block. Once validated, they send an `inv` message to all of their peers announcing the new block. Any of those peers which haven't received the block yet send a `getdata` message requesting the block. The `block` message follows, and the cycle repeats until all peers on the network have the block. (Or, in the case of SPV clients, just the parts of the block they need.)

The more peers you have, the greater the chance you'll be connected to the miner when he makes his initial announcement with an `inv` message, allowing you to be one of the first to request the block with the `getdata` message.

However, if the peer you send the `getdata` message to is bogged down in data transfer, it may take you longer to finish downloading the block than if you had started downloading from a different peer, so having more connections isn't a guarantee that you'll be able to download recently-mined blocks faster. In short, there's an element of luck involved.

> **Comments:**
> **username_0**: Thank you, username_1. your description gave me a clear blueprint.  
> **username_0**: IF the upcoming version is in parallel to fetching blocks, do you think change the max outbound bigger will be better?  
> **username_1**: Yes, but the advantage will be less significant in absolute terms.  For example: if peer A is connected to the miner and peer B is connected to peer A, it might take 5 seconds for peer A to download and verify the block from the miner and then 5 more seconds for peer B to download and verify the block from peer A (10 seconds total).  If an improvement allows the block to be downloaded and verified in 4 seconds, peer A will still get the block in half as much time, but the total time peer B has to wait is only 8 seconds.  

---

### Answer by username_2 on 2014-11-19. Score: 2

Up until the latest release (v0.9.3), more peers actually means slower synchronization typically, because we only really fetched from a single peer.

The upcoming release (v0.10.0) has a completely rewritten block fetching/validation mechanism, which first validates headers, and then fetches the blocks from all peers in parallel. The result should be much faster synchronization.

> **Comments:**
> **username_0**: Hi, username_2 . First Thank your answer very much. I don't know what doses the parallel exactly mean. I checked the source code and found every peer can fetch at most 16 blocks and then fetch from another. Is the parallel processing as you said? Or am I  wrong. Thank you.  
> **username_2**: Wait, I assumed your question was about synchronization from scratch to the latest block. If you're talking about just receiving the latest block when you're already caught up there is little to do but being connected to good peers.  

---

