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
104
105
106
107
108
109
110
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <ivan.pustogarov@uni.lu>) id 1XJRoC-0001eX-Bz
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Aug 2014 18:37:32 +0000
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;
Received: from hercules.uni.lu ([158.64.76.33])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XJRo9-0003Cp-Le
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Aug 2014 18:37:30 +0000
X-IronPort-AV: E=Sophos;i="5.01,887,1400018400"; d="scan'208";a="48408594"
Date: Mon, 18 Aug 2014 20:37:21 +0200
From: Ivan Pustogarov <ivan.pustogarov@uni.lu>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20140818183721.GD31175@localhost.localdomain>
References: <20140818164543.GB31175@localhost.localdomain>
<CAAS2fgQZaDOtoh+_oaiZh6jMOacSuHbEM=vktBdThDP_7eRH0Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAAS2fgQZaDOtoh+_oaiZh6jMOacSuHbEM=vktBdThDP_7eRH0Q@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Originating-IP: [10.24.1.72]
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: 1XJRo9-0003Cp-Le
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 18:37:32 -0000
Yes, I agree that if a client rotates its outbound connections then
sooner or later he will connect to a malicious peer. This case considers
an attacker which has some peers in the network. E.g. renting 500 IP addresses
for 0.01 USD per IP per hour will cost 3600 USD per month: doable but
still not for free.
I think that revealing the origin (or rather public IP) of a distinct
transaction is tolerable. The learned public IP can be shared by several
users. So a big ISP can server as a anonymyzer which prevents from linking
tx of the same user.
Rotation will help against low-resource attackers with no peers at all.
The reason for rotation is that if client's 8 outbound connections stay
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. The 8 entry peers are unique per client so if two
users share the same IP, they can be distinguished.
In order to protect himself from this specific attack, a client can also
set only 3-4 outbound connections, so the proposed modification is just
another potential defence. If it is useful for other things, it' great.
> If you rotate where you send out your transactions then with
> very high probability a sybil pretending to be many nodes will observe
> you transmitting directly.
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 Mon, Aug 18, 2014 at 10:21:07AM -0700, Gregory Maxwell wrote:
> On Mon, Aug 18, 2014 at 9:46 AM, Ivan Pustogarov <ivan.pustogarov@uni.lu> wrote:
> > Hi there,
> > I'd like to start a discussion on periodic rotation of outbound connections.
> > E.g. every 2-10 minutes an outbound connections is dropped and replaced
> > by a new one.
>
> Connection rotation would be fine for improving a node's knoweldge
> about available peers and making the network stronger against
> partitioning.
>
> I haven't implemented this because I think your motivation is
> _precisely_ opposite the behavior. If you keep a constant set of
> outbound peers only those peers learn the origin of your transactions,
> and so it is unlikely that any particular attacker will gain strong
> evidence. If you rotate where you send out your transactions then with
> very high probability a sybil pretending to be many nodes will observe
> you transmitting directly.
>
> Ultimately, since the traffic is clear text, if you expect to have any
> privacy at all in your broadcasts you should be broadcasting over tor
> or i2p.
--
Ivan
|
