On Sun, Nov 29, 2015 at 10:32:34PM -0500, Chris via bitcoin-dev wrote:
> On 11/16/2015 07:42 PM, Peter Todd via bitcoin-dev wrote:
> > Sequence is used for opting in as it is the only "free-form" field
> > available for that purpose. Opt-in per output was proposed as well by
> > Luke-Jr, however th
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
To collect things into one place, I was asked by Kanzure to cover
non-jgarzik block size BIPs in a quick summary, and the Scaling Bitcoin
conf folks have graciously allocated a bit of extra time for this.
e.g. BIP 100.5, 103, 105, 106 - "the serious ones"
If there is some input people would like
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
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
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
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
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
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
