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 23:02:57 +0200
From: Ivan Pustogarov <ivan.pustogarov@uni.lu>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20140818210257.GB639@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>
	<20140818203343.GA639@localhost.localdomain>
	<CAAS2fgR5EEtevfKB2xKwExhtokb8naBH_PsLkJz3ZeJfeW6YFw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAS2fgR5EEtevfKB2xKwExhtokb8naBH_PsLkJz3ZeJfeW6YFw@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

For each neighbour, a Bitcoin peer keeps the history of addresses that
it forwarded to the neighbour. If an address was already forwarded
to a neighbour it is not retransmitted again.

An attacker can make a list of potential IP addresses of clients (say
an IP range of an ISP, or listen for addresses in the Bitcoin network
before the attack). Then she periodically "spams" the network with this list and
updates the address-forward history at each Bitcoin peer.
After each "spam" round, the attacker reconnects her connections to Bitcoin peers
and thus clears the retransmission history for her connections only.

As the result, when a NAT client connects to the network and advertises its
address, the addresses will propagate to the attacker's connections only.


On Mon, Aug 18, 2014 at 01:43:44PM -0700, Gregory Maxwell wrote:
> On Mon, Aug 18, 2014 at 1:33 PM, Ivan Pustogarov <ivan.pustogarov@uni.lu> wrote:
> > 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>.
> 
> I'm afraid I'm losing you here.  The node advertises himself to
> everyone he is connected to and in/or out, those nodes pass along
> those advertisements.  When I receive an advertisement from a node I
> do not know how far away the advertised peers is, presumably I can
> accurately exclude it from being 0-hops— itself—) 1 or more should be
> indistinguishable. Is there a reason that they're distinguishable that
> I'm missing?
> 
> Can you explain to me how you propose to produce this mapping?

-- 
Ivan