<p>Really <code>getblocks</code> should have been called <code>getblockhashes</code> , as the response contains just block hashes, not full blocks.</p>

<p>Every block can be observed in three different ways:</p>

<ul>
<li>The full block, containing all transactions and header information.</li>
<li>The block without the transactions, but just the 80-byte header which includes a Merkle root committing to the transactions.</li>
<li>Just the 32-byte hash of the block header (which is used to identify the whole block, and is thus also called the block hash).</li>
</ul>

<p><code>getblocks</code> was designed to be used for synchronizing blocks. The usual sequence was that node A would send a <code>getblocks</code>, B would respond with an <code>inv</code> with block hashes, A would reply with a <code>getdata</code> for each block he's missing, and B would send over the full blocks using <code>block</code> messages. The limit was 500, as downloading more than 500 blocks at once was presumably deemed too much and pointless (as that could be up to 500 MB of data).</p>

<p><code>getheaders</code> on the other hand was designed for headers synchronization, something at the time only used by lightweight clients. These would not download (all) full blocks, and the headers sent in response would generally be the only futher communication. As headers are only 80 bytes per block, even 2000 of them is just 160 kB of data.</p>

<p>Since the introduction of headers-first synchronization (which essentially uses <code>getheaders</code> to learn about block hashes and headers simultaneously, and then download missing blocks from multiple peers at once), the old <code>getblocks</code> based synchronization is superseded (it's still implemented for compatibility with software that doesn't have headers-based sync, but other than that inferior in every way except implementation complexity).</p>

CC BY-SA 4.0
2019-06-01T09:13:41.567Z
2019-06-01T09:13:41.567Z
Pieter Wuille
<p>I've been reading through the Bitcoin P2P protocol documentation as well as experimenting with Bitcore library but confused about one thing.</p>

<p>So <code>getblocks</code> seems to return inventory objects, which are just pointers, so you have to make another <code>getdata</code> request using those inventories to get the actual block.</p>

<p>And <code>getheaders</code> seems to return headers from <code>starts</code> to <code>stop</code>. </p>

<p>They act similar, except that <code>getheaders</code> returns more than just the pointers. I'm confused here because I feel like <code>getheaders</code> should be the "light mode" which only downloads small amount of data compared to <code>getblocks</code>. This is also shown by the fact that <code>getheaders</code> download up to 2000 headers by default while <code>getblocks</code> downloads up to only 500 inventories.</p>

<p>So am i misunderstanding any of this? Why does <code>getheaders</code> return more information than <code>getblocks</code> AND also return more results that <code>getblocks</code> (2000 vs 500)?</p>

<bitcoin-core><bitcoind><protocol>
Why does getheaders P2P API return more than getblocks?
Vlad
# Why does getheaders P2P API return more than getblocks?

(Asked by: username_0 on 2019-05-31)

I've been reading through the Bitcoin P2P protocol documentation as well as experimenting with Bitcore library but confused about one thing.

So `getblocks` seems to return inventory objects, which are just pointers, so you have to make another `getdata` request using those inventories to get the actual block.

And `getheaders` seems to return headers from `starts` to `stop`.

They act similar, except that `getheaders` returns more than just the pointers. I'm confused here because I feel like `getheaders` should be the "light mode" which only downloads small amount of data compared to `getblocks`. This is also shown by the fact that `getheaders` download up to 2000 headers by default while `getblocks` downloads up to only 500 inventories.

So am i misunderstanding any of this? Why does `getheaders` return more information than `getblocks` AND also return more results that `getblocks` (2000 vs 500)?

**Tags:** bitcoin-core, bitcoind, protocol


---

## 1 answers

### Answer by username_1 on 2019-06-01. Score: 8 | Accepted answer

Really `getblocks` should have been called `getblockhashes` , as the response contains just block hashes, not full blocks.

Every block can be observed in three different ways:

* The full block, containing all transactions and header information.
* The block without the transactions, but just the 80-byte header which includes a Merkle root committing to the transactions.
* Just the 32-byte hash of the block header (which is used to identify the whole block, and is thus also called the block hash).

`getblocks` was designed to be used for synchronizing blocks. The usual sequence was that node A would send a `getblocks`, B would respond with an `inv` with block hashes, A would reply with a `getdata` for each block he's missing, and B would send over the full blocks using `block` messages. The limit was 500, as downloading more than 500 blocks at once was presumably deemed too much and pointless (as that could be up to 500 MB of data).

`getheaders` on the other hand was designed for headers synchronization, something at the time only used by lightweight clients. These would not download (all) full blocks, and the headers sent in response would generally be the only futher communication. As headers are only 80 bytes per block, even 2000 of them is just 160 kB of data.

Since the introduction of headers-first synchronization (which essentially uses `getheaders` to learn about block hashes and headers simultaneously, and then download missing blocks from multiple peers at once), the old `getblocks` based synchronization is superseded (it's still implemented for compatibility with software that doesn't have headers-based sync, but other than that inferior in every way except implementation complexity).


---

