<p><code>getblocks</code> message pushes a maximum of 500 block <code>inv</code>s to the caller. It will lookup the given block locater in the active chain and pushes up to 500 MSG_BLOCK invs to the caller (it might stop earlier because the called node reaches the chain tip). The corresponding code for bitcoin-core 0.10 can be found here (<a href="https://github.com/bitcoin/bitcoin/blob/0.10/src/main.cpp#L3888" rel="nofollow">https://github.com/bitcoin/bitcoin/blob/0.10/src/main.cpp#L3888</a>).</p>

<p>Also notice that bitcoin-core now uses the headers first approach and therefore getblocks is no longer in use when acting as a "calling node".</p>

CC BY-SA 3.0
2015-06-03T13:02:41.060Z
What was actually confusing me was teh description on Bitcoin Wiki, [here](https://en.bitcoin.it/wiki/Protocol_documentation#getblocks). According to this description I imagine block locators being like distant markers on a blockchain - not being  pushed into `inv` necessarily consecutively. Let's say one node0's last seen block was block #40 and the best tip is at block #45. Will node0 then send block locators/header hashes in its `getblocks` message in this pattern [#1, #2, #3, ..., #40]? or as "distant" markers like e.g. [#10, #25, #30, #35, ..., #40]?
Aliakbar Ahmadi
CC BY-SA 3.0
2015-06-03T13:23:27.843Z
Check L3892 (https://github.com/bitcoin/bitcoin/blob/0.10/src/main.cpp#L3892). As far as i see only one locator is supported. So your node0 should send its top block hash within the getheaders message. Consider also reading: https://bitcoin.org/en/developer-reference#getblocks and you could also follow the `CNode`s `hashContinue` variable.
Jonas Schnelli
CC BY-SA 3.0
2015-06-03T13:38:28.013Z
Ok, but upon reading bitcoin.org/en/developer-reference#getblocks, it says _"One or more block header hashes ..."_ and with your hint of `hashContinue` and the fact that `nLimit` is decremented I'd claim that a **consecutive** order of multiple header hashes inside the inventory field sounds more plausible!?
Aliakbar Ahmadi
CC BY-SA 3.0
2015-06-03T14:47:45.830Z
I think you/we mix up getblocks message with the inv response. The `getblocks` message should probably only contain one block locater and a optional hash stop. The called node will response your `getblocks` message with serval invs containing all blockhashes that where found on the called node after your given block locater up to hash-stop or a max. of 500 blocks. If the node already sent you a block hash inv, it might be skipped. `nLimit` is decremented to make sure you won't get more than 500invs.
Jonas Schnelli
CC BY-SA 3.0
2015-06-03T14:54:29.260Z
Yes I also think we're talking of different things. I'm actually referring to bitcoin.org/en/developer-reference#getblocks **and** in particular to https://bitcoin.org/img/dev/en-ibd-getblocks.svg where it also says "header hash**es**" whereas you say _"The getblocks message should probably only contain **one** block locater and a optional hash stop."_
Aliakbar Ahmadi
CC BY-SA 3.0
2015-06-04T09:58:18.973Z
What do you think?
Aliakbar Ahmadi
CC BY-SA 3.0
2015-06-03T12:28:17.630Z
2015-06-03T12:28:17.630Z
Jonas Schnelli
<p>How many block locator hashes are sent in a <code>getblocks</code> message? And how distant are these locator hashes from one another?</p>

<blockchain><block><blockchain-fork><message><block-header>
Amount of block locator hashes in "getblocks" message
Aliakbar Ahmadi
# Amount of block locator hashes in "getblocks" message

(Asked by: username_0 on 2015-06-02)

How many block locator hashes are sent in a `getblocks` message? And how distant are these locator hashes from one another?

**Tags:** blockchain, block, blockchain-fork, message, block-header


---

## 1 answers

### Answer by username_1 on 2015-06-03. Score: 0 | Accepted answer

`getblocks` message pushes a maximum of 500 block `inv`s to the caller. It will lookup the given block locater in the active chain and pushes up to 500 MSG\_BLOCK invs to the caller (it might stop earlier because the called node reaches the chain tip). The corresponding code for bitcoin-core 0.10 can be found here (<https://github.com/bitcoin/bitcoin/blob/0.10/src/main.cpp#L3888>).

Also notice that bitcoin-core now uses the headers first approach and therefore getblocks is no longer in use when acting as a "calling node".

> **Comments:**
> **username_0**: What was actually confusing me was teh description on Bitcoin Wiki, [here](https://en.bitcoin.it/wiki/Protocol_documentation#getblocks). According to this description I imagine block locators being like distant markers on a blockchain - not being  pushed into `inv` necessarily consecutively. Let's say one node0's last seen block was block #40 and the best tip is at block #45. Will node0 then send block locators/header hashes in its `getblocks` message in this pattern [#1, #2, #3, ..., #40]? or as "distant" markers like e.g. [#10, #25, #30, #35, ..., #40]?  
> **username_1**: Check L3892 (https://github.com/bitcoin/bitcoin/blob/0.10/src/main.cpp#L3892). As far as i see only one locator is supported. So your node0 should send its top block hash within the getheaders message. Consider also reading: https://bitcoin.org/en/developer-reference#getblocks and you could also follow the `CNode`s `hashContinue` variable.  
> **username_0**: Ok, but upon reading bitcoin.org/en/developer-reference#getblocks, it says _"One or more block header hashes ..."_ and with your hint of `hashContinue` and the fact that `nLimit` is decremented I'd claim that a **consecutive** order of multiple header hashes inside the inventory field sounds more plausible!?  
> **username_1**: I think you/we mix up getblocks message with the inv response. The `getblocks` message should probably only contain one block locater and a optional hash stop. The called node will response your `getblocks` message with serval invs containing all blockhashes that where found on the called node after your given block locater up to hash-stop or a max. of 500 blocks. If the node already sent you a block hash inv, it might be skipped. `nLimit` is decremented to make sure you won't get more than 500invs.  
> **username_0**: Yes I also think we're talking of different things. I'm actually referring to bitcoin.org/en/developer-reference#getblocks **and** in particular to https://bitcoin.org/img/dev/en-ibd-getblocks.svg where it also says "header hash**es**" whereas you say _"The getblocks message should probably only contain **one** block locater and a optional hash stop."_  
> **username_0**: What do you think?  

---

