summaryrefslogtreecommitdiff
path: root/96/18e8938618273ae699c098e4ec3494a79b7ca2
blob: ce49d9fe9134bcc2665d3719545f55729ed0cd64 (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
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
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pieter.wuille@gmail.com>) id 1XJQpm-0000bz-Nz
	for bitcoin-development@lists.sourceforge.net;
	Mon, 18 Aug 2014 17:35:06 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.181 as permitted sender)
	client-ip=209.85.213.181; envelope-from=pieter.wuille@gmail.com;
	helo=mail-ig0-f181.google.com; 
Received: from mail-ig0-f181.google.com ([209.85.213.181])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XJQpl-0007hc-Oi
	for bitcoin-development@lists.sourceforge.net;
	Mon, 18 Aug 2014 17:35:06 +0000
Received: by mail-ig0-f181.google.com with SMTP id h3so8345731igd.14
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 18 Aug 2014 10:35:00 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.234.193 with SMTP id ug1mr482997igc.20.1408383300385;
	Mon, 18 Aug 2014 10:35:00 -0700 (PDT)
Received: by 10.50.156.135 with HTTP; Mon, 18 Aug 2014 10:35:00 -0700 (PDT)
Received: by 10.50.156.135 with HTTP; Mon, 18 Aug 2014 10:35:00 -0700 (PDT)
In-Reply-To: <CAAS2fgQZaDOtoh+_oaiZh6jMOacSuHbEM=vktBdThDP_7eRH0Q@mail.gmail.com>
References: <20140818164543.GB31175@localhost.localdomain>
	<CAAS2fgQZaDOtoh+_oaiZh6jMOacSuHbEM=vktBdThDP_7eRH0Q@mail.gmail.com>
Date: Mon, 18 Aug 2014 19:35:00 +0200
Message-ID: <CAPg+sBjQv7vrw63KbZf+mUj8W6h8GxdpE7xYbLLFfhm6-aGKdA@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=001a113489e053e1940500eaca7d
X-Spam-Score: -0.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
	(pieter.wuille[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-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: 1XJQpl-0007hc-Oi
Cc: Ivan Pustogarov <ivan.pustogarov@uni.lu>,
	Bitcoin Dev <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:35:07 -0000

--001a113489e053e1940500eaca7d
Content-Type: text/plain; charset=ISO-8859-1

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.
On Aug 18, 2014 7:23 PM, "Gregory Maxwell" <gmaxwell@gmail.com> 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.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--001a113489e053e1940500eaca7d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Yes, I believe peer rotation is useful, but not for privacy =
- just for improving the network&#39;s internal knowledge.</p>
<p dir=3D"ltr">I haven&#39;t looked at the implementation yet, but how I im=
agined it would be every X minutes you attempt a new outgoing connection, e=
ven if you&#39;re already at the outbound limit. Then, if a connection atte=
mpt succeeds, another connection (according to some scoring system) is repl=
aced by it. Given such a mechanism, plus reasonable assurances that better =
connections survive for a longer time, I have no problem with rotating ever=
y few minutes.<br>
</p>
<div class=3D"gmail_quote">On Aug 18, 2014 7:23 PM, &quot;Gregory Maxwell&q=
uot; &lt;<a href=3D"mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>&gt; w=
rote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Aug 18, 2014 at 9:46 AM, Ivan Pustogarov &lt;<a href=3D"mailto:ivan=
.pustogarov@uni.lu">ivan.pustogarov@uni.lu</a>&gt; wrote:<br>
&gt; Hi there,<br>
&gt; I&#39;d like to start a discussion on periodic rotation of outbound co=
nnections.<br>
&gt; E.g. every 2-10 minutes an outbound connections is dropped and replace=
d<br>
&gt; by a new one.<br>
<br>
Connection rotation would be fine for improving a node&#39;s knoweldge<br>
about available peers and making the network stronger against<br>
partitioning.<br>
<br>
I haven&#39;t implemented this because I think your motivation is<br>
_precisely_ opposite the behavior. If you keep a constant set of<br>
outbound peers only those peers learn the origin of your transactions,<br>
and so it is unlikely that any particular attacker will gain strong<br>
evidence. If you rotate where you send out your transactions then with<br>
very high probability a sybil pretending to be many nodes will observe<br>
you transmitting directly.<br>
<br>
Ultimately, since the traffic is clear text, if you expect to have any<br>
privacy at all in your broadcasts you should be broadcasting over tor<br>
or i2p.<br>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div>

--001a113489e053e1940500eaca7d--