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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1XJRQn-0003xI-Gd
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Aug 2014 18:13:21 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.181 as permitted sender)
client-ip=209.85.220.181; envelope-from=gmaxwell@gmail.com;
helo=mail-vc0-f181.google.com;
Received: from mail-vc0-f181.google.com ([209.85.220.181])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XJRQm-00032o-HK
for bitcoin-development@lists.sourceforge.net;
Mon, 18 Aug 2014 18:13:21 +0000
Received: by mail-vc0-f181.google.com with SMTP id lf12so6239050vcb.12
for <bitcoin-development@lists.sourceforge.net>;
Mon, 18 Aug 2014 11:13:15 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.52.228.67 with SMTP id sg3mr7398211vdc.6.1408385594995; Mon,
18 Aug 2014 11:13:14 -0700 (PDT)
Received: by 10.52.187.132 with HTTP; Mon, 18 Aug 2014 11:13:14 -0700 (PDT)
In-Reply-To: <CAAS2fgRT8OQzUkneKwpjD15aLZDivT=hgBMTB63EjN8RBrp+RQ@mail.gmail.com>
References: <20140818164543.GB31175@localhost.localdomain>
<CAAS2fgQZaDOtoh+_oaiZh6jMOacSuHbEM=vktBdThDP_7eRH0Q@mail.gmail.com>
<CAPg+sBgzEMAQ03GTE2j82+K2B+Dia6T0z14ZYWsBQ8z8QSVoLg@mail.gmail.com>
<CAAS2fgRT8OQzUkneKwpjD15aLZDivT=hgBMTB63EjN8RBrp+RQ@mail.gmail.com>
Date: Mon, 18 Aug 2014 11:13:14 -0700
Message-ID: <CAAS2fgT5-s-uukP8uTRKJ+pzwG-f9knetH44qQ78HsctG9_cZA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
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: 1XJRQm-00032o-HK
Subject: [Bitcoin-development] Fwd: 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:13:21 -0000
On Mon, Aug 18, 2014 at 10:30 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> Yes, I believe peer rotation is useful, but not for privacy - just for
> improving the network's internal knowledge.
>
> I haven't looked at the implementation yet, but how I imagined it would be
> every X minutes you attempt a new outgoing connection, even if you're
> already at the outbound limit. Then, if a connection attempt succeeds,
> another connection (according to some scoring system) is replaced by it.
> Given such a mechanism, plus reasonable assurances that better connections
> survive for a longer time, I have no problem with rotating every few
> minutes.
Previously when you and I had discussed this I'd proposed that some
number (say) four of the most long lived connections which had proven
themselves useful (e.g. by relaying blocks) be pinned up and not be
eligible for dropping. By protecting some subset of peers you
guarantee that an attacker which simply introduces a lot of nodes
cannot partition the network which existed prior to when the attack
started.
On Mon, Aug 18, 2014 at 10:27 AM, Mike Hearn <mike@plan99.net> wrote:
> I think the attack Ivan is talking about does not require sybil attacks to work though, just listening to lots of peers
I may not be understanding you. Might be a definitions thing, I'm
using the definition: A sybil attack is when a party takes on many
identities (nodes) in the network.
What ivan highlights is a bit of a tradeoff between concealing
identities and linkages. Relaying transactions through only a single
peer ever (until that one is no longer on the network) is the best
strategy for concealing your identity (ignoring tor and what not), as
only that peer learns anything about your identity. But it may reveal
a lot about how different transactions are linked, since people
observing that peer will observe that your transactions are
correlated.
The optimal strategy for avoiding linkages (ignoring tor, again), is
to randomly pick a different peer for each transaction and relay the
transaction only to that peer. This can (and probably should) be
distinct from your normal network connectivity.
Probably for anti-linkage I'd suggest that a facility for that kind of
announcement should be done. If used over tor it would also protect
your identity. Then the regular topology of the network can be
optimized for learning and partition resistance.
|
