Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.181 as permitted sender)
	client-ip=209.85.220.181; envelope-from=gmaxwell@gmail.com;
	helo=mail-vc0-f181.google.com; 
MIME-Version: 1.0
In-Reply-To: <20140818183721.GD31175@localhost.localdomain>
References: <20140818164543.GB31175@localhost.localdomain>
	<CAAS2fgQZaDOtoh+_oaiZh6jMOacSuHbEM=vktBdThDP_7eRH0Q@mail.gmail.com>
	<20140818183721.GD31175@localhost.localdomain>
Date: Mon, 18 Aug 2014 12:37:49 -0700
Message-ID: <CAAS2fgQa1ZURn1M9-LBnSHsE5fHKdatrVbNJbd+E9JYQYH=wFw@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Ivan Pustogarov <ivan.pustogarov@uni.lu>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Outbound connections rotation
Precedence: list

On Mon, Aug 18, 2014 at 11:37 AM, Ivan Pustogarov
<ivan.pustogarov@uni.lu> 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.