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; 
Date: Tue, 19 Aug 2014 11:34:40 +0200
From: Ivan Pustogarov <ivan.pustogarov@uni.lu>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20140819093425.GA5223@localhost.localdomain>
References: <bitcoin/bitcoin/pull/4723@github.com>
	<bitcoin/bitcoin/pull/4723/c52572672@github.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <bitcoin/bitcoin/pull/4723/c52572672@github.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [bitcoin] Add rotation of outbound
	connections (#4723)
Precedence: list

I agree with this.
Some combinatorics shows that 3 persistent connections instead of 8 results in
a low success rate of the entry-peers fingerprinting attack.

> it should not disconnect any nodes which were addnode, and it should not disconnect whitelisted peers
I agree ('Addnodes' are already excluded in the example code from the pull request)

On Mon, Aug 18, 2014 at 04:51:34PM -0700, Gregory Maxwell wrote:
> It was pointed out to me that my concern wrt partitioning is unclear. Imagine
> an attacker starts up a moderate number of sybil nodes. He also connects to
> every other available listening peer and fills up their inbound capacity.
> 
> In the current network this kind of activity would only disrupt newly joining
> peers. But nodes which were still online would remain connected to each other.
> With excessive rotation the entire network could become connected exclusively
> via the sybils.
> 
> —
> Reply to this email directly or view it on GitHub.*
> 

-- 
Ivan