Received-SPF: pass (sog-mx-4.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: Mon, 18 Aug 2014 22:33:43 +0200
From: Ivan Pustogarov <ivan.pustogarov@uni.lu>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20140818203343.GA639@localhost.localdomain>
References: <20140818164543.GB31175@localhost.localdomain>
	<CAAS2fgQZaDOtoh+_oaiZh6jMOacSuHbEM=vktBdThDP_7eRH0Q@mail.gmail.com>
	<20140818183721.GD31175@localhost.localdomain>
	<CAAS2fgQa1ZURn1M9-LBnSHsE5fHKdatrVbNJbd+E9JYQYH=wFw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAAS2fgQa1ZURn1M9-LBnSHsE5fHKdatrVbNJbd+E9JYQYH=wFw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Outbound connections rotation
Precedence: list

The attack I'm trying to address is described here: https://www.cryptolux.org/index.php/Bitcoin
It was discussed here: https://bitcointalk.org/index.php?topic=632124.0

It uses the following observation. Each NATed client connects to the Bitcoin network
through 8 entry peers; he also advertises his public IP address to these peers which
allows an attacker to make the mapping <8-entry-peers, client-IP-address>.
The probability for two different clients to choose
the same entry peers is negligible. When a client generates a transaction,
the entry peers of the client are likely to be the first to retransmit it.

The attacker establishes many connections to each reachable Bitcoin peer and listens
for transactions. For each transaction she records 8-10 peers which were the first to forward this tx.
As a result, if two transactions are forwarded by the same set of entry peers,
they are likely to belong to the same client. 
Also each 8-tuples has a mapping to the client's advertised IP address.


On Mon, Aug 18, 2014 at 12:37:49PM -0700, Gregory Maxwell wrote:
> 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.

-- 
Ivan