On Wed, Oct 24, 2012 at 11:56 AM, Mike Hearn <m...@plan99.net> 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? ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
