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 1XJQCb-0007CE-Fb for bitcoin-development@lists.sourceforge.net; Mon, 18 Aug 2014 16:54:37 +0000 Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XJQCZ-0000Ms-JY for bitcoin-development@lists.sourceforge.net; Mon, 18 Aug 2014 16:54:37 +0000 X-IronPort-AV: E=Sophos;i="5.01,887,1400018400"; d="scan'208";a="48405118" Date: Mon, 18 Aug 2014 18:46:12 +0200 From: Ivan Pustogarov To: Message-ID: <20140818164543.GB31175@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline 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: 1XJQCZ-0000Ms-JY Subject: [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 16:54:37 -0000 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. Motivation: Each bitcoin non-UPnP client behind NAT has 8 outbound connections which change only rarely (due to occasional remote side disconnections). A subset of these 8 entry nodes uniquely identifies a user. An attacker can listen for transactions in Bitcoin network and for each transaction record the first 8 peers which forwarded the transaction. If two distinct transactions (with unrelated bitcoin addresses) come from the same set of 8 peers, the attacker can conclude that they originated from the same user. This gives another method (in addition to transaction graph analysis) for an attacker to link different BC addresses of the same user. Also note that by default bitcoin clients advertise their public IP addresses. The attacker can link the advertised IP's to corresponding 8 entry nodes and use it to deanonymise Bitcoin clients. If a bitcoin client periodically rotates his set of outbound connections, his 8-peers fingerprint is blurred over time. Corresponding pull request is #4723. Some details are here: https://www.cryptolux.org/index.php/Bitcoin -- Ivan