From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XJTcv-0000s4-Pe for bitcoin-development@lists.sourceforge.net; Mon, 18 Aug 2014 20:34:02 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of uni.lu designates 158.64.76.33 as permitted sender) client-ip=158.64.76.33; envelope-from=ivan.pustogarov@uni.lu; helo=hercules.uni.lu; Received: from hercules.uni.lu ([158.64.76.33]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XJTcu-000585-9p for bitcoin-development@lists.sourceforge.net; Mon, 18 Aug 2014 20:34:01 +0000 X-IronPort-AV: E=Sophos;i="5.01,888,1400018400"; d="scan'208";a="48412562" Date: Mon, 18 Aug 2014 22:33:43 +0200 From: Ivan Pustogarov To: Gregory Maxwell Message-ID: <20140818203343.GA639@localhost.localdomain> References: <20140818164543.GB31175@localhost.localdomain> <20140818183721.GD31175@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [10.24.1.80] X-Spam-Score: -2.2 (--) 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 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1XJTcu-000585-9p Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Outbound connections rotation 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, 18 Aug 2014 20:34:02 -0000 The attack I'm trying to address is described here: https://www.cryptolux.org/index.php/Bitcoin It was discussed here: https://bitcointalk.org/index.php?topic=632124.0 It uses the following observation. Each NATed client connects to the Bitcoin network through 8 entry peers; he also advertises his public IP address to these peers which allows an attacker to make the mapping <8-entry-peers, client-IP-address>. The probability for two different clients to choose the same entry peers is negligible. When a client generates a transaction, the entry peers of the client are likely to be the first to retransmit it. The attacker establishes many connections to each reachable Bitcoin peer and listens for transactions. For each transaction she records 8-10 peers which were the first to forward this tx. As a result, if two transactions are forwarded by the same set of entry peers, they are likely to belong to the same client. Also each 8-tuples has a mapping to the client's advertised IP address. On Mon, Aug 18, 2014 at 12:37:49PM -0700, Gregory Maxwell wrote: > On Mon, Aug 18, 2014 at 11:37 AM, Ivan Pustogarov > wrote: > > the same for a long time, an attacker which does not have any peers at all > > but just listens the Bitcoin network can link together differed BC addresses > > and learn the IP of the client. > > I don't understand what you're talking about here; if you have no peer > at all you will learn nothing about the Bitcoin network. > > Can you clarify? > > > > The 8 entry peers are unique per client so if two > > users share the same IP, they can be distinguished. > > What mechanism are you referring to specifically? > > > Outbound connections are still rotated from time to time due to remote side > > disconnections. Plus outbound connections do not survive BC client restarts > > (unlike Tor Guard nodes). > > On our initial connections we do have a preference for nodes we knew > were up recently. This could be made further. That the current > behavior isn't great isn't an argument for making it worse on that > dimension. -- Ivan