Received-SPF: pass (sog-mx-3.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: <CAAS2fgRT8OQzUkneKwpjD15aLZDivT=hgBMTB63EjN8RBrp+RQ@mail.gmail.com>
References: <20140818164543.GB31175@localhost.localdomain>
	<CAAS2fgQZaDOtoh+_oaiZh6jMOacSuHbEM=vktBdThDP_7eRH0Q@mail.gmail.com>
	<CAPg+sBgzEMAQ03GTE2j82+K2B+Dia6T0z14ZYWsBQ8z8QSVoLg@mail.gmail.com>
	<CAAS2fgRT8OQzUkneKwpjD15aLZDivT=hgBMTB63EjN8RBrp+RQ@mail.gmail.com>
Date: Mon, 18 Aug 2014 11:13:14 -0700
Message-ID: <CAAS2fgT5-s-uukP8uTRKJ+pzwG-f9knetH44qQ78HsctG9_cZA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Subject: [Bitcoin-development] Fwd:  Outbound connections rotation
Precedence: list

On Mon, Aug 18, 2014 at 10:30 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> Yes, I believe peer rotation is useful, but not for privacy - just for
> improving the network's internal knowledge.
>
> I haven't looked at the implementation yet, but how I imagined it would be
> every X minutes you attempt a new outgoing connection, even if you're
> already at the outbound limit. Then, if a connection attempt succeeds,
> another connection (according to some scoring system) is replaced by it.
> Given such a mechanism, plus reasonable assurances that better connections
> survive for a longer time, I have no problem with rotating every few
> minutes.

Previously when you and I had discussed this I'd proposed that some
number (say) four of the most long lived connections which had proven
themselves useful (e.g. by relaying blocks) be pinned up and not be
eligible for dropping. By protecting some subset of peers you
guarantee that an attacker which simply introduces a lot of nodes
cannot partition the network which existed prior to when the attack
started.

On Mon, Aug 18, 2014 at 10:27 AM, Mike Hearn <mike@plan99.net> wrote:
> I think the attack Ivan is talking about does not require sybil attacks to work though, just listening to lots of peers

I may not be understanding you. Might be a definitions thing, I'm
using the definition: A sybil attack is when a party takes on many
identities (nodes) in the network.

What ivan highlights is a bit of a tradeoff between concealing
identities and linkages.  Relaying transactions through only a single
peer ever (until that one is no longer on the network) is the best
strategy for concealing your identity (ignoring tor and what not), as
only that peer learns anything about your identity.  But it may reveal
a lot about how different transactions are linked, since people
observing that peer will observe that your transactions are
correlated.

The optimal strategy for avoiding linkages (ignoring tor, again), is
to randomly pick a different peer for each transaction and relay the
transaction only to that peer.  This can (and probably should) be
distinct from your normal network connectivity.

Probably for anti-linkage I'd suggest that a facility for that kind of
announcement should be done. If used over tor it would also protect
your identity.   Then the regular topology of the network can be
optimized for learning and partition resistance.