1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <ivan.pustogarov@uni.lu>) id 1XJTcv-0000s4-Pe
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Aug 2014 20:34:02 +0000
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;
Received: from hercules.uni.lu ([158.64.76.33])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XJTcu-000585-9p
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Aug 2014 20:34:01 +0000
X-IronPort-AV: E=Sophos;i="5.01,888,1400018400"; d="scan'208";a="48412562"
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)
X-Originating-IP: [10.24.1.80]
X-Spam-Score: -2.2 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1XJTcu-000585-9p
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Outbound connections rotation
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 18 Aug 2014 20:34:02 -0000
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
|
