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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y0VeN-0002Vy-GD for bitcoin-development@lists.sourceforge.net; Mon, 15 Dec 2014 13:25:23 +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 1Y0VeL-0006kl-Jl for bitcoin-development@lists.sourceforge.net; Mon, 15 Dec 2014 13:25:23 +0000 Received: from localhost (localhost [127.0.0.1]) by quidecco.de (Postfix) with SMTP id BCC88E2353B; Mon, 15 Dec 2014 14:25:14 +0100 (CET) To: Wladimir Content-Type: text/plain; charset=UTF-8; format=flowed From: Isidor Zeuner References: <54760A50.201@riseup.net> <20141127020947.A13D2E19A09@quidecco.de> In-Reply-To: Message-Id: <20141215132514.BCC88E2353B@quidecco.de> Date: Mon, 15 Dec 2014 14:25: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: 1Y0VeL-0006kl-Jl 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, 15 Dec 2014 13:25:23 -0000 [...] > > 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. > > In my experience the problem has always been getting bootstrapped. > Most nodes hardly give any hidden service nodes in their getaddr. > (this has been improved in master by including a set of hidden service > seed nodes) > But this assumes -onlynet=tor. Tor with exit nodes should be less > problematic, unless someone managed to DoSban all the exit nodes as > described in the paper (but I've never seen such an attack myself). > When refering to "getting bootstrapped", do you only mean collecting node addresses, or also syncing blocks? If you're saying the drops in connection counts are likely to be not caused by a DoSban attack on the exit nodes, what could be other reasons to look into? > > Can you tell me more about how you measured this? > > > > [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.] > > Right, there's something to be said for splitting your own transaction > submission from normal P2P networking and transaction relay. > (esp for non-SPV wallets which don't inherently leak any information > about their addresses) > > There was a pull request about this for Bitcoin Core one, maybe I > closed it unfairly https://github.com/bitcoin/bitcoin/issues/4564 . > Great! I find it very interesting to research options for splitting communication between Tor and non-Tor as long as the introduced information leakage between both connection methods can be proved to be nonexistent or negligible. In the case of Bitcoin, this makes me wonder about an attack that could look approximately like this: * Node A connects to Bitcoin using Tor (for submitting transactions) and IPv4 (for all other communication). * Node B strives for direct IPv4 connections with node A * Node B uses the direct IPv4 connections in order to supply Node A with additional peer addresses not supplied to any other nodes * Node B observes these additional peer addresses For transactions submitted to the additional peer addresses supplied by node B, how to prevent that the probability of these originating from node A is higher than for originating from other nodes? For handling block propagation using non-Tor connections, it's probably harder to create information leaks, as the logic for handling disagreement about blocks is pretty well-researched, meaning that it's less important where the blocks come from. Best regards, Isidor