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
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4038449C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 22:20:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com
[209.85.220.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 38E8FEA
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 22:20:23 +0000 (UTC)
Received: by padck2 with SMTP id ck2so144767044pad.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jul 2015 15:20:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:subject:references:in-reply-to:content-type;
bh=Gl4YOcEqH4fo2G1oyDF4EBVnEBpJMU20tVxUtQ8n3Gw=;
b=P5jRlb8nr4cFrwESC8fZ72+aTnVeSW2f22NfGR16WpoZzaabvoD5GHrFvwioRgGlbp
NlVGnUCFah3tWMNcKF5zEekEzQfXWcvnqohl62zBNsRASF0DbQxWy7M/rDB8t4Hc3i4Q
4M06ArPiU75my4aD/R04muM9zmooR0u9eFljlLae8J2f2ZBRp27THp686ATy44ATDcKk
o7bIdpfwgI6VFJrvij7jf/7z/ea1HLLLkQu7vHEGRrSN719RsMCXo4BAdifjjYvoNbVk
hE6kwcNBqo9QwlN5J8c8yyy1IWrjwKAbF30lySvyfuaE8SC6vK/9I5WNG8gXT/bPW9ht
kY4g==
X-Gm-Message-State: ALoCoQla5+lpDSOu8YkbQTMY+62S/VKQKKDx3BrfPLzTq8reUFiHucRKDaLULihce4VZ1AuJkzmL
X-Received: by 10.66.141.232 with SMTP id rr8mr2017313pab.5.1437603622842;
Wed, 22 Jul 2015 15:20:22 -0700 (PDT)
Received: from [10.0.1.14] (c-67-161-88-20.hsd1.wa.comcast.net. [67.161.88.20])
by smtp.googlemail.com with ESMTPSA id
w10sm5101969pds.49.2015.07.22.15.20.21
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 22 Jul 2015 15:20:22 -0700 (PDT)
Message-ID: <55B01731.6070306@voskuil.org>
Date: Wed, 22 Jul 2015 15:20:33 -0700
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Thomas Voegtlin <thomasv@electrum.org>,
bitcoin-dev@lists.linuxfoundation.org
References: <55AFBBE6.3060702@electrum.org> <55AFC52C.3010700@voskuil.org>
In-Reply-To: <55AFC52C.3010700@voskuil.org>
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="Dx2wbHuTt4aCnMtbqGxIG0E8qG6MvEwBw"
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Making Electrum more anonymous
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 22:20:25 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Dx2wbHuTt4aCnMtbqGxIG0E8qG6MvEwBw
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
I should add that the obvious resolution to this set of problems is to
use a distinct Tor route for each Bitcoin address, not to reinvent Tor
and reproduce its community. So ultimately this is easy to implement,
but the downside is performance.
But it's important to keep in mind that poor-performing perfect privacy
for address monitoring is trivial to achieve - just sync the full
blockchain.
Presumably if you don't trust a server to protect your privacy, you also
don't trust it with your money. So any robust privacy optimization would
at least be designed to support partial (SPV) chain clients. It would
also need to support wallet restoration from backup.
The level of privacy will always be a performance trade-off. The ideal
solution would allow a client to balance privacy against performance.
e
On 07/22/2015 09:30 AM, Eric Voskuil wrote:
> Hi Thomas,
>=20
> The scheme is essentially onion routing. The set of {M} are entry nodes=
> and the set of {S} are exit nodes. The weaknesses are as you would see
> in an analogous TOR implementation:
>=20
> (1) The lack of relay nodes {R} make collaboration between any subset o=
f
> {M} and {S} trivial.
>=20
> (2) OR is a mixnet, so the size of the network matters a lot.
>=20
> (3) The directory is a perpetual weakness.
>=20
> (4) Content is visible to the exit node (or the final service). This
> means each address must be passed via a distinct route to prevent
> correlation.
>=20
> e
>=20
> On 07/22/2015 08:51 AM, Thomas Voegtlin via bitcoin-dev wrote:
>> Hello,
>>
>> Although Electrum clients connect to several servers in order to fetch=
>> block headers, they typically request address balances and address
>> histories from a single server. This means that the chosen server know=
s
>> that a given set of addresses belong to the same wallet. That is true
>> even if Electrum is used over TOR.
>>
>> There have been various proposals to improve on that, but none of them=
>> really convinced me so far. One recurrent proposal has been to create
>> subsets of wallet addresses, and to send them to separate servers. In =
my
>> opinion, this does not really improve anonymity, because it requires
>> trusting more servers.
>>
>> Here is an idea, inspired by TOR, on which I would like to have some
>> feedback: We create an anonymous routing layer between Electrum server=
s
>> and clients.
>>
>> * Each server S publishes a RSA public key, KS
>> * Each client receives a list of available servers and their pubkeys
>> * For each wallet address, addr_i, a client chooses a server S_i, and =
a
>> RSA keypair (K_addr_i, k_addr_i)
>> * The client creates a list of encrypted requests. Each request contai=
ns
>> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
>> * The client chooses a main server M, and sends the list of encrypted
>> requests to M
>> * M dispatches the client's requests to the corresponding servers S_i
>> (without the client's IP address.)
>> * Each server decrypts the requests it receives, performs the request,=
>> and encrypts the result with K_addr_i
>> * M receives encrypted responses, and forwards them to the client.
>> * The client decrypts the encrypted response with k_addr_i
>>
>> What do you think? What are the costs and benefits of such an approach=
?
>>
>> (Note: this will not work if all servers, or a large fraction of them,=
>> are controlled by the same entity that controls M)
>>
>>
>> Thomas
>> _______________________________________________
>=20
--Dx2wbHuTt4aCnMtbqGxIG0E8qG6MvEwBw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVsBcxAAoJEDzYwH8LXOFOkf8H/380Gdwosy23lo79N56frILF
qZ7YtDAgtl6Qtg7uXQig+qdbUvQq96bvLhi3U3zFhtojvPtmUl7SZzLzIG+EbrEc
zBG/LOjmeDaNQva4Iv3+Qdzc/iuyzhGj0AiQp/t61LW96XRWazuARGDa+YFTSc00
XS41iz5kDS4ctCf2AVKB87zaUmVcnhL2y8JC+dZma8Qpzn2H7bj7E9kNw3V0a/kE
YiRCj7k7fOQEVG5wgLJFTVvrWeqYbdFtCOuUz7KKew0gmVLxoqvRKSIUaGfT1h13
qwi6ejfAzAe33I+UMggwQWwfPuK3SxROl+vShaiT3ehi7h2Jx5ghV0mn5yYbHcE=
=Jlp6
-----END PGP SIGNATURE-----
--Dx2wbHuTt4aCnMtbqGxIG0E8qG6MvEwBw--
|
