From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SfWW8-0007FG-9f for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 13:24:48 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bluematt.me designates 173.246.101.161 as permitted sender) client-ip=173.246.101.161; envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; Received: from vps.bluematt.me ([173.246.101.161] helo=mail.bluematt.me) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1SfWW2-0003zg-LU for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 13:24:48 +0000 Received: from [IPv6:2001:470:9ff2:1:ee55:f9ff:fec6:e666] (unknown [IPv6:2001:470:9ff2:1:ee55:f9ff:fec6:e666]) by mail.bluematt.me (Postfix) with ESMTPSA id BB94A398F; Fri, 15 Jun 2012 13:19:07 +0000 (UTC) Message-ID: <1339766346.31489.49.camel@bmthinkpad> From: Matt Corallo To: Mike Hearn Date: Fri, 15 Jun 2012 15:19:06 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.2-1 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1SfWW2-0003zg-LU Cc: Bitcoin Development Subject: Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 13:24:48 -0000 On Thu, 2012-06-14 at 13:52 +0200, Mike Hearn wrote: > > filterinit(false positive rate, number of elements): initialize > > filterload(data): input a serialized bloom filter table metadata and data. > > Why not combine these two? I believe its because it allows the node which will have to use the bloom filter to scan transactions to chose how much effort it wants to put into each transaction on behalf of the SPV client. Though its generally a small amount of CPU time/memory, if we end up with a drastic split between SPV nodes and only a few large network nodes, those nodes may wish to limit the CPU/memory usage each node is allowed to use, which may be important if you are serving 1000 SPV peers. It offers a sort of negotiation between SPV client and full node instead of letting the client specify it outright. > > > '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. A series of CMerkleTx's might also end up redundantly encoding branches of the merkle tree, so, yes as a part of the BIP/implementation, I would say we probably want a CFilteredBlock or similar