From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4038449C for ; 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 ; Wed, 22 Jul 2015 22:20:23 +0000 (UTC) Received: by padck2 with SMTP id ck2so144767044pad.0 for ; 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 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 , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--