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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1XJQcL-00005c-Ov
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Aug 2014 17:21:13 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.172 as permitted sender)
client-ip=209.85.220.172; envelope-from=gmaxwell@gmail.com;
helo=mail-vc0-f172.google.com;
Received: from mail-vc0-f172.google.com ([209.85.220.172])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XJQcK-0008WD-VB
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Aug 2014 17:21:13 +0000
Received: by mail-vc0-f172.google.com with SMTP id im17so6176986vcb.3
for <bitcoin-development@lists.sourceforge.net>;
Mon, 18 Aug 2014 10:21:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.220.112.143 with SMTP id w15mr1612578vcp.41.1408382467485;
Mon, 18 Aug 2014 10:21:07 -0700 (PDT)
Received: by 10.52.187.132 with HTTP; Mon, 18 Aug 2014 10:21:07 -0700 (PDT)
In-Reply-To: <20140818164543.GB31175@localhost.localdomain>
References: <20140818164543.GB31175@localhost.localdomain>
Date: Mon, 18 Aug 2014 10:21:07 -0700
Message-ID: <CAAS2fgQZaDOtoh+_oaiZh6jMOacSuHbEM=vktBdThDP_7eRH0Q@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Ivan Pustogarov <ivan.pustogarov@uni.lu>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XJQcK-0008WD-VB
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 17:21:13 -0000
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.
|
