From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TbFC9-0005tG-JY for bitcoin-development@lists.sourceforge.net; Wed, 21 Nov 2012 18:38:45 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bluematt.me designates 173.246.101.161 as permitted sender) client-ip=173.246.101.161; envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; Received: from vps.bluematt.me ([173.246.101.161] helo=mail.bluematt.me) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1TbFC8-0002Er-A4 for bitcoin-development@lists.sourceforge.net; Wed, 21 Nov 2012 18:38:45 +0000 Received: from [192.168.2.25] (69-36-219-195.dynamic.dsl.skybest.com [69.36.219.195]) by mail.bluematt.me (Postfix) with ESMTPSA id 2742E5206 for ; Wed, 21 Nov 2012 18:38:38 +0000 (UTC) Message-ID: <1353523117.1085.14.camel@localhost.localdomain> From: Matt Corallo To: bitcoin-development@lists.sourceforge.net Date: Wed, 21 Nov 2012 13:38:37 -0500 In-Reply-To: <20121121151534.GA5540@vps7135.xlshosting.net> References: <20121121151534.GA5540@vps7135.xlshosting.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1TbFC8-0002Er-A4 Subject: Re: [Bitcoin-development] Draft BIP for Bloom filtering X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 18:38:45 -0000 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