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
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <adam@cypherspace.org>) id 1W6iuC-0003sH-MY
for bitcoin-development@lists.sourceforge.net;
Fri, 24 Jan 2014 15:42:52 +0000
X-ACL-Warn:
Received: from mout.perfora.net ([74.208.4.195])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W6iuB-0000Fh-6y
for bitcoin-development@lists.sourceforge.net;
Fri, 24 Jan 2014 15:42:52 +0000
Received: from netbook (c107-70.i07-27.onvol.net [92.251.107.70])
by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis)
id 0MPDRo-1WB8ko3pxI-0057uS; Fri, 24 Jan 2014 10:42:44 -0500
Received: by netbook (Postfix, from userid 1000)
id 6B9772E27DB; Fri, 24 Jan 2014 16:42:36 +0100 (CET)
Received: by flare (hashcash-sendmail, from uid 1000);
Fri, 24 Jan 2014 16:42:35 +0100
Date: Fri, 24 Jan 2014 16:42:35 +0100
From: Adam Back <adam@cypherspace.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20140124154235.GA3741@netbook.cypherspace.org>
References: <CAAS2fgQmsxjkQFSiCdeMoVMaqq5720KpUpdkKZOE+XytHsWw0w@mail.gmail.com>
<20140124090218.GA15398@savin>
<CANEZrP0MnXr4xjaMPg7v7vTiDQr-y7esvEBE=xk=Y0BUGXak9A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
In-Reply-To: <CANEZrP0MnXr4xjaMPg7v7vTiDQr-y7esvEBE=xk=Y0BUGXak9A@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:140124:mike@plan99.net::mww4o7JlXilkHut3:003+SE
X-Hashcash: 1:20:140124:pete@petertodd.org::m9EwSD5V1MhhXvTU:0000000000000000000
00000000000000000000000007mv
X-Hashcash: 1:20:140124:bitcoin-development@lists.sourceforge.net::LbL1hxFfFuxk3
HdF:000000000000000000001Pls
X-Hashcash: 1:20:140124:adam@cypherspace.org::NpRkWKHPPkJxKc8H:00000000000000000
000000000000000000000000119X
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V02:K0:hGhHQ6Fo/V3PMo8t8LsEmRQe9IQrhxnVFFPLskS5R8J
Z6hQIho9ic4IP0SkRzxIkIIqxs2v+ANS9detTJLP01hJOoe9+B
GEBadbgUTvfRA+P+K4fo1vJWZcVaz2upXVOgh5VePVJyqpeH/Z
DgoKeloIUunDvDEtp0Grgp14+7uMGxh1/zKNR50uP5rMXG53/p
a02HvK1xH05sxZEjLXO8+be0i0+O/+GseJ+P/IlKDPc4r6Exkx
heLI+V1kB5DdOXLim/W3nWe5Durg+hDLMNtCUFyTja5qo4GG//
3zxGSi23BONq7dMDNDURY/J88ZPWaBE1UlIyz4UaeOl9qm4/+D
fzJWzxurgBt3/LIb3kXEvuN/JykrrM7hHq8lP5Yxf
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
X-Headers-End: 1W6iuB-0000Fh-6y
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bait for reusable addresses
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, 24 Jan 2014 15:42:52 -0000
I think prefix has analysis side effects. There are (at least) 4 things
that link payments: the graph of payment flows, timing, precise amounts, =
IP
addresses, but with prefix a 5th: the prefix allows public elmination of
candidates connections, I think that may make network flow analysis even
more effective than it has been.
So SPV can be tuned as Mike just said, and as Greg pointed out somewhere
bloom is more private than prefix because its a wallet to node connection=
,
not a node broadcast, and Mike mentioned embedded Tor in another post to
boost node-capture issues with hostile network.
So reusable addresses are cool for full node recipients (0-bit prefix) or
trusted server offload (your own desktop, VPS, or trusted service provide=
r
node, and solve real problems for the use case of static and donation
addresses particularly with this second delegatable key for no-funds at r=
isk
search (which is even good as Jeremey said for your own node, in a offlin=
e
wallet use case).
Now while it would be clearly a very nice win if reusable addresses could=
be
made SPV-like in network characteristics and privacy, but we dont have a
plausible mechanism yet IMO. Close as we got was Greg's enhancement of
my/your "bloom bait"/"prefix" concept to make multiple candidate baits to
provide some ambiguity (still allows elimination, just slightly less of i=
t).
If we can find some efficient crypto to solve that last one, we could eve=
n
adopt them generally if it was efficient enough without needing interacti=
ve
one-use address release.
Maybe we should ask some math/theoretical crypto people if there is anyth=
ing
like public key watermarking or something that could solve this problem
efficiently.
For the related but different case of transaction level authenticity I li=
ke
Alan's server derived but communicated scalar & base to allow the client =
to
do at least TOFU.
Payment protocol may add another level of identity framework on top of TO=
FU
addresses (at a lower level than the payment messages defined now), and
without then needing a batch upload of offline signed secondary address
sigature that Mike described a while back, at least in person, maybe onli=
ne
somewhere (an add on with similar purpose and effect to Alan's TOFU, but
then with revocation, identity and certification for merchants).
I have not talked about payment protocols main app level function I think=
we
all understand and agree on the purpose and use of the server and optiona=
l
client certs in that. People may wish to add other cert types later (eg
PGP, SSH etc) but this version covers the common merchant tech, and allow=
s
client-side certs to be experimented with for identity also (eg imagine a=
s a
way to enrol with regulated entities like exchanges.)
Tell me if I am misunderstanding anything :)
Adam
On Fri, Jan 24, 2014 at 12:26:19PM +0000, Mike Hearn wrote:
> brittleness. The real world experience is that users, or to be exac=
t
> wallet authors, turn down SPV privacy parameters until bloom filter=
s
> have almost no privacy in exchange for little bandwidth usage.
>
> That's not fundamental though, it just reflects that the only
> implementation of this is used on a wide range of devices and doesn't
> yet have any notion of bandwidth modes or monitoring. It can and will
> be resolved at some point.=C2
|
