Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.53 as permitted sender)
	client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com;
	helo=mail-wg0-f53.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
Date: Wed, 24 Oct 2012 17:56:07 +0200
Message-ID: <CANEZrP0XALwBFJyZTzYd5xBp4MRrjv0s_y2tOXbO7UgjWF2HzA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Subject: [Bitcoin-development] Draft BIP for Bloom filtering
Precedence: list

I've written a draft BIP describing the bloom filtering protocol
extension developed by myself and Matt.

https://en.bitcoin.it/wiki/BIP_0037

(yes I know there's some kind of process around getting allocated a
number - it seems overkill for this).

Please read it and let me know if there are any missing details or
things which sound wrong.

Design-wise, it occurred to me as I wrote the BIP that the method of
delaying reception of invs is a bit ad-hoc. It may be better to have a
bloom filter be sent in the version message itself. On the other hand,
having a flag to delay invs means that the filter can be calculated in
parallel to bringing up the network connections. Whilst actually
making a Bloom filter is fast, with deterministic wallets you may need
to do a lot of calculations to find the keys to scan for.