summaryrefslogtreecommitdiff
path: root/fe/57d3580048dac898c257a7447a410b18970de7
blob: 4d8cd9ae0e12b3d34f9284b42dfe6c83b0182e4d (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
78
79
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gmaxwell@gmail.com>) id 1Wsq3l-0007xm-Dt
	for bitcoin-development@lists.sourceforge.net;
	Fri, 06 Jun 2014 09:03:37 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.174 as permitted sender)
	client-ip=209.85.217.174; envelope-from=gmaxwell@gmail.com;
	helo=mail-lb0-f174.google.com; 
Received: from mail-lb0-f174.google.com ([209.85.217.174])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Wsq3k-0006UY-GR
	for bitcoin-development@lists.sourceforge.net;
	Fri, 06 Jun 2014 09:03:37 +0000
Received: by mail-lb0-f174.google.com with SMTP id n15so1333523lbi.33
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 06 Jun 2014 02:03:29 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.20.168 with SMTP id o8mr623965lae.78.1402045409832; Fri,
	06 Jun 2014 02:03:29 -0700 (PDT)
Received: by 10.112.235.72 with HTTP; Fri, 6 Jun 2014 02:03:29 -0700 (PDT)
In-Reply-To: <20140606084852.GA30247@netbook.cypherspace.org>
References: <20140606081933.GA29458@savin>
	<20140606084852.GA30247@netbook.cypherspace.org>
Date: Fri, 6 Jun 2014 02:03:29 -0700
Message-ID: <CAAS2fgTsjZPxds+QHb+ceC_Thu4xsDFAEqXtxznCs_EbyLZepg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
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
	(gmaxwell[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
X-Headers-End: 1Wsq3k-0006UY-GR
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] NODE_BLOOM service bit
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, 06 Jun 2014 09:03:37 -0000

On Fri, Jun 6, 2014 at 1:48 AM, Adam Back <adam@cypherspace.org> wrote:
> Advertising NODE BLOOM as a service sounds good.
>
> But the critique of bloom filters, I am not so sure prefix filters are
> better.  Prefix filters offer questionable privacy tradeoffs in my opinion.
> Same problem as with stealth address proposed use of prefixes.
>
> All for scalability, efficiency and decentralization but not ideally at the
> expense of nuking privacy.  The effects on privacy are cumulative, and
> affect everyone not just the user.  Same pattern of local decision, global
> effect as with reused addresses.

The performance Bytecoin/Monero/Fantom/etc. systems that use ECDH
addresses for all transactions seem to be suggesting that the prefixes
aren't really needed.

At least with current system rules doing the ECDH for each transaction
seems pretty reasonable.