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
82
83
84
85
86
87
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1SfWW8-0007FG-9f
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 13:24:48 +0000
Received-SPF: pass (sog-mx-1.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-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1SfWW2-0003zg-LU for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 13:24:48 +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 BB94A398F;
Fri, 15 Jun 2012 13:19:07 +0000 (UTC)
Message-ID: <1339766346.31489.49.camel@bmthinkpad>
From: Matt Corallo <bitcoin-list@bluematt.me>
To: Mike Hearn <mike@plan99.net>
Date: Fri, 15 Jun 2012 15:19:06 +0200
In-Reply-To: <CANEZrP0kNZDByHpK2=UjP+ag0X1KmqHxnJdm=e_pWMitP4QvvA@mail.gmail.com>
References: <CA+8xBpecVQcTTbPxUm_3_GWC99dEd4=-VFWb+QT6jUy4rg8U4w@mail.gmail.com>
<CANEZrP0kNZDByHpK2=UjP+ag0X1KmqHxnJdm=e_pWMitP4QvvA@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: 1SfWW2-0003zg-LU
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 13:24:48 -0000
On Thu, 2012-06-14 at 13:52 +0200, 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?
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. Though its
generally a small amount of CPU time/memory, if we end up with a drastic
split between SPV nodes and only a few large network nodes, those nodes
may wish to limit the CPU/memory usage each node is allowed to use,
which may be important if you are serving 1000 SPV peers. It offers a
sort of negotiation between SPV client and full node instead of letting
the client specify it outright.
>
> > '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.
A series of CMerkleTx's might also end up redundantly encoding branches
of the merkle tree, so, yes as a part of the BIP/implementation, I would
say we probably want a CFilteredBlock or similar
|
