From: Pieter Wuille <pieter.wuille@gmail•com>
To: Matt Corallo <bitcoin-list@bluematt•me>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Draft BIP for Bloom filtering
Date: Tue, 27 Nov 2012 22:10:23 +0100 [thread overview]
Message-ID: <20121127211019.GA22701@vps7135.xlshosting.net> (raw)
In-Reply-To: <1353523117.1085.14.camel@localhost.localdomain>
On Wed, Nov 21, 2012 at 01:38:37PM -0500, Matt Corallo wrote:
> 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).
Sure, it's nothing important, but it seems like it fails to do what it was intended for.
How about just this: tweak + i*0xFBA4C795 (number optimized to give large seed
differences for every tweak). If you want variation when changing the number of hash
functions, just choose a different seed.
> > 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?)
It's probably not worth it for something that is max 36 kilobytes. If ever
necessary, we can define a new message type that just lists a number of bits to
be set in the server-side filter.
For now, I agree that you should just send the filter as intended, and not expect to
do many filteradds (though you should take the implicitly-added txids into
accounted when computing the filter size).
--
Pieter
next prev parent reply other threads:[~2012-11-27 21:10 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
2012-11-27 21:10 ` Pieter Wuille [this message]
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=20121127211019.GA22701@vps7135.xlshosting.net \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=bitcoin-list@bluematt$(echo .)me \
/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