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 n
Data compression adds latency and reduces predictability, so engineers have
decided to leave compression to application layers instead of transport layer
or lower in order to let the application designer decide what tradeoffs to make.
On Nov 11, 2015, at 10:49 AM, Marco Pontello via bitcoin-dev
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
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/lo
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
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
>> wrote:
>>
>> There are better ways of sending new blocks, that's certainly
>> true but for sending historical blocks and sed
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 ru
On Tue, Nov 10, 2015 at 4:11 PM, Peter Tschipper
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 im
Quick observation: block transmission would be compress-once,
send-multiple-times, which makes the tradeoff a little better.
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfound
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 t
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. Th
On Mon, Nov 9, 2015 at 5:58 PM, gladoscc via bitcoin-dev <
bitcoin-dev@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.
>
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.
I absolutely would not dismiss 25% compression. gzip and bzip2 compression
is relatively standard, and I'd consid
I would expect that since a block contains mostly hashes and crypto signatures,
it would be almost totally incompressible. I just calculated compression
ratios:
zlib-15%(file is LARGER)
gzip 28%
bzip225%
So zlib compression is right out. How much is ~25% bandwidth savings worth
On Mon, Nov 9, 2015 at 11:18 AM, Peter Tschipper via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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 compr
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 blo
16 matches
Mail list logo
