public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <bitcoin-list@bluematt•me>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Draft BIP for Bloom filtering
Date: Wed, 21 Nov 2012 13:38:37 -0500	[thread overview]
Message-ID: <1353523117.1085.14.camel@localhost.localdomain> (raw)
In-Reply-To: <20121121151534.GA5540@vps7135.xlshosting.net>

On Wed, 2012-11-21 at 16:15 +0100, Pieter Wuille wrote:
> On Wed, Oct 24, 2012 at 05:56:07PM +0200, Mike Hearn wrote:
> > I've written a draft BIP describing the bloom filtering protocol
> > extension developed by myself and Matt.
> > 
> > https://en.bitcoin.it/wiki/BIP_0037
> 
> Two comments I made on the pullreq page, which are probably better discussed here:
> * The 0xFFFFFFFF/(n-1)*i seed value seems intended to result in large bit
>   differences between the different hash function's seeds. Together with the tweak,
>   however, the first and the last now get seeds tweak and tweak-1. I think
>   something simpler like k1*i+k2*n+tweak is better (with k1 and k2 arbitrary large
>   odd 32-bit integers).
Meh, sure, whatever...I dont really think the seed values matter
significantly (Murmur3 isnt that bad of a hash function...) (and the
original algorithm wont result in a significant bit difference between
the seeds in many cases).
> * I feel uneasy about the arbitrary filter parameters used for the implicitly
>   created filter when sending filteradd without filterload. The server cannot be
>   expected to make a reasonable guess how the client is going to use the filter,
>   and the client still has to track how large the server-side filter grows anyway.
>   I'd prefer to make this simply illegal (DoS 100): filteradd always requires an
>   active filter.
I think there is some consensus here, and I have no problem doing it
this way (in large part, filteradd should not be used at all).
> Maybe the actual filter data in filterload can be made optional:
>   if it is omitted, it's assumed to be all zeroes (though that would mean the size
>   has to be specified).
> 
I'm not sure here, if you are sending a filter just to use filteradd to
add things to it manually, you are doing something very, very, very
wrong... Though we could certainly do some kind of compressed bloom
filter encoding to allow for small filter loads (loading the few things
you need to filteradd right away) where you anticipate adding
significantly more filter elements down the road (can anyone even come
up with a case where you anticipate doing this?), the filter is small
enough (max 36kB) that I see little benefit for the large increase in
complexity (or is this another repeat of the merkle branch discussion?)

Matt




  reply	other threads:[~2012-11-21 18:38 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-24 15:56 Mike Hearn
2012-10-24 16:22 ` Pieter Wuille
2012-10-24 16:35   ` Mike Hearn
2012-10-24 17:11     ` Pieter Wuille
2012-10-24 18:54       ` Gavin Andresen
2012-10-24 19:00         ` Matt Corallo
2012-10-24 19:10         ` Mike Hearn
2012-10-24 20:29           ` Gavin Andresen
2012-10-24 20:58             ` Mike Hearn
2012-10-24 21:55             ` Jeff Garzik
2012-10-25 16:56 ` Gregory Maxwell
2012-10-25 17:01   ` Gregory Maxwell
2012-10-26 14:01   ` Mike Hearn
2012-10-26 14:17     ` Gregory Maxwell
2012-10-26 14:21       ` Mike Hearn
2012-10-26 14:34         ` Gregory Maxwell
2012-11-06 19:14     ` Pieter Wuille
2012-11-21 15:15 ` Pieter Wuille
2012-11-21 18:38   ` Matt Corallo [this message]
2012-11-27 21:10     ` Pieter Wuille
2013-01-10 15:21       ` Mike Hearn
2013-01-11  3:59         ` Matt Corallo
2013-01-11  5:02           ` Jeff Garzik
2013-01-11 14:11             ` Mike Hearn
2013-01-11 14:13               ` Mike Hearn
2013-01-16 10:43                 ` Mike Hearn
2013-01-16 15:00                   ` Matt Corallo
2013-01-18 16:38                     ` Mike Hearn
2013-01-19  9:51                       ` Andreas Schildbach
2013-01-30 11:09                     ` Mike Hearn
2013-01-30 11:13                       ` Mike Hearn
2013-02-06 16:33                         ` Mike Hearn
2013-02-06 16:45                           ` Gregory Maxwell
2013-02-20 12:44                             ` Mike Hearn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1353523117.1085.14.camel@localhost.localdomain \
    --to=bitcoin-list@bluematt$(echo .)me \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox