Bitcoin Forum
April 19, 2024, 09:44:57 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Compressed p2p communication  (Read 603 times)
keeshux (OP)
Newbie
*
Offline Offline

Activity: 26
Merit: 6


View Profile WWW
June 09, 2015, 10:16:33 PM
 #1

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!
1713563097
Hero Member
*
Offline Offline

Posts: 1713563097

View Profile Personal Message (Offline)

Ignore
1713563097
Reply with quote  #2

1713563097
Report to moderator
1713563097
Hero Member
*
Offline Offline

Posts: 1713563097

View Profile Personal Message (Offline)

Ignore
1713563097
Reply with quote  #2

1713563097
Report to moderator
1713563097
Hero Member
*
Offline Offline

Posts: 1713563097

View Profile Personal Message (Offline)

Ignore
1713563097
Reply with quote  #2

1713563097
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
TierNolan
Legendary
*
Offline Offline

Activity: 1232
Merit: 1083


View Profile
June 09, 2015, 10:43:02 PM
 #2

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.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
keeshux (OP)
Newbie
*
Offline Offline

Activity: 26
Merit: 6


View Profile WWW
June 09, 2015, 11:06:44 PM
 #3

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?
keeshux (OP)
Newbie
*
Offline Offline

Activity: 26
Merit: 6


View Profile WWW
June 09, 2015, 11:14:05 PM
 #4

Autoreply: yes, by having 64/80 bytes worth of hashes (previous block hash + Merkle root). Thanks Tier.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!