Subject: Re: [Bitcoin-development] Draft BIP for Bloom filtering

From: Gregory Maxwell <[email-masked]>
Date: Thu, 25 Oct 2012 12:56:39 -0400

On Wed, Oct 24, 2012 at 11:56 AM, Mike Hearn <[email-masked]> 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

Thanks for taking the time to write this up.

I still don't understand what purpose the apparently gratuitous
inefficiency of constantly resending common tree fragments. There are
many points of complexity in this protocol— handling premature
disconnections without missing blocks, the actual implementation of
the hash functions for the filter, validation of the hash tree, etc.
Presumably these components will just get implemented a few times in
some carefully constructed library code, so I don't see an
implementation complexity argument here— except the fact that it isn't
what Matt has implemented so far.

The current design can cause massive overhead compared to pulling an
unfiltered block should a filter be somewhat overboard and also makes
this filtering useless for applications which would select a small but
not tiny subset of the transactions (e.g. 10%).

Also, it's not mentioned in the page— but the hash function used is
not cryptographically strong,  so what prevents a complexity (well,
bandwidth in this case) attack?  someone could start using txids and
txouts that collide with the maximum number of other existing txouts
in order to waste bandwidth for people.  Is this avenue of attack not
a concern?