On December 3, 2015 7:02:20 AM GMT+08:00, Peter Tschipper
wrote:
>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 d
Gavin Andresen via bitcoin-dev
writes:
> On Wed, Dec 2, 2015 at 1:57 PM, Emin Gün Sirer <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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-spec
On Wed, Dec 2, 2015 at 1:57 PM, Emin Gün Sirer <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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-conta
Emin's email presents to me the idea of dictionaries that already contain
the data we'd want to compress. With 8 bytes of indexing data, we can
refer to a TxID or a Public Key or any existing part of the blockchain.
There are also data sequences like scripts that contain a few variable
chunks and
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
confi
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
My issue is more that its additional complexity and attack surface, and
for a very minor gain which should disappear with further optimization
elsewhere and less that we absolutely shouldn't add compression because
we're definitely gonna have issues.
On 12/02/15 20:16, Peter Tschipper via bitc
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, bu
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
If compression is to be used a custom compression algorithm should be
written.
Bitcoin data is largely incompressible outside of a tiny subset of fields.
On 12/01/2015 11:33 PM, Simon Liu via bitcoin-dev wrote:
> Hi Pavel,
>
> (my earlier email was moderated, so the list can only see it via your
Hi Pavel,
(my earlier email was moderated, so the list can only see it via your
reply),
Yes, an attacker could try and send malicious data to take advantage of
a compression library vulnerability... but is it that much worse than
existing attack vectors which might also result in denial of servi
> On 02 Dec 2015, at 00:44, Simon Liu wrote:
>
> Hi Matt/Pavel,
>
> Why is it scary/undesirable? Thanks.
Select your preferable compression library and google for it with +CVE.
E.g. in zlib:
http://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-1820/GNU-Zlib.html
…allows rem
> On 01 Dec 2015, at 06:28, Matt Corallo via bitcoin-dev
> 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.
I have the same opinion.
On the other h
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. If there were a massive improvement, I'd find it
acceptable, but the improvement you've shown really isn't all that mu
@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 sm
15 matches
Mail list logo
