Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Sh3oZ-0007o6-B4 for bitcoin-development@lists.sourceforge.net; Tue, 19 Jun 2012 19:10:11 +0000 Received-SPF: pass (sog-mx-4.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-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Sh3oV-00013r-4q for bitcoin-development@lists.sourceforge.net; Tue, 19 Jun 2012 19:10:11 +0000 Received: from [IPv6:2001:470:9ff2:1:221:ccff:fe5d:b72] (unknown [IPv6:2001:470:9ff2:1:221:ccff:fe5d:b72]) by mail.bluematt.me (Postfix) with ESMTPSA id 8C5C239D1; Tue, 19 Jun 2012 19:10:00 +0000 (UTC) Message-ID: <1340132998.6065.7.camel@bmthinkpad> From: Matt Corallo To: Mike Hearn Date: Tue, 19 Jun 2012 21:09:58 +0200 In-Reply-To: References: <1339766346.31489.49.camel@bmthinkpad> <1339771184.31489.53.camel@bmthinkpad> 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: 1Sh3oV-00013r-4q 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: Tue, 19 Jun 2012 19:10:11 -0000 On Sat, 2012-06-16 at 10:27 +0200, Mike Hearn wrote: > > I'd much rather have an overloaded node respond with 50% fp rate filters > > as an option if there aren't many full nodes available than simply > > disconnect SPV clients. > > I don't think the bloom filter settings have any impact on server-side > load ... a node still has to check every transaction against the > filter regardless of how that filter is configured, which means the > same amount of disk io and processing. > > How can you reduce load on a peer by negotiating different filter settings? Agreed, I was largely giving a reason why one may want to negotiate the filter settings in response to your question as to why it was done. As long as there are sane limits (you cant make a 1GB filter by specifying 0% fp and some crazy number of entires), filter negotiation largely isnt worth it (also prevents any floats from appearing in the p2p protocol, though in either case it shouldn't be able to cause issues). Matt