Date: Wed, 21 Nov 2012 16:15:35 +0100
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20121121151534.GA5540@vps7135.xlshosting.net>
References: <CANEZrP0XALwBFJyZTzYd5xBp4MRrjv0s_y2tOXbO7UgjWF2HzA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANEZrP0XALwBFJyZTzYd5xBp4MRrjv0s_y2tOXbO7UgjWF2HzA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Draft BIP for Bloom filtering
Precedence: list

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).
* 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. 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).

-- 
Pieter