<p>There are probably several reasons, but it's mostly historic. There is no inherent problem with just sending transaction id's. There is a disadvantage too, though, namely increased latency, which is not necessarily a problem when doing an initial sync, but it is not wanted when a fresh new block is propagating.</p>

<p>In fact, this idea is part of <a href="https://en.bitcoin.it/wiki/BIP_0037" rel="nofollow">BIP 37</a>, which specifies a protocol extension for requesting filtered blocks. To avoid the increased latency, matching transactions that are not known to the server to be already known to the receiver, are sent immediately after the filtered block itself.</p>

<p>Edit: <a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki" rel="nofollow">BIP152</a> compact blocks also use this idea, though they use shortened 48-bit transaction ids instead to save space.</p>

CC BY-SA 3.0
2013-01-24T12:54:26.683Z
Regarding latency, couldn't a block message with transactions id's be relayed as soon as it arrives before verifying its transactions? Creating blocks with invalid transactions would be too costly to consider them a problem, right?
Danny Navarro
CC BY-SA 3.0
2013-01-24T13:06:16.453Z
Didn't know bloom filters included filtered blocks. That solves the issue. Is the full implementation of BIP 37 coming with 0.8 release?
Danny Navarro
CC BY-SA 3.0
2013-01-24T19:02:35.967Z
A server-side implementation of BIP 37 will be in 0.8, yes.
Pieter Wuille
CC BY-SA 3.0
2013-01-24T12:07:56.163Z
2016-09-23T01:49:03.567Z
2016-09-23T01:49:03.567Z
Pieter Wuille
<p>When a bitcoin node has the blockchain in sync, most transactions in incoming <code>block</code> messages may have been already received as standalone <code>tx</code> messages before.</p>

<p>With a <code>block</code> message with only transaction hashes, the receiving node could try to reassemble the full block with its unconfirmed transactions and just request the missing transactions to complete the block.</p>

<p>Since this way to save bandwidth looks too obvious, I'm guessing there must a reason to always include the transactions in <code>block</code> messages, even after downloading the blockchain.</p>

<network><synchronization><relay><compact-blocks>
Block messages with transactions hashes instead of full transactions
Danny Navarro
# Block messages with transactions hashes instead of full transactions

(Asked by: username_0 on 2013-01-24)

When a bitcoin node has the blockchain in sync, most transactions in incoming `block` messages may have been already received as standalone `tx` messages before.

With a `block` message with only transaction hashes, the receiving node could try to reassemble the full block with its unconfirmed transactions and just request the missing transactions to complete the block.

Since this way to save bandwidth looks too obvious, I'm guessing there must a reason to always include the transactions in `block` messages, even after downloading the blockchain.

**Tags:** network, synchronization, relay, compact-blocks


---

## 1 answers

### Answer by username_1 on 2013-01-24. Score: 9 | Accepted answer

There are probably several reasons, but it's mostly historic. There is no inherent problem with just sending transaction id's. There is a disadvantage too, though, namely increased latency, which is not necessarily a problem when doing an initial sync, but it is not wanted when a fresh new block is propagating.

In fact, this idea is part of [BIP 37](https://en.bitcoin.it/wiki/BIP_0037), which specifies a protocol extension for requesting filtered blocks. To avoid the increased latency, matching transactions that are not known to the server to be already known to the receiver, are sent immediately after the filtered block itself.

Edit: [BIP152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) compact blocks also use this idea, though they use shortened 48-bit transaction ids instead to save space.

> **Comments:**
> **username_0**: Regarding latency, couldn't a block message with transactions id's be relayed as soon as it arrives before verifying its transactions? Creating blocks with invalid transactions would be too costly to consider them a problem, right?  
> **username_0**: Didn't know bloom filters included filtered blocks. That solves the issue. Is the full implementation of BIP 37 coming with 0.8 release?  
> **username_1**: A server-side implementation of BIP 37 will be in 0.8, yes.  

---

