From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xy1Sr-0004kb-Jp for bitcoin-development@lists.sourceforge.net; Mon, 08 Dec 2014 16:47:13 +0000 X-ACL-Warn: Received: from quidecco.de ([81.169.136.15]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Xy1Sq-0007wh-1C for bitcoin-development@lists.sourceforge.net; Mon, 08 Dec 2014 16:47:13 +0000 Received: from localhost (localhost [127.0.0.1]) by quidecco.de (Postfix) with SMTP id 6C492E1B59B; Mon, 8 Dec 2014 17:15:14 +0100 (CET) To: Mike Hearn From: Isidor Zeuner Content-Type: text/plain; charset=UTF-8; format=flowed References: <54760A50.201@riseup.net> <20141127020947.A13D2E19A09@quidecco.de> In-Reply-To: Message-Id: <20141208161514.6C492E1B59B@quidecco.de> Date: Mon, 8 Dec 2014 17:15:14 +0100 (CET) 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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1Xy1Sq-0007wh-1C 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: Mon, 08 Dec 2014 16:47:13 -0000 > > > > [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. > In order to get more synergy between Bitcoin users of varying skill levels, my suggestion would be a cleaner separation between technical mechanisms and policies (possibly suitable for users without technical skills). Core development would mean providing suitable mechanisms by which it is possible to run Bitcoin on different constraints. This may include ways to handle attacks specific to the Tor/Bitcoin combination. People who like to research what is possible with the protocol can then experiment on how these mechanisms can be used in order to mitigate these attacks. Finally, distributors of consumer wallets can use this research in order to distribute their wallet with policies which may be less prone to Tor-specific attacks. Or leave this out altogether if their audience has different expectations for connecting to Bitcoin. The tricky part is probably to figure out what is the greatest common denominator of what keeps Bitcoin stable and running while still leaving room for customized policies. But I think that separating concerns like this is better than letting a debate about how to mitigate certain Tor-related attacks evolve towards a debate about Tor or not Tor. > 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. > I think it would be very interesting to explore alternatives for Tor. But at this point, completely abandoning Tor would mean that users either have to agree to have their transactions correlated to their IP address, or to trust their transactions to a third party where they are not subject to the security guarantees Bitcoin's logic can provide anymore. In my opinion, it's a rather huge sacrifice. What I find interesting, however, is that a lot of suggestions I see with respect to attacks related to Tor/Bitcoin (including my own) involve some kind of extra effort required for Tor users on Bitcoin in order to protect themselves against these attacks. So, it may be interesting to explore if it is viable to think of Tor's privacy guarantees as coming for free. Going from there, if it cannot be guaranteed to work completely for free, the question would be to what extent the required extra effort should be a shared effort of the network, and to what extent users requiring the improved privacy should use their own resources in order to make it possible. Best regards, Isidor