From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XtwuK-0000MN-Kg for bitcoin-development@lists.sourceforge.net; Thu, 27 Nov 2014 11:06:44 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.54 as permitted sender) client-ip=74.125.82.54; envelope-from=mh.in.england@gmail.com; helo=mail-wg0-f54.google.com; Received: from mail-wg0-f54.google.com ([74.125.82.54]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XtwuJ-0005Iw-Dr for bitcoin-development@lists.sourceforge.net; Thu, 27 Nov 2014 11:06:44 +0000 Received: by mail-wg0-f54.google.com with SMTP id l2so6157234wgh.41 for ; Thu, 27 Nov 2014 03:06:37 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.104.197 with SMTP id gg5mr12359062wib.7.1417086384977; Thu, 27 Nov 2014 03:06:24 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.194.89.130 with HTTP; Thu, 27 Nov 2014 03:06:24 -0800 (PST) In-Reply-To: References: <54760A50.201@riseup.net> <20141127020947.A13D2E19A09@quidecco.de> Date: Thu, 27 Nov 2014 12:06:24 +0100 X-Google-Sender-Auth: JLDwOMOZ9S5MpKKE5cJkd_i4NrM Message-ID: From: Mike Hearn To: Gregory Maxwell Content-Type: multipart/alternative; boundary=f46d041825bc97c0340508d522ec X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XtwuJ-0005Iw-Dr Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 11:06:44 -0000 --f46d041825bc97c0340508d522ec Content-Type: text/plain; charset=UTF-8 > > [As an aside I agree that there are lots of things to improve here, > but the fact that users can in theory be forced off of tor via DOS > attacks is not immediately concerning to me because its a conscious > choice users would make to abandon their privacy Bitcoin already has a large population of users who have little or no technical skill, it wouldn't surprise me at all if it was found to be the clear majority by now. Assuming success and growth in future, very few users will make any decisions at all about their privacy, they will just accept the defaults. In such a world no consumer wallet is going to directly expose Tor to end users - if used at all it'll just be used behind the scenes. So automated fallback or control over exits would be a concern for such wallets. My gut feeling about this stuff has changed over time. I don't think it'd be a great idea to tie Bitcoin to Tor too deeply, convenient though its infrastructure is. Most apps don't need a whole lot of onion routing - a small amount built in to the p2p layer would be sufficient. Tor is huge, complicated and could be a liability in future. --f46d041825bc97c0340508d522ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[As an aside I agree that there are lots of thin= gs to improve here,
but the fact that users can in theory be forced off of tor via DOS
attacks is not immediately concerning to me because its a conscious
choice users would make to abandon their privacy

Bitcoin already has a large population of users who have little or no= technical skill, it wouldn't surprise me at all if it was found to be = the clear majority by now. Assuming success and growth in future, very few = users will make any decisions at all about their privacy, they will just ac= cept the defaults. In such a world no consumer wallet is going to directly = expose Tor to end users - if used at all it'll just be used behind the = scenes. So automated fallback or control over exits would be a concern for = such wallets.

My gut feeling about this stuff has = changed over time. I don't think it'd be a great idea to tie Bitcoi= n to Tor too deeply, convenient though its infrastructure is. Most apps don= 't need a whole lot of onion routing - a small amount built in to the p= 2p layer would be sufficient. Tor is huge, complicated and could be a liabi= lity in future.
--f46d041825bc97c0340508d522ec--