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
88
89
90
91
92
93
94
95
96
97
98
99
|
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 <jgarzik@exmulti.com>) id 1SfWXn-0007Iy-7K
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 13:26:31 +0000
X-ACL-Warn:
Received: from mail-lpp01m010-f47.google.com ([209.85.215.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SfWXh-000424-KV
for bitcoin-development@lists.sourceforge.net;
Fri, 15 Jun 2012 13:26:31 +0000
Received: by lags15 with SMTP id s15so2258204lag.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 15 Jun 2012 06:26:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:x-originating-ip:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding:x-gm-message-state;
bh=QqM1pMu5f8bmj9PZxQfbMqkzWz86NfGcbI/oPgh/LAs=;
b=YRs3mBiHsjgizT8YEalZuY/Z8xgYnqMf4U0u1H01WrAgej88O/29oR8WdkNkciyoHc
1ALOHYxaFv1QykTk9Hy2eArhyP4HOhx7iYuLeYRgPuB0aGDaR/KktSWHicdy8rCkxLj/
L0ZECQ1982Sb/hdJ5oQdyar6awi52nQrrwAnBOSDYfK4Gui9xl8Q7ZYC92g9wR0NOZTd
2mDWt/raJ43aQ7pINGlQm66LQGxHPCvC6hhl2oc++nmuzCWh9yUOaSnM3HE6TUJbU5Z9
3UHSuokZuyGwJDFQoSOdQdYz0AcYJyHhxXWWtW7AJVpVa1v20cALm+1ErtTP6ApLRG87
BYmA==
MIME-Version: 1.0
Received: by 10.152.46.232 with SMTP id y8mr5594094lam.18.1339766779027; Fri,
15 Jun 2012 06:26:19 -0700 (PDT)
Received: by 10.114.19.70 with HTTP; Fri, 15 Jun 2012 06:26:18 -0700 (PDT)
X-Originating-IP: [2001:4830:1603:2:21c:c0ff:fe79:c8c2]
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>
Date: Fri, 15 Jun 2012 09:26:18 -0400
Message-ID: <CA+8xBpcwhQPQRe=stYb9xksLsTbiABKLS7PZnRtvPga6AmSg4Q@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmd8s9auGHlOlGxZMbkGqwEFZQh1yE1DikHh9w3hGdYLsdWOTFEIXBeF9JBKn8jwlhpIRRW
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1SfWXh-000424-KV
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:26:31 -0000
On Thu, Jun 14, 2012 at 7:52 AM, Mike Hearn <mike@plan99.net> wrote:
>> filterinit(false positive rate, number of elements): initialize
>> filterload(data): input a serialized bloom filter table metadata and dat=
a.
>
> Why not combine these two?
This is a fair point that sipa raised.
Consensus concluded that 'filterload' includes all necessary metadata
required to initialize a bloom filter. That implies 'filterinit'
would only be needed for 'filteradd'. If we don't think 'filteradd'
has a compelling use case, filterinit + filteradd can be dropped.
>> '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 =A0inv<->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.
Yes, the format is something that must be hashed out (no pun
intended). Need input from potential users about what information
they might need.
--=20
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com
|
