On Fri, 2012-06-15 at 15:23 +0200, Mike Hearn wrote: > > > 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. > > If that's the case then the negotiation protocol needs to be specified > too. It seems heavy though. If a node is getting overloaded it could > just disconnect intensive peers or refuse new connections. IMHO it already is. A node requests a filter using filterinit by specifying the false positive rate it wants and a guessed number of items. The node which will have to hold that filter then responds with the closest filter to what the SPV node requested that it is willing to provide. If the SPV node responds with a filterload command, it has accepted the offer, otherwise it will simply disconnect and find a better full node. 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. At least thats my thinking, but you may be right that it is too heavy for too little gain.
------------------------------------------------------------------------------ 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
