<p>The current Bitcoin P2P protocol has no concept of compression, though there have been some proposals to incorporate it. The transaction data is sent as-is.</p>
<p>Some earlier discussion:</p>
<ul>
<li><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015851.html" rel="nofollow noreferrer">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015851.html</a> for specialized compression for headers sync.</li>
<li><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011837.html" rel="nofollow noreferrer">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011837.html</a> for general LZO-based compression.</li>
<li><a href="https://blockstream.com/satellite/" rel="nofollow noreferrer">Blockstream Satellite</a> uses a custom transaction compression scheme, which I privately know was once considered to be proposed as a general P2P protocol extension, though I don't think it ever made it that far.</li>
</ul>

CC BY-SA 4.0
2023-02-01T16:10:47.523Z
Where can I find these proposals?
Son Kaos999
CC BY-SA 4.0
2023-02-01T16:15:49.940Z
@SonKaos999: I fed Google "bitcoin compression bip", it gave me https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011837.html and a few other relevant documents among some non-relevant stuff.
RedGrittyBrick
CC BY-SA 4.0
2023-02-01T16:19:16.837Z
I added a few links.
Pieter Wuille
CC BY-SA 4.0
2023-02-01T15:16:10.460Z
2023-02-01T16:19:10.107Z
2023-02-01T16:19:10.107Z
Pieter Wuille
<p>Imagine I want to fill the 80 bytes of OP_RETURN data with zeroes, so that the resulting data is 640 bits set to 0, or 160 hex digits set to 0.</p>
<p>The data is 640 bits but the information encoded is much smaller, and can be represented with less data. Is the P2P network optimized to relay the OP_RETURN information as &quot;write 0 a hundred sixty times&quot; (compressed way) or would it relay the whole string of zeroes (raw data)?</p>
<p>Also imagine that a whole Bitcoin block is filled with such OP_RETURNs. If the P2P network relays compressed data, and although this block is ~1MB of raw data, the actual data downloaded and stored by full/archival nodes is significantly lower. Is this <strong>hypothetically</strong> possible?</p>

CC BY-SA 4.0
2023-02-02T08:18:37.510Z
Related: https://bitcoin.stackexchange.com/q/103100/5292
Jannes
<network><raw-data><op-return><bandwidth>
Raw data vs information encoded in OP_RETURNs
Son Kaos999
# Raw data vs information encoded in OP_RETURNs

(Asked by: username_0 on 2023-02-01)

Imagine I want to fill the 80 bytes of OP\_RETURN data with zeroes, so that the resulting data is 640 bits set to 0, or 160 hex digits set to 0.

The data is 640 bits but the information encoded is much smaller, and can be represented with less data. Is the P2P network optimized to relay the OP\_RETURN information as "write 0 a hundred sixty times" (compressed way) or would it relay the whole string of zeroes (raw data)?

Also imagine that a whole Bitcoin block is filled with such OP\_RETURNs. If the P2P network relays compressed data, and although this block is ~1MB of raw data, the actual data downloaded and stored by full/archival nodes is significantly lower. Is this **hypothetically** possible?

**Tags:** network, raw-data, op-return, bandwidth

> **Comments:**
> **username_1**: Related: https://bitcoin.stackexchange.com/q/103100/5292  

---

## 1 answers

### Answer by username_2 on 2023-02-01. Score: 8 | Accepted answer

The current Bitcoin P2P protocol has no concept of compression, though there have been some proposals to incorporate it. The transaction data is sent as-is.

Some earlier discussion:

* <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015851.html> for specialized compression for headers sync.
* <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011837.html> for general LZO-based compression.
* [Blockstream Satellite](https://blockstream.com/satellite/) uses a custom transaction compression scheme, which I privately know was once considered to be proposed as a general P2P protocol extension, though I don't think it ever made it that far.

> **Comments:**
> **username_0**: Where can I find these proposals?  
> **username_3**: @username_0: I fed Google "bitcoin compression bip", it gave me https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011837.html and a few other relevant documents among some non-relevant stuff.  
> **username_2**: I added a few links.  

---

