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
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
|
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 <adam@cypherspace.org>) id 1Wsret-0003Nx-IZ
for bitcoin-development@lists.sourceforge.net;
Fri, 06 Jun 2014 10:46:03 +0000
X-ACL-Warn:
Received: from mout.perfora.net ([74.208.4.195])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wsres-0001Mm-0V
for bitcoin-development@lists.sourceforge.net;
Fri, 06 Jun 2014 10:46:03 +0000
Received: from netbook (c31-67.i07-8.onvol.net [92.251.31.67])
by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis)
id 0MdJxT-1XAnsW1w1b-00I5u3; Fri, 06 Jun 2014 06:45:52 -0400
Received: by netbook (Postfix, from userid 1000)
id 1AD762E50DD; Fri, 6 Jun 2014 12:45:45 +0200 (CEST)
Received: by flare (hashcash-sendmail, from uid 1000);
Fri, 6 Jun 2014 12:45:43 +0200
Date: Fri, 6 Jun 2014 12:45:43 +0200
From: Adam Back <adam@cypherspace.org>
To: Peter Todd <pete@petertodd.org>
Message-ID: <20140606104543.GA31085@netbook.cypherspace.org>
References: <20140606081933.GA29458@savin>
<20140606084852.GA30247@netbook.cypherspace.org>
<20140606090441.GA19256@savin>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20140606090441.GA19256@savin>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:140606:pete@petertodd.org::K9fXyyVWf4SDgQqU:0000000000000000000
00000000000000000000000032h4
X-Hashcash: 1:20:140606:bitcoin-development@lists.sourceforge.net::jv8bOEjsAwvPF
O7m:000000000000000000001hC1
X-Hashcash: 1:20:140606:gmaxwell@gmail.com::sEqudymqk9pibwcg:0000000000000000000
0000000000000000000000004S4p
X-Hashcash: 1:20:140606:adam@cypherspace.org::KXswWufdw6O8i3GM:00000000000000000
00000000000000000000000002Gx
X-Provags-ID: V02:K0:wv2JYSWEG8DSRF075xyeBrV1X0IXVLLWDqdJuCooSy8
zi0ZNiODeb4iP/RjC1nDgPj4Fl46Ai8G6kkd+NvJcItVa0JMmq
GYPQnOelfFRaUAxeT2sYXbB42MTB8OjbOB+xmBvo4S2ml2kWwH
EJwYoUkdv+lszcIsrfsDnKmpD8GtoWyyRxv8hOLhQuDBeFvk3H
v0I8i5i8CYkyRv2L/fEaYm9jzU1VtGjHaJgx603CW0WIZUPC36
ObDlU5I42BEzZWDN1wsKkBx0thDXMIcr4nWhJSpTt7Ze2T+Po5
uzmD1ZazC2YkVg+aj9KUIadA3Hd0RLukEyIn1n3QHPGDJJw5F0
P74T53zgP+kSNYmemR15+72AK8KplY0yOSFbTVoKG
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [74.208.4.195 listed in list.dnswl.org]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.0 T_FILL_THIS_FORM_SHORT Fill in a short form with personal
information
X-Headers-End: 1Wsres-0001Mm-0V
Cc: 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 10:46:03 -0000
On Fri, Jun 06, 2014 at 05:04:41AM -0400, Peter Todd wrote:
>On Fri, Jun 06, 2014 at 10:48:52AM +0200, Adam Back wrote:
>> Prefix filters offer questionable privacy tradeoffs in my opinion. Same
>> problem as with stealth address proposed use of prefixes.
>
>That's assuming you're doing the proposed prefix brute forcing
As I recall prefix brute forcing was a bit twiddle saving, ie searching for
EDH key that has the users public prefix. That does not improve privacy
over an explicit prefix, it saves a byte or so at the expense of average 128
EDH exchanges to send and provides also some probably relatively ineffective
plausible deniability by enabling the transaction to be indistinguishable
from some other (not very common) types of transaction.
>don't do that they have privacy equal or better than bloom filters, but
>with better scalability.
either its full node only where prefixes are not used, which is less
scalable than bloom; or prefixes are used explicitly or implicitly
(brute-force) and either way privacy is weakened by the extra correlation
hook provided by elimination from the network graph of payments with
mismatched prefixes.
>In particular that better scalability lets you efficiently query multiple
>servers for blockchain data, only giving up info on a subset of the
>addresses in your wallet to each server. This can be a significant
>improvement to bloom filters if your attacker is running logging nodes to
>try to, say, deanonymize CoinJoin transactions.
We need to consider the two types of privacy involved. Privacy from the
full node an SPV client is relying on to find its payments, vs privacy from
analysis of the public transaction graph. The latter is more damaging.
Better to design for privacy against future analysis of public info, than
privacy by argument to select non-hostile nodes. Tor has changed recently
to account for the fact that chosing fresh random nodes is actually worse.
ie you have a probability of identity/address identification per route/node,
and repeatedly selecting routes/nodes just cumulatively increases the chance
you'll be identified. Better to pick a random node, identify it and stick
to it and hope you chose well.
>Now if you want to come up with something better and write code, please
>do! I'm sure the math exists; what doesn't exist is robust and well
>tested code in multiple languages.
Maybe other simpler, but yes there was the proof of concept that the math
exists in the form of the weil pairing.
https://bitcointalk.org/index.php?topic=431756.new
But what problem are we trying to solve here? Is it an immediate problem?
Maybe better to figure out a more privacy compatible solution which will
take longer, than let coding drive protocol.
Adam
|
