From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XvORf-0002Cl-AZ for bitcoin-development@lists.sourceforge.net; Mon, 01 Dec 2014 10:43:07 +0000 X-ACL-Warn: Received: from quidecco.de ([81.169.136.15]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1XvORd-0005Wk-IJ for bitcoin-development@lists.sourceforge.net; Mon, 01 Dec 2014 10:43:07 +0000 Received: from localhost (localhost [127.0.0.1]) by quidecco.de (Postfix) with SMTP id 9E56EE170B7; Mon, 1 Dec 2014 11:42:58 +0100 (CET) From: Isidor Zeuner To: Gregory Maxwell Content-Type: text/plain; charset=UTF-8; format=flowed References: <54760A50.201@riseup.net> <20141127020947.A13D2E19A09@quidecco.de> In-Reply-To: Message-Id: <20141201104258.9E56EE170B7@quidecco.de> Date: Mon, 1 Dec 2014 11:42:58 +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: 1XvORd-0005Wk-IJ 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, 01 Dec 2014 10:43:07 -0000 Hi Gregory, response below quote: > > Since this attack vector has been discussed, I started making some > > measurements on how effective it is to connect to Bitcoin using Tor, > > and I found that the number of connections dropping to near-zero is > > a situation which occurs rather frequently, which suggests that there > > is still room to improve on the DoS handling. > > I'm confused by this, I run quite a few nodes exclusively on tor and > chart their connectivity and have seen no such connection dropping > behaviour. > > Can you tell me more about how you measured this? > When you say "running exclusively on Tor", what do you mean exactly? Do you also connect or allow connections through hidden services? I made outbound connections through Tor exit points the only way to connect to Bitcoin, and increased the number of allowed outbound connection in order to get more meaningful values. Lately, I could see unusual behaviour at: * 2014-11-28 13:14 UTC * 2014-11-25 07:32 UTC * 2014-11-24 13:06 UTC Anything I should look into? > [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 (and the behaviour of > the system here is known and intentional). There are other mechanisms > available for people to relay their transactions than connecting > directly to the bitcoin network; so their choice isn't just abandon > privacy or don't use bitcoin at all.] > I think this issue is more important than it seems. Firstly, when running Tor-only, there are still attack vectors which make use of the DoS protection deficiencies. Secondly, if we tell people not to connect directly if they want privacy, how do we ensure that these indirect methods will not come with implications for their privacy? Best regards, Isidor