1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1SfXgs-000790-8b
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 14:39:58 +0000
Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1SfXgm-000305-K5 for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 14:39:58 +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 5BCE0398A;
Fri, 15 Jun 2012 14:39:46 +0000 (UTC)
Message-ID: <1339771184.31489.53.camel@bmthinkpad>
From: Matt Corallo <bitcoin-list@bluematt.me>
To: Mike Hearn <mike@plan99.net>
Date: Fri, 15 Jun 2012 16:39:44 +0200
In-Reply-To: <CANEZrP3jj2ymQPH50g2PvzZhRzTnUnCLUjvBYj8ndBCJsnGJ-w@mail.gmail.com>
References: <CA+8xBpecVQcTTbPxUm_3_GWC99dEd4=-VFWb+QT6jUy4rg8U4w@mail.gmail.com>
<CANEZrP0kNZDByHpK2=UjP+ag0X1KmqHxnJdm=e_pWMitP4QvvA@mail.gmail.com>
<1339766346.31489.49.camel@bmthinkpad>
<CANEZrP3jj2ymQPH50g2PvzZhRzTnUnCLUjvBYj8ndBCJsnGJ-w@mail.gmail.com>
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: 1SfXgm-000305-K5
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2012 14:39:58 -0000
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.
|
