Received-SPF: pass (sog-mx-3.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
In-Reply-To: <CA+8xBpecVQcTTbPxUm_3_GWC99dEd4=-VFWb+QT6jUy4rg8U4w@mail.gmail.com>
References: <CA+8xBpecVQcTTbPxUm_3_GWC99dEd4=-VFWb+QT6jUy4rg8U4w@mail.gmail.com>
Date: Thu, 14 Jun 2012 13:52:29 +0200
Message-ID: <CANEZrP0kNZDByHpK2=UjP+ag0X1KmqHxnJdm=e_pWMitP4QvvA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@exmulti.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New P2P commands for diagnostics,
	SPV clients
Precedence: list

> filterinit(false positive rate, number of elements): initialize
> filterload(data): input a serialized bloom filter table metadata and data.

Why not combine these two?

> 'filterload' and 'filteradd' enable special behavior changes for
> 'mempool' and existing P2P commands, whereby only transactions
> matching the bloom filter will be announced to the connection, and
> only matching transactions will be sent inside serialized blocks.

Need to specify the format of how these arrive. It means that when a
new block is found instead of inv<->getdata<->block we'd see something
like  inv<->getdata<->merkleblock where a "merkleblock" structure is a
header + list of transactions + list of merkle branches linking them
to the root. I think CMerkleTx already knows how to serialize this,
but it redundantly includes the block hash which would not be
necessary for a merkleblock message.