path: root/b7/802767d62d8fd3b986d2ada060865782fe237d

Return-Path: <fireduck@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 47B46491
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 16:41:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com
	[209.85.212.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EFD32235
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 16:41:34 +0000 (UTC)
Received: by wicgb10 with SMTP id gb10so106440927wic.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jul 2015 09:41:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:content-type; bh=SpYpeLmLjqO3iU7lqT1quk0NvU4lNQxDz3DGI4vwsuA=;
	b=qt24Zoi0SC4cbjQZQE6Pl4RLwmDok5a3hsc8jVMg4PiVLdTmq7M6sBWsbQZheMqd5s
	gQuF0Jhf93ZZNB/nfO/bQ+34+zjlJBFSbD//gmwFyFzVdyNmigYMIlDHUap9y0v+HLrY
	BOIq3FXC6QVg9Kk3iUKgqbLsxLQ6YKCy6Ql40losmZ8oqvyf+iUH+q5ys51UIdtVnBs3
	uTFTMpLNuvBYXqGaYoZoxPkejEA1qdmHQRyBwZytxsmnUjy6mJ+wVaMSlvF4uUR8QLRn
	akPmgyK88UvXPyx9qcWi7ZVIPniwEVJujEbehf5nfCubszyduXC9zwK/9F3dNvPxL1qN
	q8JA==
X-Received: by 10.194.246.105 with SMTP id xv9mr6739007wjc.135.1437583293719; 
	Wed, 22 Jul 2015 09:41:33 -0700 (PDT)
MIME-Version: 1.0
References: <55AFBBE6.3060702@electrum.org>
In-Reply-To: <55AFBBE6.3060702@electrum.org>
From: =?UTF-8?B?Sm9zZXBoIEdsZWFzb24g4pGI?= <fireduck@gmail.com>
Date: Wed, 22 Jul 2015 16:41:24 +0000
Message-ID: <CA+ASnrG_sNRio03pr_F6vSepucG66=R+n_x7xREYqKPXOo9hyw@mail.gmail.com>
To: Thomas Voegtlin <thomasv@electrum.org>,
	bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11c3a5368eabd7051b797175
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 16:41:36 -0000

--001a11c3a5368eabd7051b797175
Content-Type: text/plain; charset=UTF-8

I've thought about this as well, (in addition to making a java
implementation of the electrum server).

One solution would be for the client to combine all the addresses they are
interested in into a single bloom filter and send that to the server.

It would be pretty expensive for the server to check every address against
the bloom filter, but maybe for recent blocks (client can send how behind
they are) and for new transactions it wouldn't be bad at all.

The client could end up receiving a bunch of transactions they weren't
interested in but it would likely be manageable.

The client would also need to be fairly clever, including a set of static
ruse addresses and dynamic ruse addresses that they include in the filter.
That way a server would have a hard time using the bloom filter as a
fingerprint and figuring out which addresses are the real ones.

An alternative would be the server sending a bloom filter of addresses in
each block and then the client requesting entire blocks.  This would use
more bandwidth, but it seems like it would be pretty simple to implement
and give good anonymity.

Basically the idea is to spend more bandwidth and CPU to keep the server in
the dark on what the client really wants.

On Wed, Jul 22, 2015 at 8:51 AM Thomas Voegtlin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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 knows
> 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 servers
> 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 contains
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a11c3a5368eabd7051b797175
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ve thought about this as well, (in addition to makin=
g a java implementation of the electrum server).<div><br></div><div>One sol=
ution would be for the client to combine all the addresses they are interes=
ted in into a single bloom filter and send that to the server.</div><div><b=
r></div><div>It would be pretty expensive for the server to check every add=
ress against the bloom filter, but maybe for recent blocks (client can send=
 how behind they are) and for new transactions it wouldn&#39;t be bad at al=
l.</div><div><br></div><div>The client could end up receiving a bunch of tr=
ansactions they weren&#39;t interested in but it would likely be manageable=
.</div><div><br></div><div>The client would also need to be fairly clever, =
including a set of static ruse addresses and dynamic ruse addresses that th=
ey include in the filter.=C2=A0 That way a server would have a hard time us=
ing the bloom filter as a fingerprint and figuring out which addresses are =
the real ones.<br></div><div><br></div><div>An alternative would be the ser=
ver sending a bloom filter of addresses in each block and then the client r=
equesting entire blocks.=C2=A0 This would use more bandwidth, but it seems =
like it would be pretty simple to implement and give good anonymity.</div><=
div><br></div><div>Basically the idea is to spend more bandwidth and CPU to=
 keep the server in the dark on what the client really wants.</div><div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Jul 22, 2015 at 8:51 A=
M Thomas Voegtlin via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
Although Electrum clients connect to several servers in order to fetch<br>
block headers, they typically request address balances and address<br>
histories from a single server. This means that the chosen server knows<br>
that a given set of addresses belong to the same wallet. That is true<br>
even if Electrum is used over TOR.<br>
<br>
There have been various proposals to improve on that, but none of them<br>
really convinced me so far. One recurrent proposal has been to create<br>
subsets of wallet addresses, and to send them to separate servers. In my<br=
>
opinion, this does not really improve anonymity, because it requires<br>
trusting more servers.<br>
<br>
Here is an idea, inspired by TOR, on which I would like to have some<br>
feedback: We create an anonymous routing layer between Electrum servers<br>
and clients.<br>
<br>
* Each server S publishes a RSA public key, KS<br>
* Each client receives a list of available servers and their pubkeys<br>
* For each wallet address, addr_i, a client chooses a server S_i, and a<br>
RSA keypair (K_addr_i, k_addr_i)<br>
* The client creates a list of encrypted requests. Each request contains<br=
>
addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i<br>
* The client chooses a main server M, and sends the list of encrypted<br>
requests to M<br>
* M dispatches the client&#39;s requests to the corresponding servers S_i<b=
r>
(without the client&#39;s IP address.)<br>
* Each server decrypts the requests it receives, performs the request,<br>
and encrypts the result with K_addr_i<br>
* M receives encrypted responses, and forwards them to the client.<br>
* The client decrypts the encrypted response with k_addr_i<br>
<br>
What do you think? What are the costs and benefits of such an approach?<br>
<br>
(Note: this will not work if all servers, or a large fraction of them,<br>
are controlled by the same entity that controls M)<br>
<br>
<br>
Thomas<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>

--001a11c3a5368eabd7051b797175--