summaryrefslogtreecommitdiff
path: root/dc/00351ceb324e17d6ac1b229bd3bc9f66568ad9
blob: ae0868b82787fc553d4ed5e55ee0af659d4202f0 (plain)
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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pw@vps7135.xlshosting.net>) id 1TbC1l-0007Uo-W6
	for bitcoin-development@lists.sourceforge.net;
	Wed, 21 Nov 2012 15:15:50 +0000
X-ACL-Warn: 
Received: from vps7135.xlshosting.net ([178.18.90.41])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1TbC1g-000315-6N for bitcoin-development@lists.sourceforge.net;
	Wed, 21 Nov 2012 15:15:49 +0000
Received: by vps7135.xlshosting.net (Postfix, from userid 1000)
	id 7BE9D6117F; Wed, 21 Nov 2012 16:15:37 +0100 (CET)
Date: Wed, 21 Nov 2012 16:15:35 +0100
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20121121151534.GA5540@vps7135.xlshosting.net>
References: <CANEZrP0XALwBFJyZTzYd5xBp4MRrjv0s_y2tOXbO7UgjWF2HzA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANEZrP0XALwBFJyZTzYd5xBp4MRrjv0s_y2tOXbO7UgjWF2HzA@mail.gmail.com>
X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: 0.9 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(pieter.wuille[at]gmail.com)
	0.0 DKIM_ADSP_CUSTOM_MED   No valid author signature, adsp_override is
	CUSTOM_MED
	-0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain 1.2 NML_ADSP_CUSTOM_MED    ADSP custom_med hit,
	and not from a mailing list
	-0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1TbC1g-000315-6N
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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 15:15:50 -0000

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).
* 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. 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).

-- 
Pieter