Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XJRoC-0001eX-Bz for bitcoin-development@lists.sourceforge.net; Mon, 18 Aug 2014 18:37:32 +0000 Received-SPF: pass (sog-mx-1.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-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XJRo9-0003Cp-Le for bitcoin-development@lists.sourceforge.net; Mon, 18 Aug 2014 18:37:30 +0000 X-IronPort-AV: E=Sophos;i="5.01,887,1400018400"; d="scan'208";a="48408594" Date: Mon, 18 Aug 2014 20:37:21 +0200 From: Ivan Pustogarov To: Gregory Maxwell Message-ID: <20140818183721.GD31175@localhost.localdomain> References: <20140818164543.GB31175@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.72] 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: 1XJRo9-0003Cp-Le 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 18:37:32 -0000 Yes, I agree that if a client rotates its outbound connections then sooner or later he will connect to a malicious peer. This case considers an attacker which has some peers in the network. E.g. renting 500 IP addresses for 0.01 USD per IP per hour will cost 3600 USD per month: doable but still not for free. I think that revealing the origin (or rather public IP) of a distinct transaction is tolerable. The learned public IP can be shared by several users. So a big ISP can server as a anonymyzer which prevents from linking tx of the same user. Rotation will help against low-resource attackers with no peers at all. The reason for rotation is that if client's 8 outbound connections stay 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. The 8 entry peers are unique per client so if two users share the same IP, they can be distinguished. In order to protect himself from this specific attack, a client can also set only 3-4 outbound connections, so the proposed modification is just another potential defence. If it is useful for other things, it' great. > If you rotate where you send out your transactions then with > very high probability a sybil pretending to be many nodes will observe > you transmitting directly. 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 Mon, Aug 18, 2014 at 10:21:07AM -0700, Gregory Maxwell wrote: > On Mon, Aug 18, 2014 at 9:46 AM, Ivan Pustogarov wrote: > > Hi there, > > I'd like to start a discussion on periodic rotation of outbound connections. > > E.g. every 2-10 minutes an outbound connections is dropped and replaced > > by a new one. > > Connection rotation would be fine for improving a node's knoweldge > about available peers and making the network stronger against > partitioning. > > I haven't implemented this because I think your motivation is > _precisely_ opposite the behavior. If you keep a constant set of > outbound peers only those peers learn the origin of your transactions, > and so it is unlikely that any particular attacker will gain strong > evidence. If you rotate where you send out your transactions then with > very high probability a sybil pretending to be many nodes will observe > you transmitting directly. > > Ultimately, since the traffic is clear text, if you expect to have any > privacy at all in your broadcasts you should be broadcasting over tor > or i2p. -- Ivan