<p>It depends on which protocol is used. The two main ones that are commonly available:</p>
<ul>
<li>The original <code>getdata</code>/<code>block</code>-based protocol. A node would send <code>getdata</code> message with a block hash, and in return receive <code>block</code> message which contains the full block, including the headers, and all transactions.</li>
<li>The <a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki" rel="nofollow noreferrer">BIP152</a> &quot;compact blocks&quot; protocol extension, introduced in 2016. In this mode, nodes would ask (again using <code>getdata</code>) for a <em>compact</em> block (<code>cmpctblock</code>), which consists of the block header, the coinbase transaction, and short (48 bits) salted hashes of all the transactions in the block. The receiver would then try to reconstruct said block using the transactions it already has in its mempool (or elsewhere), request missing ones (using <code>getblocktxn</code>), receive those (using <code>blocktxn</code>), try to reconstruct again, and if that still fails, fall back to requesting the full block using the original protocol.</li>
</ul>
<p>Both of these approaches do require that the receiver is somehow made aware of the block's existence. There are again a number of ways this can be done:</p>
<ul>
<li>The original <code>inv</code>-based protocol, where new block hashes are announced. Nodes can also ask for large sequences of block headers (for catching up on historical blocks) using <code>getblocks</code>).</li>
<li>The <a href="https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki" rel="nofollow noreferrer">BIP130</a> &quot;sendheaders&quot; protocol extension. This allows nodes to request that new blocks are announced using their headers (<code>headers</code> message) rather than using the hashes. Headers are 80 bytes, while hashes are 32, so they're slightly bigger, but headers are much more useful for the receiver to make decisions based on (e.g. they can already verify proof-of-work).</li>
<li>The BIP152 compact block protocol also includes a &quot;high bandwidth&quot; mode, where nodes can request that new blocks get announced immediately using <code>cmpctblock</code>, rather than needing a round-trip using <code>inv</code> or <code>headers</code> first.</li>
</ul>
<p>Nodes may also negotiate ahead of time that <code>cmpctblock</code> messages may be sent unannounced (without corresponding <code>getdata</code> request), to reduce the latency.</p>
<p>Modern Bitcoin Core versions use <code>getdata</code>/<code>block</code> for initial block download, and then compact blocks for newly found blocks (and sendheaders for learning about them).</p>

CC BY-SA 4.0
2022-12-10T19:40:27.843Z
Thank you so much sir this made me so clear about my query.
I am actually creating a new chain of mine this would help me so much.
Aarav Dayal
CC BY-SA 4.0
2022-12-10T17:25:37.863Z
2022-12-10T17:25:37.863Z
Pieter Wuille
<p>Most of the blogs and answers to this question do not give a straightforward answer.</p>
<p>I have a good amount of information regarding bitcoin and would like to simply know if the transactions are packed as a whole inside the block when it is broadcasted or if only the hashes are included on broadcast and then the nodes (if they don't have a few transactions already in their mem pool) query the other nodes to give the transactions corresponding to that hashes?</p>
<p>Regards PL46U3@LTZ</p>

CC BY-SA 4.0
2022-12-10T09:36:02.767Z
I suppose both transactions and blocks are gossiped independently, and I'd assume only the ids are gossiped, while the contents are fetched only by the node that doesn't have the full data (the raw transaction or the block).
Mercedes
<bitcoin-core><network>
When a block is broadcasted, are all the data of the transactions packed into it or are only its hashes included in the block
Aarav Dayal
# When a block is broadcasted, are all the data of the transactions packed into it or are only its hashes included in the block

(Asked by: username_0 on 2022-12-10)

Most of the blogs and answers to this question do not give a straightforward answer.

I have a good amount of information regarding bitcoin and would like to simply know if the transactions are packed as a whole inside the block when it is broadcasted or if only the hashes are included on broadcast and then the nodes (if they don't have a few transactions already in their mem pool) query the other nodes to give the transactions corresponding to that hashes?

Regards PL46U3@LTZ

**Tags:** bitcoin-core, network

> **Comments:**
> **username_1**: I suppose both transactions and blocks are gossiped independently, and I'd assume only the ids are gossiped, while the contents are fetched only by the node that doesn't have the full data (the raw transaction or the block).  

---

## 1 answers

### Answer by username_2 on 2022-12-10. Score: 0 | Accepted answer

It depends on which protocol is used. The two main ones that are commonly available:

* The original `getdata`/`block`-based protocol. A node would send `getdata` message with a block hash, and in return receive `block` message which contains the full block, including the headers, and all transactions.
* The [BIP152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) "compact blocks" protocol extension, introduced in 2016. In this mode, nodes would ask (again using `getdata`) for a *compact* block (`cmpctblock`), which consists of the block header, the coinbase transaction, and short (48 bits) salted hashes of all the transactions in the block. The receiver would then try to reconstruct said block using the transactions it already has in its mempool (or elsewhere), request missing ones (using `getblocktxn`), receive those (using `blocktxn`), try to reconstruct again, and if that still fails, fall back to requesting the full block using the original protocol.

Both of these approaches do require that the receiver is somehow made aware of the block's existence. There are again a number of ways this can be done:

* The original `inv`-based protocol, where new block hashes are announced. Nodes can also ask for large sequences of block headers (for catching up on historical blocks) using `getblocks`).
* The [BIP130](https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki) "sendheaders" protocol extension. This allows nodes to request that new blocks are announced using their headers (`headers` message) rather than using the hashes. Headers are 80 bytes, while hashes are 32, so they're slightly bigger, but headers are much more useful for the receiver to make decisions based on (e.g. they can already verify proof-of-work).
* The BIP152 compact block protocol also includes a "high bandwidth" mode, where nodes can request that new blocks get announced immediately using `cmpctblock`, rather than needing a round-trip using `inv` or `headers` first.

Nodes may also negotiate ahead of time that `cmpctblock` messages may be sent unannounced (without corresponding `getdata` request), to reduce the latency.

Modern Bitcoin Core versions use `getdata`/`block` for initial block download, and then compact blocks for newly found blocks (and sendheaders for learning about them).

> **Comments:**
> **username_0**: Thank you so much sir this made me so clear about my query. I am actually creating a new chain of mine this would help me so much.  

---

