Topic: Compressed p2p communication (Read 635 times)
Autoreply: yes, by having 64/80 bytes worth of hashes (previous block hash + Merkle root). Thanks Tier.
Good point. Before testing, would you state the same for a Bloom-filtered stream though? Do you think that block headers alone would compress as bad?
Just out of curiosity, I wonder why the Bitcoin p2p protocol doesn't support any data compression. It seems to make sense in the first place as miners exchange a lot of data, possibly with many repeated patterns. Is there anything I didn't consider? Prefer network usage over processing power?
A lot of the data in the transactions is keys, signatures and hashes. These are going to be pretty random looking and hard to compress.
I took a random 128MB block.dat file, and compressed it using zip. The compressed file was 92MB. This is smaller, but not that much smaller. The benefit of compression isn't that much and it would make it harder to keep clients compatible.
The protocol also does things like sending the hash of the transaction before sending the transaction. This lets node only ask for transactions (and blocks) that they haven't seen before.
Just out of curiosity, I wonder why the Bitcoin p2p protocol doesn't support any data compression. It seems to make sense in the first place as miners exchange a lot of data, possibly with many repeated patterns. Is there anything I didn't consider? Prefer network usage over processing power?
Thanks!
Thanks!
Jump to: