Peter Tschipper [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-11-09 to 2015-12-02
💬 Posted a total of 16 messages
📚 Participated in the following categories: bitcoin-dev, BIP Draft
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:45:27

- reply

📅 Original date posted:2015-12-02
📝 Original message:On 30/11/2015 9:28 PM, Matt Corallo wrote:
> I'm really not a fan of this at all. To start with, adding a compression library that is directly accessible to the network on financial software is a really, really scary idea.
Why scary? LZO has no current security issues, and it will be
configureable by each node operator so it can be turned off completely
if needed or desired.
> If there were a massive improvement, I'd find it acceptable, but the improvement you've shown really isn't all that much.
Why is 15% at the low end, to 27% at the high end not good? It sounds
like a very good boost.
> The numbers you recently posted show it improving the very beginning of IBD somewhat over high-latency connections, but if we're throughput-limited after the very beginning of IBD, we should fix that, not compress the blocks.
I only did the compression up to the 200,000 block to better isolate the
transmission of data from the post processing of blocks and determine
whether the compressing of data was adding to much to the total
transmission time.
I think it's clear from the data that as the data (blocks, transactions)
increase in size that (1) they compress better and (2) they have a
bigger and positive impact on improving performance when compressed.
> Additionally, I'd be very surprised if this had any significant effect on the speed at which new blocks traverse the network (do you have any simulations or other thoughts on this?).
>From the table below, at 120000 blocks the time to sync the chain was
roughly the same for compressed vs. uncompressed however after that
point as block sizes start increasing, all compression libraries
peformed much faster than uncompressed. The data provided in this
testing clearly shows that as block size increases, the performance
improvement by compressing data also increases.
TABLE 5:
Results shown in seconds with 60ms of induced latency
Num blks sync'd Uncmp Zlib-1 Zlib-6 LZO1x-1 LZO1x-999
--------------- ----- ------ ------ ------- ---------
120000 3226 3416 3397 3266 3302
130000 4010 3983 3773 3625 3703
140000 4914 4503 4292 4127 4287
150000 5806 4928 4719 4529 4821
160000 6674 5249 5164 4840 5314
170000 7563 5603 5669 5289 6002
180000 8477 6054 6268 5858 6638
190000 9843 7085 7278 6868 7679
200000 11338 8215 8433 8044 8795
As far as, what happens after the block is received, then obviously
compression isn't going to help in post processing and validating the
block, but in the pure transmission of the object it most certainly and
logically does and in a fairly direct proportion to the file size (a
file that is 20% smaller will be transmited "at least" 20% faster, you
can use any data transfer time calculator
<http://www.calctool.org/CALC/prof/computing/transfer_time> for that).
The only issue, that I can see that required testing was to show how
much compression there would be, and how much time the compression of
the data would add to the sending of the data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151202/9212a042/attachment-0001.html>

2023-06-07 17:45:25

- reply

📅 Original date posted:2015-12-02
📝 Original message:On 02/12/2015 2:23 PM, Matt Corallo wrote:
> My issue is more that its additional complexity and attack surface,
> and for a very minor gain
What is a minor gain? 15 to 27% compression sounds good to me and the
larger the data the better the compression. And although there is a
decent peformance gain in proportion to the % of compression, the
original motivation of the BIP was to reduce bandwidth for users in
regions where they are subject to caps.
> which should disappear with further optimization elsewhere
Why would the benefit of compressing data disappear with further
optimizations elsewhere, I'm not following you?. The compression of
data mainly has benefit in the sending of packets over the network. I
would think the performance gain would be cumulative. Why would this go
away by optimizing elsewhere?
> and less that we absolutely shouldn't add compression because we're
> definitely gonna have issues.
It's not that difficult to add compression. Even if there was an issue,
the compression feature can be completely turned off.
>
> On 12/02/15 20:16, Peter Tschipper via bitcoin-dev wrote:
>> Building a compressor from scratch may yeild some better compression
>> ratios, or not, but having trust and faith in whether it will stand up
>> against attack vectors another matter. LZO has been around for 20 years
>> with very few problems and no current issues. Maybe something better
>> can be built, but when and how much testing will need to be done before
>> it can be trusted? Right now there is something that provides a benefit
>> and in the future if something better is found it's not that difficult
>> to add it. We could easily support multiple compression libraries.
>>
>>
>> On 02/12/2015 10:57 AM, Emin Gün Sirer wrote:
>>> Thanks Peter for the careful, quantitative work.
>>>
>>> I want to bring one additional issue to everyone's consideration,
>>> related to the choice of the Lempel-Ziv family of compressors.
>>>
>>> While I'm not familiar with every single compression engine tested,
>>> the Lempel-Ziv family of compressors are generally based on
>>> "compression tables." Essentially, they assign a short unique number
>>> to every new subsequence they encounter, and when they re-encounter a
>>> sequence like "ab" in "abcdfdcdabcdfabcdf" they replace it with that
>>> short integer (say, in this case, 9-bit constant 256). So this example
>>> sequence may turn into "abcdfd<258 for cd><256 for ab><258 for
>>> cd>f<261 for abc><259 for df>" which is slightly shorter than the
>>> original (I'm doing this off the top of my head so the counts may be
>>> off, but it's meant to be illustrative). Note that the sequence "abc"
>>> got added into the table only after it was encountered twice in the
>>> input.
>>>
>>> This is nice and generic and works well for English text where certain
>>> letter sequences (e.g. "it" "th" "the" "this" "are" "there" etc) are
>>> repeated often, but it is nowhere as compact as it could possibly be
>>> for mostly binary data -- there are opportunities for much better
>>> compression, made possible by the structured reuse of certain byte
>>> sequences in the Bitcoin wire protocol.
>>>
>>> On a Bitcoin wire connection, we might see several related
>>> transactions reorganizing cash in a set of addresses, and therefore,
>>> several reuses of a 20-byte address. Or we might see a 200-byte
>>> transaction get transmitted, followed by the same transaction,
>>> repeated in a block. Ideally, we'd learn the sequence that may be
>>> repeated later on, all at once (e.g. a Bitcoin address or a
>>> transaction), and replace it with a short number, referring back to
>>> the long sequence. In the example above, if we knew that "abcdf" was a
>>> UNIT that would likely be repeated, we would put it into the
>>> compression table as a whole, instead of relying on repetition to get
>>> it into the table one extra byte at a time. That may let us compress
>>> the original sequence down to "abcdfd<257 for cd><256 for abcdf><256
>>> for abcdf>" from the get go.
>>>
>>> Yet the LZ variants I know of will need to see a 200-byte sequence
>>> repeated **199 times** in order to develop a single, reusable,
>>> 200-byte long subsequence in the compression table.
>>>
>>> So, a Bitcoin-specific compressor can perhaps do significantly better,
>>> but is it a good idea? Let's argue both sides.
>>>
>>> Cons:
>>>
>>> On the one hand, Bitcoin-specific compressors will be closely tied to
>>> the contents of messages, which might make it difficult to change the
>>> wire format later on -- changes to the wire format may need
>>> corresponding changes to the compressor. If the compressor cannot be
>>> implemented cleanly, then the protocol-agnostic, off-the-shelf
>>> compressors have a maintainability edge, which comes at the expense of
>>> the compression ratio.
>>>
>>> Another argument is that compression algorithms of any kind should be
>>> tested thoroughly before inclusion, and brand new code may lack the
>>> maturity required. While this argument has some merit, all outputs are
>>> verified separately later on during processing, so
>>> compression/decompression errors can potentially be detected. If the
>>> compressor/decompressor can be structured in a way that isolates
>>> bitcoind from failure (e.g. as a separate process for starters), this
>>> concern can be remedied.
>>>
>>> Pros:
>>>
>>> The nature of LZ compressors leads me to believe that much higher
>>> compression ratios are possible by building a custom, Bitcoin-aware
>>> compressor. If I had to guess, I would venture that compression ratios
>>> of 2X or more are possible in some cases. In some sense, the "O(1)
>>> block propagation" idea that Gavin proposed a while ago can be seen as
>>> extreme example of a Bitcoin-specific compressor, albeit one that
>>> constrains the order of transactions in a block.
>>>
>>> Compression can buy us some additional throughput at zero cost, modulo
>>> code complexity.
>>> Given the amount of acrimonious debate over the block size we have all
>>> had to endure, it seems
>>> criminal to leave potentially free improvements on the table. Even if
>>> the resulting code is
>>> deemed too complex to include in the production client right now, it
>>> would be good to understand
>>> the potential for improvement.
>>>
>>> How to Do It
>>>
>>> If we want to compress Bitcoin, a programming challenge/contest would
>>> be one of the best ways to find the best possible, Bitcoin-specific
>>> compressor. This is the kind of self-contained exercise that bright
>>> young hackers love to tackle. It'd bring in new programmers into the
>>> ecosystem, and many of us would love to discover the limits of
>>> compressibility for Bitcoin bits on a wire. And the results would be
>>> interesting even if the final compression engine is not enabled by
>>> default, or not even merged.
>>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

2023-06-07 17:45:24

- reply

📅 Original date posted:2015-12-02
📝 Original message:Building a compressor from scratch may yeild some better compression
ratios, or not, but having trust and faith in whether it will stand up
against attack vectors another matter. LZO has been around for 20 years
with very few problems and no current issues. Maybe something better
can be built, but when and how much testing will need to be done before
it can be trusted? Right now there is something that provides a benefit
and in the future if something better is found it's not that difficult
to add it. We could easily support multiple compression libraries.
On 02/12/2015 10:57 AM, Emin Gün Sirer wrote:
> Thanks Peter for the careful, quantitative work.
>
> I want to bring one additional issue to everyone's consideration,
> related to the choice of the Lempel-Ziv family of compressors.
>
> While I'm not familiar with every single compression engine tested,
> the Lempel-Ziv family of compressors are generally based on
> "compression tables." Essentially, they assign a short unique number
> to every new subsequence they encounter, and when they re-encounter a
> sequence like "ab" in "abcdfdcdabcdfabcdf" they replace it with that
> short integer (say, in this case, 9-bit constant 256). So this example
> sequence may turn into "abcdfd<258 for cd><256 for ab><258 for
> cd>f<261 for abc><259 for df>" which is slightly shorter than the
> original (I'm doing this off the top of my head so the counts may be
> off, but it's meant to be illustrative). Note that the sequence "abc"
> got added into the table only after it was encountered twice in the
> input.
>
> This is nice and generic and works well for English text where certain
> letter sequences (e.g. "it" "th" "the" "this" "are" "there" etc) are
> repeated often, but it is nowhere as compact as it could possibly be
> for mostly binary data -- there are opportunities for much better
> compression, made possible by the structured reuse of certain byte
> sequences in the Bitcoin wire protocol.
>
> On a Bitcoin wire connection, we might see several related
> transactions reorganizing cash in a set of addresses, and therefore,
> several reuses of a 20-byte address. Or we might see a 200-byte
> transaction get transmitted, followed by the same transaction,
> repeated in a block. Ideally, we'd learn the sequence that may be
> repeated later on, all at once (e.g. a Bitcoin address or a
> transaction), and replace it with a short number, referring back to
> the long sequence. In the example above, if we knew that "abcdf" was a
> UNIT that would likely be repeated, we would put it into the
> compression table as a whole, instead of relying on repetition to get
> it into the table one extra byte at a time. That may let us compress
> the original sequence down to "abcdfd<257 for cd><256 for abcdf><256
> for abcdf>" from the get go.
>
> Yet the LZ variants I know of will need to see a 200-byte sequence
> repeated **199 times** in order to develop a single, reusable,
> 200-byte long subsequence in the compression table.
>
> So, a Bitcoin-specific compressor can perhaps do significantly better,
> but is it a good idea? Let's argue both sides.
>
> Cons:
>
> On the one hand, Bitcoin-specific compressors will be closely tied to
> the contents of messages, which might make it difficult to change the
> wire format later on -- changes to the wire format may need
> corresponding changes to the compressor. If the compressor cannot be
> implemented cleanly, then the protocol-agnostic, off-the-shelf
> compressors have a maintainability edge, which comes at the expense of
> the compression ratio.
>
> Another argument is that compression algorithms of any kind should be
> tested thoroughly before inclusion, and brand new code may lack the
> maturity required. While this argument has some merit, all outputs are
> verified separately later on during processing, so
> compression/decompression errors can potentially be detected. If the
> compressor/decompressor can be structured in a way that isolates
> bitcoind from failure (e.g. as a separate process for starters), this
> concern can be remedied.
>
> Pros:
>
> The nature of LZ compressors leads me to believe that much higher
> compression ratios are possible by building a custom, Bitcoin-aware
> compressor. If I had to guess, I would venture that compression ratios
> of 2X or more are possible in some cases. In some sense, the "O(1)
> block propagation" idea that Gavin proposed a while ago can be seen as
> extreme example of a Bitcoin-specific compressor, albeit one that
> constrains the order of transactions in a block.
>
> Compression can buy us some additional throughput at zero cost, modulo
> code complexity.
> Given the amount of acrimonious debate over the block size we have all
> had to endure, it seems
> criminal to leave potentially free improvements on the table. Even if
> the resulting code is
> deemed too complex to include in the production client right now, it
> would be good to understand
> the potential for improvement.
>
> How to Do It
>
> If we want to compress Bitcoin, a programming challenge/contest would
> be one of the best ways to find the best possible, Bitcoin-specific
> compressor. This is the kind of self-contained exercise that bright
> young hackers love to tackle. It'd bring in new programmers into the
> ecosystem, and many of us would love to discover the limits of
> compressibility for Bitcoin bits on a wire. And the results would be
> interesting even if the final compression engine is not enabled by
> default, or not even merged.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151202/ddbc5702/attachment-0001.html>

2023-06-07 17:45:21

- reply

📅 Original date posted:2015-11-30
📝 Original message:@gmaxwell Bip Editor, and the Bitcoin Dev Community,
After several weeks of experimenting and testing with various
compression libraries I think there is enough evidence to show that
compressing blocks and transactions is not only beneficial in reducing
network bandwidth but is also provides a small performance boost when
there is latency on the network.
The following is a BIP Draft document for your review.
(The alignment of the columns in the tables doesn't come out looking
right in this email but if you cut and paste into a text document they
are just fine)
<pre>
BIP: ?
Title: Datastream compression of Blocks and Tx's
Author: Peter Tschipper <peter.tschipper at gmail.com>
Status: Draft
Type: Standards Track
Created: 2015-11-30
</pre>
==Abstract==
To compress blocks and transactions, and to concatenate them together
when possible, before sending.
==Motivation==
Bandwidth is an issue for users that run nodes in regions where
bandwidth is expensive and subject to caps, in addition network latency
in some regions can also be quite high. By compressing data we can
reduce daily bandwidth used in a significant way while at the same time
speed up the transmission of data throughout the network. This should
encourage users to keep their nodes running longer and allow for more
peer connections with less need for bandwidth throttling and in
addition, may also encourage users in areas of marginal internet
connectivity to run nodes where in the past they would not have been
able to.
==Specification==
Advertise compression using a service bit. Both peers must have
compression turned on in order for data to be compressed, sent, and
decompressed.
Blocks will be sent compressed.
Transactions will be sent compressed with the exception of those less
than 500 bytes.
Blocks will be concatenated when possible.
Transactions will be concatenated when possible or when a
MSG_FILTERED_BLOCK is requested.
Compression levels to be specified in "bitcoin.conf".
Compression and decompression can be completely turned off.
Although unlikely, if compression should fail then data will be sent
uncompressed.
The code for compressing and decompressing will be located in class
CDataStream.
Compression library LZO1x will be used.
==Rationale==
By using a service bit, compression and decompression can be turned
on/off completely at both ends with a simple configuration setting. It
is important to be able to easily turn off compression/decompression as
a fall back mechanism. Using a service bit also makes the code fully
compatible with any node that does not currently support compression. A
node that do not present the correct service bit will simply receive
data in standard uncompressed format.
All blocks will be compressed. Even small blocks have been found to
benefit from compression.
Multiple block requests that are in queue will be concatenated together
when possible to increase compressibility of smaller blocks.
Concatenation will happen only if there are multiple block requests from
the same remote peer. For example, if peer1 is requesting two blocks
and they are both in queue then those two blocks will be concatenated.
However, if peer1 is requesting 1 block and peer2 also one block, and
they are both in queue, then each peer is sent only its block and no
concatenation will occur. Up to 16 blocks (the max blocks in flight) can
be concatenated but not exceeding the MAX_PROTOCOL_MESSAGE_LENGTH.
Concatenated blocks compress better and further reduce bandwidth.
Transactions below 500 bytes do not compress well and will be sent
uncompressed unless they can be concatenated (see Table 3).
Multiple transaction requests that are in queue will be concatenated
when possible. This further reduces bandwidth needs and speeds the
transfer of large requests for many transactions, such as with
MSG_FILTERED_BLOCK requests, or when the system gets busy and is flooded
with transactions. Concatenation happens in the same way as for blocks,
described above.
By allowing for differing compression levels which can be specified in
the bitcoin.conf file, a node operator can tailor their compression to a
level suitable for their system.
Although unlikely, if compression fails for any reason then blocks and
transactions will be sent uncompressed. Therefore, even with
compression turned on, a node will be able to handle both compressed and
uncompressed data from another peer.
By Abstracting the compression/decompression code into class
"CDataStream", compression can be easily applied to any datastream.
The compression library LZO1x-1 does not compress to the extent that
Zlib does but it is clearly the better performer (particularly as file
sizes get larger), while at the same time providing very good
compression (see Tables 1 and 2). Furthermore, LZO1x-999 can provide
and almost Zlib like compression for those who wish to have more
compression, although at a cost.
==Test Results==
With the LZO library, current test results show up to a 20% compression
using LZO1x-1 and up to 27% when using LZO1x-999. In addition there is
a marked performance improvement when there is latency on the network.
>From the test results, with a latency of 60ms there is an almost 30%
improvement in performance when comparing LZO1x-1 compressed blocks with
uncompressed blocks (see Table 5).
The following table shows the percentage that blocks were compressed,
using two different Zlib and LZO1x compression level settings.
TABLE 1:
range = data size range
range Zlib-1 Zlib-6 LZO1x-1 LZO1x-999
----------- ------ ------ ------- --------
0-250 12.44 12.86 10.79 14.34
250-500 19.33 12.97 10.34 11.11
600-700 16.72 n/a 12.91 17.25
700-800 6.37 7.65 4.83 8.07
900-1KB 6.54 6.95 5.64 7.9
1KB-10KB 25.08 25.65 21.21 22.65
10KB-100KB 19.77 21.57 4.37 19.02
100KB-200KB 21.49 23.56 15.37 21.55
200KB-300KB 23.66 24.18 16.91 22.76
300KB-400KB 23.4 23.7 16.5 21.38
400KB-500KB 24.6 24.85 17.56 22.43
500KB-600KB 25.51 26.55 18.51 23.4
600KB-700KB 27.25 28.41 19.91 25.46
700KB-800KB 27.58 29.18 20.26 27.17
800KB-900KB 27 29.11 20 27.4
900KB-1MB 28.19 29.38 21.15 26.43
1MB -2MB 27.41 29.46 21.33 27.73
The following table shows the time in seconds that a block of data takes
to compress using different compression levels. One can clearly see
that LZO1x-1 is the fastest and is not as affected when data sizes get
larger.
TABLE 2:
range = data size range
range Zlib-1 Zlib-6 LZO1x-1 LZO1x-999
----------- ------ ------ ------- ---------
0-250 0.001 0 0 0
250-500 0 0 0 0.001
500-1KB 0 0 0 0.001
1KB-10KB 0.001 0.001 0 0.002
10KB-100KB 0.004 0.006 0.001 0.017
100KB-200KB 0.012 0.017 0.002 0.054
200KB-300KB 0.018 0.024 0.003 0.087
300KB-400KB 0.022 0.03 0.003 0.121
400KB-500KB 0.027 0.037 0.004 0.151
500KB-600KB 0.031 0.044 0.004 0.184
600KB-700KB 0.035 0.051 0.006 0.211
700KB-800KB 0.039 0.057 0.006 0.243
800KB-900KB 0.045 0.064 0.006 0.27
900KB-1MB 0.049 0.072 0.006 0.307
TABLE 3:
Compression of Transactions (without concatenation)
range = block size range
ubytes = average size of uncompressed transactions
cbytes = average size of compressed transactions
cmp% = the percentage amount that the transaction was compressed
datapoints = number of datapoints taken
range ubytes cbytes cmp% datapoints
---------- ------ ------ ------ ----------
0-250 220 227 -3.16 23780
250-500 356 354 0.68 20882
500-600 534 505 5.29 2772
600-700 653 608 6.95 1853
700-800 757 649 14.22 578
800-900 822 758 7.77 661
900-1KB 954 862 9.69 906
1KB-10KB 2698 2222 17.64 3370
10KB-100KB 15463 12092 21.80 15429
The above table shows that transactions don't compress well below 500
bytes but do very well beyond 1KB where there are a great deal of those
large spam type transactions. However, most transactions happen to be
in the < 500 byte range. So the next step was to appy concatenation for
those smaller transactions. Doing that yielded some very good
compression results. Some examples as follows:
The best one that was seen was when 175 transactions were concatenated
before being compressed. That yielded a 20% compression ratio, but that
doesn't take into account the savings from the unneeded 174 message
headers (24 bytes each) as well as 174 TCP ACKs of 52 bytes each which
yields and additional 76*174 = 13224 byte savings, making for an overall
bandwidth savings of 32%:
2015-11-18 01:09:09.002061 compressed data from 79890 to 67426
txcount:175
However, that was an extreme example. Most transaction aggregates were
in the 2 to 10 transaction range. Such as the following:
2015-11-17 21:08:28.469313 compressed data from 3199 to 2876 txcount:10
But even here the savings of 10% was far better than the "nothing" we
would get without concatenation, but add to that the 76 byte * 9
transaction savings and we have a total 20% savings in bandwidth for
transactions that otherwise would not be compressible. Therefore the
concatenation of small transactions can also save bandwidth and speed up
the transmission of those transactions through the network while keeping
network and message queue chatter to a minimum.
==Choice of Compression library==
LZO was chosen over Zlib. LZO is the fastest most scalable option when
used at the lowest compression setting which will be a performance boost
for users that prefer performance over bandwidth savings. And at the
higher end, LZO provides good compression (although at a higher cost)
which approaches that of Zlib.
Other compression libraries investigated were Snappy, LZOf, fastZlib and
LZ4 however none of these were found to be suitable, either because they
were not portable, lacked the flexibility to set compression levels or
did not provide a useful compression ratio.
The following two tables show results in seconds for syncing the first
200,000 blocks. Tests were run on a high-speed wireless LAN with very
little latency, and also run with a 60ms latency which was induced with
"Netbalancer".
TABLE 4:
Results shown in seconds on highspeed wireless LAN (no induced latency)
Num blks sync'd Uncmp Zlib-1 Zlib-6 LZO1x-1 LZO1x-999
--------------- ----- ------ ------ ------- ---------
10000 255 232 233 231 257
20000 464 414 420 407 453
30000 677 594 611 585 650
40000 887 787 795 760 849
50000 1099 961 977 933 1048
60000 1310 1145 1167 1110 1259
70000 1512 1330 1362 1291 1470
80000 1714 1519 1552 1469 1679
90000 1917 1707 1747 1650 1882
100000 2122 1905 1950 1843 2111
110000 2333 2107 2151 2038 2329
120000 2560 2333 2376 2256 2580
130000 2835 2656 2679 2558 2921
140000 3274 3259 3161 3051 3466
150000 3662 3793 3547 3440 3919
160000 4040 4172 3937 3767 4416
170000 4425 4625 4379 4215 4958
180000 4860 5149 4895 4781 5560
190000 5855 6160 5898 5805 6557
200000 7004 7234 7051 6983 7770
TABLE 5:
Results shown in seconds with 60ms of induced latency
Num blks sync'd Uncmp Zlib-1 Zlib-6 LZO1x-1 LZO1x-999
--------------- ----- ------ ------ ------- ---------
10000 219 299 296 294 291
20000 432 568 565 558 548
30000 652 835 836 819 811
40000 866 1106 1107 1081 1071
50000 1082 1372 1381 1341 1333
60000 1309 1644 1654 1605 1600
70000 1535 1917 1936 1873 1875
80000 1762 2191 2210 2141 2141
90000 1992 2463 2486 2411 2411
100000 2257 2748 2780 2694 2697
110000 2627 3034 3076 2970 2983
120000 3226 3416 3397 3266 3302
130000 4010 3983 3773 3625 3703
140000 4914 4503 4292 4127 4287
150000 5806 4928 4719 4529 4821
160000 6674 5249 5164 4840 5314
170000 7563 5603 5669 5289 6002
180000 8477 6054 6268 5858 6638
190000 9843 7085 7278 6868 7679
200000 11338 8215 8433 8044 8795
==Backward compatibility==
Being unable to present the correct service bit, older clients will
continue to receive standard uncompressed data and will be fully
compatible with this change.
==Fallback==
It is important to be able to entirely and easily turn off compression
and decompression as a fall back mechanism. This can be done with a
simple bitcoin.conf setting of "compressionlevel=0". Only one of the two
connected peers need to set compressionlevel=0 in order to turn off
compression and decompression completely.
==Deployment==
This enhancement does not require a hard or soft fork.
==Service Bit==
During the testing of this implementation, service bit 28 was used,
however this enhancement will require a permanently assigned service bit.
==Implementation==
This implementation depends on the LZO compression library: lzo-2.09
https://github.com/ptschip/bitcoin/tree/compress
==Copyright==
This document is placed in the public domain.

2023-06-07 17:45:19

- reply

2023-06-07 17:44:51

- reply

📅 Original date posted:2015-11-14
📝 Original message:I'd like to use service bit 28 for testing the block compression
prototype unless anyone has any objections or is using it already.
Thanks.

2023-06-07 17:44:30

- reply

📅 Original date posted:2015-11-29
📝 Original message:yes, you're right, it's just the percentage compressed (size reduction)
On 28/11/2015 4:30 PM, Jonathan Toomim wrote:
> It appears you're using the term "compression ratio" to mean "size
> reduction". A compression ratio is the ratio (compressed /
> uncompressed). A 1 kB file compressed with a 10% compression ratio
> would be 0.1 kB. It seems you're using (1 - compressed/uncompressed),
> meaning that the compressed file would be 0.9 kB.
>
> On Nov 28, 2015, at 6:48 AM, Peter Tschipper via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>> The following show the compression ratio acheived for various sizes
>> of data. Zlib is the clear
>> winner for compressibility, with LZOx-999 coming close but at a cost.
>>
>> range Zlib-1 cmp%
>> Zlib-6 cmp% LZOx-1 cmp% LZOx-999 cmp%
>> 0-250b 12.44 12.86 10.79 14.34
>> 250-500b 19.33 12.97 10.34 11.11
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151128/38398a67/attachment.html>

2023-06-07 17:44:29

- reply

📅 Original date posted:2015-11-28
📝 Original message:Hi All,
Here are some final results of testing with the reference implementation
for compressing blocks and transactions. This implementation also
concatenates blocks and transactions when possible so you'll see data
sizes in the 1-2MB ranges.
Results below show the time it takes to sync the first part of the
blockchain, comparing Zlib to the LZOx library. (LZOf was also tried
but wasn't found to be as good as LZOx). The following shows tests run
with and without latency. With latency on the network, all compression
libraries performed much better than without compression.
I don't think it's entirely obvious which is better, Zlib or LZO.
Although I prefer the higher compression of Zlib, overall I would have
to give the edge to LZO. With LZO we have the fastest most scalable
option when at the lowest compression setting which will be a boost in
performance for users that want peformance over compression, and then at
the high end LZO provides decent compression which approaches Zlib,
(although at a higher cost) but good for those that want to save more
bandwidth.
Uncompressed 60ms Zlib-1 (60ms) Zlib-6 (60ms) LZOx-1 (60ms) LZOx-999
(60ms)
219 299 296 294 291
432 568 565 558 548
652 835 836 819 811
866 1106 1107 1081 1071
1082 1372 1381 1341 1333
1309 1644 1654 1605 1600
1535 1917 1936 1873 1875
1762 2191 2210 2141 2141
1992 2463 2486 2411 2411
2257 2748 2780 2694 2697
2627 3034 3076 2970 2983
3226 3416 3397 3266 3302
4010 3983 3773 3625 3703
4914 4503 4292 4127 4287
5806 4928 4719 4529 4821
6674 5249 5164 4840 5314
7563 5603 5669 5289 6002
8477 6054 6268 5858 6638
9843 7085 7278 6868 7679
11338 8215 8433 8044 8795
These results from testing on a highspeed wireless LAN (very small latency)
Results in seconds
Num blocks sync'd Uncompressed Zlib-1 Zlib-6 LZOx-1 LZOx-999
10000 255 232 233 231 257
20000 464 414 420 407 453
30000 677 594 611 585 650
40000 887 782 795 760 849
50000 1099 961 977 933 1048
60000 1310 1145 1167 1110 1259
70000 1512 1330 1362 1291 1470
80000 1714 1519 1552 1469 1679
90000 1917 1707 1747 1650 1882
100000 2122 1905 1950 1843 2111
110000 2333 2107 2151 2038 2329
120000 2560 2333 2376 2256 2580
130000 2835 2656 2679 2558 2921
140000 3274 3259 3161 3051 3466
150000 3662 3793 3547 3440 3919
160000 4040 4172 3937 3767 4416
170000 4425 4625 4379 4215 4958
180000 4860 5149 4895 4781 5560
190000 5855 6160 5898 5805 6557
200000 7004 7234 7051 6983 7770
The following show the compression ratio acheived for various sizes of
data. Zlib is the clear
winner for compressibility, with LZOx-999 coming close but at a cost.
range Zlib-1 cmp%
Zlib-6 cmp% LZOx-1 cmp% LZOx-999 cmp%
0-250b 12.44 12.86 10.79 14.34
250-500b 19.33 12.97 10.34 11.11
600-700 16.72 n/a 12.91 17.25
700-800 6.37 7.65 4.83 8.07
900-1KB 6.54 6.95 5.64 7.9
1KB-10KB 25.08 25.65 21.21 22.65
10KB-100KB 19.77 21.57 14.37 19.02
100KB-200KB 21.49 23.56 15.37 21.55
200KB-300KB 23.66 24.18 16.91 22.76
300KB-400KB 23.4 23.7 16.5 21.38
400KB-500KB 24.6 24.85 17.56 22.43
500KB-600KB 25.51 26.55 18.51 23.4
600KB-700KB 27.25 28.41 19.91 25.46
700KB-800KB 27.58 29.18 20.26 27.17
800KB-900KB 27 29.11 20 27.4
900KB-1MB 28.19 29.38 21.15 26.43
1MB -2MB 27.41 29.46 21.33 27.73
The following shows the time in seconds to compress data of various
sizes. LZO1x is the
fastest and as file sizes increase, LZO1x time hardly increases at all.
It's interesing
to note as compression ratios increase LZOx-999 performs much worse than
Zlib. So LZO is faster
on the low end and slower (5 to 6 times slower) on the high end.
range Zlib-1 Zlib-6 LZOx-1 LZOx-999 cmp%
0-250b 0.001 0 0 0
250-500b 0 0 0 0.001
500-1KB 0 0 0 0.001
1KB-10KB 0.001 0.001 0 0.002
10KB-100KB 0.004 0.006 0.001 0.017
100KB-200KB 0.012 0.017 0.002 0.054
200KB-300KB 0.018 0.024 0.003 0.087
300KB-400KB 0.022 0.03 0.003 0.121
400KB-500KB 0.027 0.037 0.004 0.151
500KB-600KB 0.031 0.044 0.004 0.184
600KB-700KB 0.035 0.051 0.006 0.211
700KB-800KB 0.039 0.057 0.006 0.243
800KB-900KB 0.045 0.064 0.006 0.27
900KB-1MB 0.049 0.072 0.006 0.307
On 10/11/2015 8:46 AM, Jeff Garzik via bitcoin-dev wrote:
> Comments:
>
> 1) cblock seems a reasonable way to extend the protocol. Further
> wrapping should probably be done at the stream level.
>
> 2) zlib has crappy security track record.
>
> 3) A fallback path to non-compressed is required, should compression
> fail or crash.
>
> 4) Most blocks and transactions have runs of zeroes and/or highly
> common bit-patterns, which contributes to useful compression even at
> smaller sizes. Peter Ts's most recent numbers bear this out. zlib
> has a dictionary (32K?) which works well with repeated patterns such
> as those you see with concatenated runs of transactions.
>
> 5) LZO should provide much better compression, at a cost of CPU
> performance and using a less-reviewed, less-field-tested library.
>
>
>
>
>
> On Tue, Nov 10, 2015 at 11:30 AM, Tier Nolan via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
>
> On Tue, Nov 10, 2015 at 4:11 PM, Peter Tschipper
> <peter.tschipper at gmail.com <mailto:peter.tschipper at gmail.com>> wrote:
>
> There are better ways of sending new blocks, that's certainly
> true but for sending historical blocks and seding transactions
> I don't think so. This PR is really designed to save
> bandwidth and not intended to be a huge performance
> improvement in terms of time spent sending.
>
>
> If the main point is for historical data, then sticking to just
> blocks is the best plan.
>
> Since small blocks don't compress well, you could define a
> "cblocks" message that handles multiple blocks (just concatenate
> the block messages as payload before compression).
>
> The sending peer could combine blocks so that each cblock is
> compressing at least 10kB of block data (or whatever is optimal).
> It is probably worth specifying a maximum size for network buffer
> reasons (either 1MB or 1 block maximum).
>
> Similarly, transactions could be combined together and compressed
> "ctxs". The inv messages could be modified so that you can
> request groups of 10-20 transactions. That would depend on how
> much of an improvement compressed transactions would represent.
>
> More generally, you could define a message which is a compressed
> message holder. That is probably to complex to be worth the
> effort though.
>
>
>
>>
>> On Tue, Nov 10, 2015 at 5:40 AM, Johnathan Corgan via
>> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> On Mon, Nov 9, 2015 at 5:58 PM, gladoscc via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>>
>> I think 25% bandwidth savings is certainly
>> considerable, especially for people running full
>> nodes in countries like Australia where internet
>> bandwidth is lower and there are data caps.
>>
>>
>> This reinforces the idea that such trade-off decisions
>> should be be local and negotiated between peers, not a
>> required feature of the network P2P.
>>
>>
>> --
>> Johnathan Corgan
>> Corgan Labs - SDR Training and Development Services
>> http://corganlabs.com
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151128/66db15c2/attachment-0001.html>

2023-06-07 17:44:28

- reply

📅 Original date posted:2015-11-18
📝 Original message:Hi all,
I'm still doing a little more investigation before opening up a formal
bip PR, but getting close. Here are some more findings.
After moving the compression from main.cpp to streams.h (CDataStream) it
was a simple matter to add compression to transactions as well. Results
as follows:
range = block size range
ubytes = average size of uncompressed transactions
cbytes = average size of compressed transactions
cmp_ratio% = compression ratio
datapoints = number of datapoints taken
range ubytes cbytes cmp_ratio% datapoints
0-250b 220 227 -3.16 23780
250-500b 356 354 0.68 20882
500-600 534 505 5.29 2772
600-700 653 608 6.95 1853
700-800 757 649 14.22 578
800-900 822 758 7.77 661
900-1KB 954 862 9.69 906
1KB-10KB 2698 2222 17.64 3370
10KB-100KB 15463 12092 21.8 15429
A couple of obvious observations. Transactions don't compress well
below 500 bytes but do very well beyond 1KB where there are a great deal
of those large spam type transactions. However, most transactions
happen to be in the < 500 byte range. So the next step was to appy
bundling, or the creating of a "blob" for those smaller transactions, if
and only if there are multiple tx's in the getdata receive queue for a
peer. Doing that yields some very good compression ratios. Some
examples as follows:
The best one I've seen so far was the following where 175 transactions
were bundled into one blob before being compressed. That yielded a 20%
compression ratio, but that doesn't take into account the savings from
the unneeded 174 message headers (24 bytes each) as well as 174 TCP
ACK's of 52 bytes each which yields and additional 76*174=13224 bytes,
making the overall bandwidth savings 32%, in this particular case.
*2015-11-18 01:09:09.002061 compressed blob from 79890 to 67426 txcount:175*
To be sure, this was an extreme example. Most transaction blobs were in
the 2 to 10 transaction range. Such as the following:
*2015-11-17 21:08:28.469313 compressed blob from 3199 to 2876 txcount:10*
But even here the savings are 10%, far better than the "nothing" we
would get without bundling, but add to that the 76 byte * 9 transaction
savings and we have a total 20% savings in bandwidth for transactions
that otherwise would not be compressible.
The same bundling was applied to blocks and very good compression ratios
are seen when sync'ing the blockchain.
Overall the bundling or blobbing of tx's and blocks seems to be a good
idea for improving bandwith use but also there is a scalability factor
here, when the system is busy, transactions are bundled more often,
compressed, sent faster, keeping message queue and network chatter to a
minimum.
I think I have enough information to put together a formal BIP with the
exception of which compression library to implement. These tests were
done using ZLib but I'll also be running tests in the coming days with
LZO (Jeff Garzik's suggestion) and perhaps Snappy. If there are any
other libraries that people would like me to get results for please let
me know and I'll pick maybe the top 2 or 3 and get results back to the
group.
On 13/11/2015 1:58 PM, Peter Tschipper wrote:
> Some further Block Compression tests results that compare performance
> when network latency is added to the mix.
>
> Running two nodes, windows 7, compressionlevel=6, syncing the first
> 200000 blocks from one node to another. Running on a highspeed
> wireless LAN with no connections to the outside world.
> Network latency was added by using Netbalancer to induce the 30ms and
> 60ms latencies.
>
> From the data not only are bandwidth savings seen but also a small
> performance savings as well. However, the overall the value in
> compressing blocks appears to be in terms of saving bandwidth.
>
> I was also surprised to see that there was no real difference in
> performance when no latency was present; apparently the time it takes
> to compress is about equal to the performance savings in such a situation.
>
>
> The following results compare the tests in terms of how long it takes
> to sync the blockchain, compressed vs uncompressed and with varying
> latencies.
> uncmp = uncompressed
> cmp = compressed
>
> num blocks sync'd uncmp (secs) cmp (secs) uncmp 30ms (secs) cmp
> 30ms (secs) uncmp 60ms (secs) cmp 60ms (secs)
> 10000 264 269 265 257 274 275
> 20000 482 492 479 467 499 497
> 30000 703 717 693 676 724 724
> 40000 918 939 902 886 947 944
> 50000 1140 1157 1114 1094 1171 1167
> 60000 1362 1380 1329 1310 1400 1395
> 70000 1583 1597 1547 1526 1637 1627
> 80000 1810 1817 1767 1745 1872 1862
> 90000 2031 2036 1985 1958 2109 2098
> 100000 2257 2260 2223 2184 2385 2355
> 110000 2553 2486 2478 2422 2755 2696
> 120000 2800 2724 2849 2771 3345 3254
> 130000 3078 2994 3356 3257 4125 4006
> 140000 3442 3365 3979 3870 5032 4904
> 150000 3803 3729 4586 4464 5928 5797
> 160000 4148 4075 5168 5034 6801 6661
> 170000 4509 4479 5768 5619 7711 7557
> 180000 4947 4924 6389 6227 8653 8479
> 190000 5858 5855 7302 7107 9768 9566
> 200000 6980 6969 8469 8220 10944 10724
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151118/7d8123e1/attachment.html>

2023-06-07 17:44:28

- reply

📅 Original date posted:2015-11-13
📝 Original message:Some further Block Compression tests results that compare performance
when network latency is added to the mix.
Running two nodes, windows 7, compressionlevel=6, syncing the first
200000 blocks from one node to another. Running on a highspeed wireless
LAN with no connections to the outside world.
Network latency was added by using Netbalancer to induce the 30ms and
60ms latencies.
>From the data not only are bandwidth savings seen but also a small
performance savings as well. However, the overall the value in
compressing blocks appears to be in terms of saving bandwidth.
I was also surprised to see that there was no real difference in
performance when no latency was present; apparently the time it takes to
compress is about equal to the performance savings in such a situation.
The following results compare the tests in terms of how long it takes to
sync the blockchain, compressed vs uncompressed and with varying latencies.
uncmp = uncompressed
cmp = compressed
num blocks sync'd uncmp (secs) cmp (secs) uncmp 30ms (secs) cmp 30ms
(secs) uncmp 60ms (secs) cmp 60ms (secs)
10000 264 269 265 257 274 275
20000 482 492 479 467 499 497
30000 703 717 693 676 724 724
40000 918 939 902 886 947 944
50000 1140 1157 1114 1094 1171 1167
60000 1362 1380 1329 1310 1400 1395
70000 1583 1597 1547 1526 1637 1627
80000 1810 1817 1767 1745 1872 1862
90000 2031 2036 1985 1958 2109 2098
100000 2257 2260 2223 2184 2385 2355
110000 2553 2486 2478 2422 2755 2696
120000 2800 2724 2849 2771 3345 3254
130000 3078 2994 3356 3257 4125 4006
140000 3442 3365 3979 3870 5032 4904
150000 3803 3729 4586 4464 5928 5797
160000 4148 4075 5168 5034 6801 6661
170000 4509 4479 5768 5619 7711 7557
180000 4947 4924 6389 6227 8653 8479
190000 5858 5855 7302 7107 9768 9566
200000 6980 6969 8469 8220 10944 10724
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151113/885c94a1/attachment-0001.html>

2023-06-07 17:44:27

- reply

📅 Original date posted:2015-11-10
📝 Original message:On 10/11/2015 8:45 AM, Peter Tschipper wrote:
> On 10/11/2015 8:30 AM, Tier Nolan via bitcoin-dev wrote:
>>
>>
>> On Tue, Nov 10, 2015 at 4:11 PM, Peter Tschipper
>> <peter.tschipper at gmail.com> wrote:
>>
>> There are better ways of sending new blocks, that's certainly
>> true but for sending historical blocks and seding transactions I
>> don't think so. This PR is really designed to save bandwidth and
>> not intended to be a huge performance improvement in terms of
>> time spent sending.
>>
>>
>> If the main point is for historical data, then sticking to just
>> blocks is the best plan.
>>
> at the beginning yes.
>> Since small blocks don't compress well, you could define a "cblocks"
>> message that handles multiple blocks (just concatenate the block
>> messages as payload before compression).
>>
> Small block are rare these days (but plenty of historical block), but
> still they get a 10% compression, not bad and I think worthwhile and
> the time it takes to compress small blocks is less that a millisecond
> so no loss there in time. But still you have a good point and
> something worthy of doing after getting compression to work. I think
> it's wise to keep it simple at first and build on the success later.
>> The sending peer could combine blocks so that each cblock is
>> compressing at least 10kB of block data (or whatever is optimal). It
>> is probably worth specifying a maximum size for network buffer
>> reasons (either 1MB or 1 block maximum).
> Good idea. Same answer as above.
>> Similarly, transactions could be combined together and compressed
>> "ctxs". The inv messages could be modified so that you can request
>> groups of 10-20 transactions. That would depend on how much of an
>> improvement compressed transactions would represent.
>>
> Good idea. Same answer as above.
>> More generally, you could define a message which is a compressed
>> message holder. That is probably to complex to be worth the effort
>> though.
> That's actually pretty easy to do and part of the plan. Sending a
> cmp_block rather than a block makes it all easier to implement. It's
> just a matter of doing pnode->pushmessage("cmp_block",
> compressed_block); and handling the "cmp_block" command string at the
> other end.
>>
>>
>>
>>>
>>> On Tue, Nov 10, 2015 at 5:40 AM, Johnathan Corgan via
>>> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>>
>>> On Mon, Nov 9, 2015 at 5:58 PM, gladoscc via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>
>>> I think 25% bandwidth savings is certainly considerable,
>>> especially for people running full nodes in countries
>>> like Australia where internet bandwidth is lower and
>>> there are data caps.
>>>
>>>
>>> This reinforces the idea that such trade-off decisions
>>> should be be local and negotiated between peers, not a
>>> required feature of the network P2P.
>>>
>>>
>>> --
>>> Johnathan Corgan
>>> Corgan Labs - SDR Training and Development Services
>>> http://corganlabs.com
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151110/1aebeb1f/attachment-0001.html>

2023-06-07 17:44:26

- reply

📅 Original date posted:2015-11-11
📝 Original message:If that were true then we wouldn't need to gzip large files before
sending them over the internet. Data compression generally helps
transmission speed as long as the amount of compression is high enough
and the time it takes is low enough to make it worthwhile. On a
corporate LAN it's generally not worthwhile unless you're dealing with
very large files, but over a corporate WAN or the internet where network
latency can be high it is IMO a worthwhile endevor.
On 11/11/2015 10:49 AM, Marco Pontello wrote:
> A random thought: aren't most communication over a data link already
> compressed, at some point?
> When I used a modem, we had the V.42bis protocol. Now, nearly all ADSL
> connections using PPPoE, surely are. And so on.
> I'm not sure another level of generic, data agnostic kind of
> compression will really give us some real-life practical advantage
> over that.
>
> Something that could take advantage of of special knowledge of the
> specific data, instead, would be an entirely different matter.
>
> Just my 2c.
>
> On Wed, Nov 11, 2015 at 7:35 PM, Peter Tschipper via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Here are the latest results on compression ratios for the first
> 295,000 blocks, compressionlevel=6. I think there are more than
> enough datapoints for statistical significance.
>
> Results are very much similar to the previous test. I'll work on
> getting a comparison between how much time savings/loss in time
> there is when syncing the blockchains: compressed vs
> uncompressed. Still, I think it's clear that serving up
> compressed blocks, at least historical blocks, will be of benefit
> for those that have bandwidth caps on their internet connections.
>
> The proposal, so far is fairly simple:
> 1) compress blocks with some compression library: currently zlib
> but I can investigate other possiblities
> 2) As a fall back we need to advertise compression as a service.
> That way we can turn off compression AND decompression completely
> if needed.
> 3) Do the compression at the datastream level in the code.
> CDataStream is the obvious place.
>
>
> Test Results:
>
> range = block size range
> ubytes = average size of uncompressed blocks
> cbytes = average size of compressed blocks
> ctime = average time to compress
> dtime = average time to decompress
> cmp_ratio% = compression ratio
> datapoints = number of datapoints taken
>
> range ubytes cbytes ctime dtime cmp_ratio%
> datapoints
> 0-250b 215 189 0.001 0.000 12.40
> 91280
> 250-500b 438 404 0.001 0.000 7.85
> 13217
> 500-1KB 761 701 0.001 0.000
> 7.86 11434
> 1KB-10KB 4149 3547 0.001 0.000 14.51
> 52180
> 10KB-100KB 41934 32604 0.005 0.001 22.25 82890
> 100KB-200KB 146303 108080 0.016 0.001 26.13 29886
> 200KB-300KB 243299 179281 0.025 0.002 26.31 25066
> 300KB-400KB 344636 266177 0.036 0.003 22.77 4956
> 400KB-500KB 463201 356862 0.046 0.004 22.96 3167
> 500KB-600KB 545123 429854 0.056 0.005 21.15 366
> 600KB-700KB 647736 510931 0.065 0.006 21.12 254
> 700KB-800KB 746540 587287 0.073 0.008 21.33 294
> 800KB-900KB 868121 682650 0.087 0.008 21.36 199
> 900KB-1MB 945747 726307 0.091 0.010 23.20 304
>
> On 10/11/2015 8:46 AM, Jeff Garzik via bitcoin-dev wrote:
>> Comments:
>>
>> 1) cblock seems a reasonable way to extend the protocol. Further
>> wrapping should probably be done at the stream level.
>>
>> 2) zlib has crappy security track record.
>>
>> 3) A fallback path to non-compressed is required, should
>> compression fail or crash.
>>
>> 4) Most blocks and transactions have runs of zeroes and/or highly
>> common bit-patterns, which contributes to useful compression even
>> at smaller sizes. Peter Ts's most recent numbers bear this out.
>> zlib has a dictionary (32K?) which works well with repeated
>> patterns such as those you see with concatenated runs of
>> transactions.
>>
>> 5) LZO should provide much better compression, at a cost of CPU
>> performance and using a less-reviewed, less-field-tested library.
>>
>>
>>
>>
>>
>> On Tue, Nov 10, 2015 at 11:30 AM, Tier Nolan via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>>
>>
>> On Tue, Nov 10, 2015 at 4:11 PM, Peter Tschipper
>> <peter.tschipper at gmail.com
>> <mailto:peter.tschipper at gmail.com>> wrote:
>>
>> There are better ways of sending new blocks, that's
>> certainly true but for sending historical blocks and
>> seding transactions I don't think so. This PR is really
>> designed to save bandwidth and not intended to be a huge
>> performance improvement in terms of time spent sending.
>>
>>
>> If the main point is for historical data, then sticking to
>> just blocks is the best plan.
>>
>> Since small blocks don't compress well, you could define a
>> "cblocks" message that handles multiple blocks (just
>> concatenate the block messages as payload before compression).
>>
>> The sending peer could combine blocks so that each cblock is
>> compressing at least 10kB of block data (or whatever is
>> optimal). It is probably worth specifying a maximum size for
>> network buffer reasons (either 1MB or 1 block maximum).
>>
>> Similarly, transactions could be combined together and
>> compressed "ctxs". The inv messages could be modified so
>> that you can request groups of 10-20 transactions. That
>> would depend on how much of an improvement compressed
>> transactions would represent.
>>
>> More generally, you could define a message which is a
>> compressed message holder. That is probably to complex to be
>> worth the effort though.
>>
>>
>>
>>>
>>> On Tue, Nov 10, 2015 at 5:40 AM, Johnathan Corgan via
>>> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>>
>>> On Mon, Nov 9, 2015 at 5:58 PM, gladoscc via
>>> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>>
>>>
>>> I think 25% bandwidth savings is certainly
>>> considerable, especially for people running full
>>> nodes in countries like Australia where internet
>>> bandwidth is lower and there are data caps.
>>>
>>>
>>> This reinforces the idea that such trade-off
>>> decisions should be be local and negotiated between
>>> peers, not a required feature of the network P2P.
>>>
>>>
>>> --
>>> Johnathan Corgan
>>> Corgan Labs - SDR Training and Development Services
>>> http://corganlabs.com
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> --
> Try the Online TrID File Identifier
> http://mark0.net/onlinetrid.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151111/89fce255/attachment-0001.html>

2023-06-07 17:44:24

- reply

📅 Original date posted:2015-11-10
📝 Original message:On 10/11/2015 8:46 AM, Jeff Garzik via bitcoin-dev wrote:
> Comments:
>
> 1) cblock seems a reasonable way to extend the protocol. Further
> wrapping should probably be done at the stream level.
agreed.
>
> 2) zlib has crappy security track record.
>
Zlib had a bad buffer overflow bug but that was in 2005 and it got a lot
of press at the time. It's was fixed in version 1.2.3...we're on 1.2.8
now. I'm not aware of any other current issues with zlib. Do you have a
citation?
> 3) A fallback path to non-compressed is required, should compression
> fail or crash.
agreed.
>
> 4) Most blocks and transactions have runs of zeroes and/or highly
> common bit-patterns, which contributes to useful compression even at
> smaller sizes. Peter Ts's most recent numbers bear this out. zlib
> has a dictionary (32K?) which works well with repeated patterns such
> as those you see with concatenated runs of transactions.
>
> 5) LZO should provide much better compression, at a cost of CPU
> performance and using a less-reviewed, less-field-tested library.
I don't think LZO will give as good compression here but I will do some
benchmarking when I can.
>
>
>
>
>
> On Tue, Nov 10, 2015 at 11:30 AM, Tier Nolan via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
>
> On Tue, Nov 10, 2015 at 4:11 PM, Peter Tschipper
> <peter.tschipper at gmail.com <mailto:peter.tschipper at gmail.com>> wrote:
>
> There are better ways of sending new blocks, that's certainly
> true but for sending historical blocks and seding transactions
> I don't think so. This PR is really designed to save
> bandwidth and not intended to be a huge performance
> improvement in terms of time spent sending.
>
>
> If the main point is for historical data, then sticking to just
> blocks is the best plan.
>
> Since small blocks don't compress well, you could define a
> "cblocks" message that handles multiple blocks (just concatenate
> the block messages as payload before compression).
>
> The sending peer could combine blocks so that each cblock is
> compressing at least 10kB of block data (or whatever is optimal).
> It is probably worth specifying a maximum size for network buffer
> reasons (either 1MB or 1 block maximum).
>
> Similarly, transactions could be combined together and compressed
> "ctxs". The inv messages could be modified so that you can
> request groups of 10-20 transactions. That would depend on how
> much of an improvement compressed transactions would represent.
>
> More generally, you could define a message which is a compressed
> message holder. That is probably to complex to be worth the
> effort though.
>
>
>
>>
>> On Tue, Nov 10, 2015 at 5:40 AM, Johnathan Corgan via
>> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> On Mon, Nov 9, 2015 at 5:58 PM, gladoscc via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>>
>> I think 25% bandwidth savings is certainly
>> considerable, especially for people running full
>> nodes in countries like Australia where internet
>> bandwidth is lower and there are data caps.
>>
>>
>> This reinforces the idea that such trade-off decisions
>> should be be local and negotiated between peers, not a
>> required feature of the network P2P.
>>
>>
>> --
>> Johnathan Corgan
>> Corgan Labs - SDR Training and Development Services
>> http://corganlabs.com
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151110/1688b581/attachment.html>

2023-06-07 17:44:24

- reply

📅 Original date posted:2015-11-11
📝 Original message:Here are the latest results on compression ratios for the first 295,000
blocks, compressionlevel=6. I think there are more than enough
datapoints for statistical significance.
Results are very much similar to the previous test. I'll work on
getting a comparison between how much time savings/loss in time there is
when syncing the blockchains: compressed vs uncompressed. Still, I
think it's clear that serving up compressed blocks, at least historical
blocks, will be of benefit for those that have bandwidth caps on their
internet connections.
The proposal, so far is fairly simple:
1) compress blocks with some compression library: currently zlib but I
can investigate other possiblities
2) As a fall back we need to advertise compression as a service. That
way we can turn off compression AND decompression completely if needed.
3) Do the compression at the datastream level in the code. CDataStream
is the obvious place.
Test Results:
range = block size range
ubytes = average size of uncompressed blocks
cbytes = average size of compressed blocks
ctime = average time to compress
dtime = average time to decompress
cmp_ratio% = compression ratio
datapoints = number of datapoints taken
range ubytes cbytes ctime dtime cmp_ratio% datapoints
0-250b 215 189 0.001 0.000 12.40 91280
250-500b 438 404 0.001 0.000 7.85 13217
500-1KB 761 701 0.001 0.000 7.86 11434
1KB-10KB 4149 3547 0.001 0.000 14.51 52180
10KB-100KB 41934 32604 0.005 0.001 22.25 82890
100KB-200KB 146303 108080 0.016 0.001 26.13 29886
200KB-300KB 243299 179281 0.025 0.002 26.31 25066
300KB-400KB 344636 266177 0.036 0.003 22.77 4956
400KB-500KB 463201 356862 0.046 0.004 22.96 3167
500KB-600KB 545123 429854 0.056 0.005 21.15 366
600KB-700KB 647736 510931 0.065 0.006 21.12 254
700KB-800KB 746540 587287 0.073 0.008 21.33 294
800KB-900KB 868121 682650 0.087 0.008 21.36 199
900KB-1MB 945747 726307 0.091 0.010 23.20 304
On 10/11/2015 8:46 AM, Jeff Garzik via bitcoin-dev wrote:
> Comments:
>
> 1) cblock seems a reasonable way to extend the protocol. Further
> wrapping should probably be done at the stream level.
>
> 2) zlib has crappy security track record.
>
> 3) A fallback path to non-compressed is required, should compression
> fail or crash.
>
> 4) Most blocks and transactions have runs of zeroes and/or highly
> common bit-patterns, which contributes to useful compression even at
> smaller sizes. Peter Ts's most recent numbers bear this out. zlib
> has a dictionary (32K?) which works well with repeated patterns such
> as those you see with concatenated runs of transactions.
>
> 5) LZO should provide much better compression, at a cost of CPU
> performance and using a less-reviewed, less-field-tested library.
>
>
>
>
>
> On Tue, Nov 10, 2015 at 11:30 AM, Tier Nolan via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
>
> On Tue, Nov 10, 2015 at 4:11 PM, Peter Tschipper
> <peter.tschipper at gmail.com <mailto:peter.tschipper at gmail.com>> wrote:
>
> There are better ways of sending new blocks, that's certainly
> true but for sending historical blocks and seding transactions
> I don't think so. This PR is really designed to save
> bandwidth and not intended to be a huge performance
> improvement in terms of time spent sending.
>
>
> If the main point is for historical data, then sticking to just
> blocks is the best plan.
>
> Since small blocks don't compress well, you could define a
> "cblocks" message that handles multiple blocks (just concatenate
> the block messages as payload before compression).
>
> The sending peer could combine blocks so that each cblock is
> compressing at least 10kB of block data (or whatever is optimal).
> It is probably worth specifying a maximum size for network buffer
> reasons (either 1MB or 1 block maximum).
>
> Similarly, transactions could be combined together and compressed
> "ctxs". The inv messages could be modified so that you can
> request groups of 10-20 transactions. That would depend on how
> much of an improvement compressed transactions would represent.
>
> More generally, you could define a message which is a compressed
> message holder. That is probably to complex to be worth the
> effort though.
>
>
>
>>
>> On Tue, Nov 10, 2015 at 5:40 AM, Johnathan Corgan via
>> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> On Mon, Nov 9, 2015 at 5:58 PM, gladoscc via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>>
>> I think 25% bandwidth savings is certainly
>> considerable, especially for people running full
>> nodes in countries like Australia where internet
>> bandwidth is lower and there are data caps.
>>
>>
>> This reinforces the idea that such trade-off decisions
>> should be be local and negotiated between peers, not a
>> required feature of the network P2P.
>>
>>
>> --
>> Johnathan Corgan
>> Corgan Labs - SDR Training and Development Services
>> http://corganlabs.com
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151111/b008e0c1/attachment.html>

2023-06-07 17:44:22

- reply

📅 Original date posted:2015-11-10
📝 Original message:On 10/11/2015 8:11 AM, Peter Tschipper wrote:
> On 10/11/2015 1:44 AM, Tier Nolan via bitcoin-dev wrote:
>> The network protocol is not quite consensus critical, but it is
>> important.
>>
>> Two implementations of the decompressor might not be bug for bug
>> compatible. This (potentially) means that a block could be designed
>> that won't decode properly for some version of the client but would
>> work for another. This would fork the network.
>>
>> A "raw" network library is unlikely to have the same problem.
>>
>> Rather than just compress the stream, you could compress only block
>> messages only. A new "cblock" message could be created that is a
>> compressed block. This shouldn't reduce efficiency by much.
>>
> I chose the more generic datastream compression so we could in the
> future apply to possibly to transactions but currently all that is
> planned, is to compress blocks, and that was really my only original
> intent until I saw that there might be some bandwidth savings for
> transactions as well.
>
> The compression however could be applied to any datastream but is not
> *forced* . Basically it would just be a method call in CDatastream so
> we could do ss.compress and ss.decompress and apply that to blocks and
> possibly transactions if worthwhile and only IF compression is turned
> on. But there is no intend to apply this to every type of message
> since most would be too small to benefit from compression.
>
> Here are some results of using the code in the PR to
> compress/decompress blocks using zlib compression level = 6. This
> data was taken from the first 275K blocks in the mainnet blockchain.
> Clearly once we get past 10KB we get pretty decent compression but
> even below that there is some benefit. I'm still collecting data and
> will get the same for the whole blockchain.
>
> range = block size range
> ubytes = average size of uncompressed blocks
> cbytes = average size of compressed blocks
> ctime = average time to compress
> dtime = average time to decompress
> cmp_ratio% = compression ratio
> datapoints = number of datapoints taken
>
> range ubytes cbytes ctime dtime cmp_ratio% datapoints
> 0-250b 215 189 0.001 0.000 12.41 79498
> 250-500b 440 405 0.001 0.000 7.82 11903
> 500-1KB 762 702 0.001 0.000 7.83 10448
> 1KB-10KB 4166 3561 0.001 0.000 14.51 50572
> 10KB-100KB 40820 31597 0.005 0.001 22.59 75555
> 100KB-200KB 146238 106320 0.015 0.001 27.30 25024
> 200KB-300KB 242913 175482 0.025 0.002 27.76 20450
> 300KB-400KB 343430 251760 0.034 0.003 26.69 2069
> 400KB-500KB 457448 343495 0.045 0.004 24.91 1889
> 500KB-600KB 540736 424255 0.056 0.007 21.54 90
> 600KB-700KB 647851 506888 0.063 0.007 21.76 59
> 700KB-800KB 749513 586551 0.073 0.007 21.74 48
> 800KB-900KB 859439 652166 0.086 0.008 24.12 39
> 900KB-1MB 952333 725191 0.089 0.009 23.85 78
>
>> If a client fails to decode a cblock, then it can ask for the block
>> to be re-sent as a standard "block" message.
> interesting idea.
>>
>> This means that it is a pure performance improvement. If problems
>> occur, then the client can just switch back to uncompressed mode for
>> that block.
>>
>> You should look into the block relay system. This gives a larger
>> improvement than simply compressing the stream. The main benefit is
>> latency but it means that actual blocks don't have to be sent, so
>> gives a potential 50% compression ratio. Normally, a node receives
>> all the transactions and then those transactions are included later
>> in the block.
>>
> There are better ways of sending new blocks, that's certainly true but
> for sending historical blocks and seding transactions I don't think
> so. This PR is really designed to save bandwidth and not intended to
> be a huge performance improvement in terms of time spent sending.
>>
>> On Tue, Nov 10, 2015 at 5:40 AM, Johnathan Corgan via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> On Mon, Nov 9, 2015 at 5:58 PM, gladoscc via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>>
>> I think 25% bandwidth savings is certainly considerable,
>> especially for people running full nodes in countries like
>> Australia where internet bandwidth is lower and there are
>> data caps.
>>
>>
>> This reinforces the idea that such trade-off decisions should be
>> be local and negotiated between peers, not a required feature of
>> the network P2P.
>>
>>
>> --
>> Johnathan Corgan
>> Corgan Labs - SDR Training and Development Services
>> http://corganlabs.com
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151110/a9fefde7/attachment.html>

2023-06-07 17:44:21

- reply

📅 Original date posted:2015-11-09
📝 Original message:This is my first time through this process so please bear with me.
I opened a PR #6973 this morning for Zlib Block Compression for block
relay and at the request of @sipa this should have a BIP associated
with it. The idea is simple, to compress the datastream before
sending, initially for blocks only but it could theoretically be done
for transactions as well. Initial results show an average of 20% block
compression and taking 90 milliseconds for a full block (on a very slow
laptop) to compress. The savings will be mostly in terms of less
bandwidth used, but I would expect there to be a small performance gain
during the transmission of the blocks particularly where network latency
is higher.
I think the BIP title, if accepted should be the more generic, "Support
for Datastream Compression" rather than the PR title of "Zlib
Compression for block relay" since it could also be used for
transactions as well at a later time.
Thanks for your time...