blob: 881c4774af21b8fed3b457877e307d889a1beba1 (
plain)
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
|
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 1XJfoe-0006A3-Fg
for bitcoin-development@lists.sourceforge.net;
Tue, 19 Aug 2014 09:34:56 +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 1XJfod-0007Nx-CK
for bitcoin-development@lists.sourceforge.net;
Tue, 19 Aug 2014 09:34:56 +0000
X-IronPort-AV: E=Sophos;i="5.01,893,1400018400"; d="scan'208";a="48447560"
Date: Tue, 19 Aug 2014 11:34:40 +0200
From: Ivan Pustogarov <ivan.pustogarov@uni.lu>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20140819093425.GA5223@localhost.localdomain>
References: <bitcoin/bitcoin/pull/4723@github.com>
<bitcoin/bitcoin/pull/4723/c52572672@github.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <bitcoin/bitcoin/pull/4723/c52572672@github.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: 1XJfod-0007Nx-CK
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [bitcoin] Add rotation of outbound
connections (#4723)
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: Tue, 19 Aug 2014 09:34:56 -0000
I agree with this.
Some combinatorics shows that 3 persistent connections instead of 8 results in
a low success rate of the entry-peers fingerprinting attack.
> it should not disconnect any nodes which were addnode, and it should not disconnect whitelisted peers
I agree ('Addnodes' are already excluded in the example code from the pull request)
On Mon, Aug 18, 2014 at 04:51:34PM -0700, Gregory Maxwell wrote:
> It was pointed out to me that my concern wrt partitioning is unclear. Imagine
> an attacker starts up a moderate number of sybil nodes. He also connects to
> every other available listening peer and fills up their inbound capacity.
>
> In the current network this kind of activity would only disrupt newly joining
> peers. But nodes which were still online would remain connected to each other.
> With excessive rotation the entire network could become connected exclusively
> via the sybils.
>
> —
> Reply to this email directly or view it on GitHub.*
>
--
Ivan
|
