From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SfYgC-0004CV-9P for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 15:43:20 +0000 X-ACL-Warn: Received: from masada.superduper.net ([85.119.82.91]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1SfYg7-00054a-Su for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 15:43:20 +0000 Received: from 70-36-145-225.dsl.dynamic.sonic.net ([70.36.145.225] helo=[192.168.11.124]) by masada.superduper.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SfYfz-0007JD-Ng; Fri, 15 Jun 2012 16:43:08 +0100 Message-ID: <4FDB5808.2060506@superduper.net> Date: Fri, 15 Jun 2012 08:43:04 -0700 From: Simon Barber User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mike Hearn References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1SfYg7-00054a-Su 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 15:43:20 -0000 separate filterinit / filterload - so you can do a new filterload later on if your list changes, without the privacy implications of filteradd. Simon On Thu 14 Jun 2012 04:52:29 AM PDT, 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? > >> '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. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development