From: Matt Corallo <bitcoin-list@bluematt•me>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients
Date: Fri, 15 Jun 2012 16:39:44 +0200 [thread overview]
Message-ID: <1339771184.31489.53.camel@bmthinkpad> (raw)
In-Reply-To: <CANEZrP3jj2ymQPH50g2PvzZhRzTnUnCLUjvBYj8ndBCJsnGJ-w@mail.gmail.com>
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.
next prev parent reply other threads:[~2012-06-15 14:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-13 20:46 Jeff Garzik
2012-06-14 11:52 ` Mike Hearn
2012-06-15 11:52 ` Mike Hearn
2012-06-15 13:19 ` Matt Corallo
2012-06-15 13:23 ` Mike Hearn
2012-06-15 14:39 ` Matt Corallo [this message]
2012-06-16 8:27 ` Mike Hearn
2012-06-19 19:09 ` Matt Corallo
2012-07-21 11:45 ` Mike Hearn
2012-07-23 7:54 ` Andreas Petersson
2012-07-23 16:40 ` Matt Corallo
2012-07-24 8:16 ` Mike Hearn
2012-06-15 13:26 ` Jeff Garzik
2012-06-15 13:43 ` Mike Hearn
2012-06-15 14:56 ` Matt Corallo
2012-06-15 15:32 ` Jeff Garzik
2012-06-15 16:20 ` Matt Corallo
2012-06-15 18:42 ` Amir Taaki
2012-06-16 8:25 ` Mike Hearn
2012-06-15 15:43 ` Simon Barber
2012-06-15 16:40 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1339771184.31489.53.camel@bmthinkpad \
--to=bitcoin-list@bluematt$(echo .)me \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox