Raw data vs information encoded in OP_RETURNs

Question

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?

Answer 1

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 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.