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
|
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 <laanwj@gmail.com>) id 1YOqMQ-0000mP-7V
for bitcoin-development@lists.sourceforge.net;
Fri, 20 Feb 2015 16:23:26 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.171 as permitted sender)
client-ip=209.85.212.171; envelope-from=laanwj@gmail.com;
helo=mail-wi0-f171.google.com;
Received: from mail-wi0-f171.google.com ([209.85.212.171])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YOqMP-0002gl-Cl
for bitcoin-development@lists.sourceforge.net;
Fri, 20 Feb 2015 16:23:26 +0000
Received: by mail-wi0-f171.google.com with SMTP id hi2so4095281wib.4
for <bitcoin-development@lists.sourceforge.net>;
Fri, 20 Feb 2015 08:23:19 -0800 (PST)
X-Received: by 10.180.80.230 with SMTP id u6mr7149780wix.69.1424449092415;
Fri, 20 Feb 2015 08:18:12 -0800 (PST)
Received: from amethyst.lan (dhcp-089-098-016-041.chello.nl. [89.98.16.41])
by mx.google.com with ESMTPSA id l6sm42691195wjx.33.2015.02.20.08.18.10
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 20 Feb 2015 08:18:11 -0800 (PST)
Date: Fri, 20 Feb 2015 17:18:10 +0100 (CET)
From: Wladimir <laanwj@gmail.com>
To: Adam Back <adam@cypherspace.org>
In-Reply-To: <CALqxMTE2doZjbsUxd-e09+euiG6bt_J=_BwKY_Ni3MNK6BiW1Q@mail.gmail.com>
Message-ID: <alpine.DEB.2.10.1502201702220.10329@nzrgulfg.ivfhpber.pbz>
References: <CALqxMTE2doZjbsUxd-e09+euiG6bt_J=_BwKY_Ni3MNK6BiW1Q@mail.gmail.com>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 1.2 (+)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(laanwj[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
2.8 MALFORMED_FREEMAIL Bad headers on message from free email service
X-Headers-End: 1YOqMP-0002gl-Cl
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] bloom filtering, privacy
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, 20 Feb 2015 16:23:26 -0000
Hello Adam,
On Fri, 20 Feb 2015, Adam Back wrote:
> So I was wondering what about changing to committing a bloom filter of
> the addresses in the block. Its seems surprising no one thought of it
> that way before (as it seems obvious when you hear it) but that seems
> to address the privacy issues as the user can fetch the block bloom
> filters and then scan it in complete privacy. (Someone appeared on
> bitcoin wizards IRC a while back and made this observation.)
I have heard this idea of inverting the bloom filter before (possibly in
#bitcoin-wizards), and as I see it it would indeed improve the privacy.
Apart from privacy it would also lower the burden for nodes. A block scan
with bloom filter is effectively a cheap DoS on a node.
In addition to that it will also avoid the 'transaction withholding
attack' that is possible with the current bloom filtering, at least if the
filter is e.g. committed to in the block header.
The drawback would be overhead - the bloom filter per block will have a
significant size (to avoid false positives), and the client would have to
fetch entire blocks that have its transactions in it.
I don't think that is so bad in practice, after all the % of blocks that
will have transactions for a given wallet will generally be low, so the
block size is amortized in a way. Of course, if the block size would be
increased this would become worse.
Wladimir
|
