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 ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
