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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <bitcoin-list@bluematt.me>) id 1TbFC9-0005tG-JY
for bitcoin-development@lists.sourceforge.net;
Wed, 21 Nov 2012 18:38:45 +0000
Received-SPF: pass (sog-mx-2.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-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1TbFC8-0002Er-A4 for bitcoin-development@lists.sourceforge.net;
Wed, 21 Nov 2012 18:38:45 +0000
Received: from [192.168.2.25] (69-36-219-195.dynamic.dsl.skybest.com
[69.36.219.195])
by mail.bluematt.me (Postfix) with ESMTPSA id 2742E5206
for <bitcoin-development@lists.sourceforge.net>;
Wed, 21 Nov 2012 18:38:38 +0000 (UTC)
Message-ID: <1353523117.1085.14.camel@localhost.localdomain>
From: Matt Corallo <bitcoin-list@bluematt.me>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 21 Nov 2012 13:38:37 -0500
In-Reply-To: <20121121151534.GA5540@vps7135.xlshosting.net>
References: <CANEZrP0XALwBFJyZTzYd5xBp4MRrjv0s_y2tOXbO7UgjWF2HzA@mail.gmail.com>
<20121121151534.GA5540@vps7135.xlshosting.net>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.6.2
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.8 (-)
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 SPF_PASS SPF: sender matches SPF record
-0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1TbFC8-0002Er-A4
Subject: Re: [Bitcoin-development] Draft BIP for Bloom filtering
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: Wed, 21 Nov 2012 18:38:45 -0000
On Wed, 2012-11-21 at 16:15 +0100, Pieter Wuille wrote:
> On Wed, Oct 24, 2012 at 05:56:07PM +0200, Mike Hearn wrote:
> > I've written a draft BIP describing the bloom filtering protocol
> > extension developed by myself and Matt.
> >
> > https://en.bitcoin.it/wiki/BIP_0037
>
> Two comments I made on the pullreq page, which are probably better discussed here:
> * The 0xFFFFFFFF/(n-1)*i seed value seems intended to result in large bit
> differences between the different hash function's seeds. Together with the tweak,
> however, the first and the last now get seeds tweak and tweak-1. I think
> something simpler like k1*i+k2*n+tweak is better (with k1 and k2 arbitrary large
> odd 32-bit integers).
Meh, sure, whatever...I dont really think the seed values matter
significantly (Murmur3 isnt that bad of a hash function...) (and the
original algorithm wont result in a significant bit difference between
the seeds in many cases).
> * I feel uneasy about the arbitrary filter parameters used for the implicitly
> created filter when sending filteradd without filterload. The server cannot be
> expected to make a reasonable guess how the client is going to use the filter,
> and the client still has to track how large the server-side filter grows anyway.
> I'd prefer to make this simply illegal (DoS 100): filteradd always requires an
> active filter.
I think there is some consensus here, and I have no problem doing it
this way (in large part, filteradd should not be used at all).
> Maybe the actual filter data in filterload can be made optional:
> if it is omitted, it's assumed to be all zeroes (though that would mean the size
> has to be specified).
>
I'm not sure here, if you are sending a filter just to use filteradd to
add things to it manually, you are doing something very, very, very
wrong... Though we could certainly do some kind of compressed bloom
filter encoding to allow for small filter loads (loading the few things
you need to filteradd right away) where you anticipate adding
significantly more filter elements down the road (can anyone even come
up with a case where you anticipate doing this?), the filter is small
enough (max 36kB) that I see little benefit for the large increase in
complexity (or is this another repeat of the merkle branch discussion?)
Matt
|
