Date: Wed, 24 Oct 2012 18:22:56 +0200
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20121024162255.GA30290@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
> 
> Please read it and let me know if there are any missing details or
> things which sound wrong.

Some questions:
* why limit the number of matching transactions to 255?
* what does "each hash and key in the output script" mean exactly? what about the output script in its entirety?
* is sharing parts of the merkle branches not worth it?

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

I'm not in favor of stuffing too much into the version message, it already seems overloaded.
A byte with some bit-flags is fine by me - higher bits can later be added for other boolean
flags.

-- 
Pieter