path: root/a5/7167745d9cd2127f6e50063a1d5f1571e986b3

Return-Path: <naumenko.gs@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 58821102C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 23 May 2018 21:04:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 89297177
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 23 May 2018 21:04:02 +0000 (UTC)
Received: by mail-wm0-f52.google.com with SMTP id a67-v6so12480347wmf.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 23 May 2018 14:04:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:from:date:message-id:subject:to;
	bh=5sXImD01cgikJg8UsxujgqsXEMVdrdsi1wqkT1PrfUY=;
	b=cVW+ommtMyRdfsHkjXeu6dMT0k26REvewdzzm/NatYASwDVWApU5Hk6XNMChNtFop2
	R94IZW9G0LNCTkJb0AdHxyh/ZVVrlf10ePyzezQzP5IsQTctYmGzJX0vend0QDt5jGXU
	TIqWFVQ2mNmJzGimLEgJ9Q5PeSlxL8f+fpzYsQb3f6n95osEaWyCM0gJiBrzvkOGml95
	c8cQEIszLiXP8F6yVPunIgD8pbTUt+7g5pB5kAF4tkrM1Kc+Drp3zo6dGIp/3+kEbWSj
	2l5PKLuCX/bWEB6f02emti9Wf5Vv6oxr7XsWKSwtFgeEu6zEpr5cN/OMD0ORx0/nep/7
	ZULQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
	bh=5sXImD01cgikJg8UsxujgqsXEMVdrdsi1wqkT1PrfUY=;
	b=XI/P9RsnyvjKMhl/pD9gLXdN1dzyB0E6BHZOhnlUCjZSwytyF6dkbs/JD0gAaUmQo/
	xPyXJ3pahNG433W7HGUXrj8EGep9EfuiYfluK42DY5k7mM+uI8ONJW8KsDnoODl9efk2
	ob8Ij7ViJU1TIVCu3x0ew7XAGTxtzgZO4+qJmWY2xEegebl/bIptqfNEf2LAnu2FGbqb
	gA53gxek0ouHvf/eY96QLaZujkbUUttdTGPM/Lw3g2uxHugQn8uDzdiCc+yiadyr1CwA
	BaBKw5zn9+e5ggOtYualZOh9gHx6nmHjf0Ch6L4jx/qT6GyYikD4hnjgGmSBpor3wOqU
	jV5w==
X-Gm-Message-State: ALKqPwelJMx/k0gFMrKUi4k/SHXzghQv5udURXMzt4o49XTbxoUx2qsO
	oE0JatmdnFhtBVtPQrthIJwbD7AA9CgJCBaFSRxChQ==
X-Google-Smtp-Source: AB8JxZoRJpZdKvILZkzTCexEo6ilH7/LAVlhSA43WkUo+/W6u20pvSAIiXeFDCN14yPRuprS48Vg0xPZrH+3LQIlgA0=
X-Received: by 2002:a2e:1218:: with SMTP id
	t24-v6mr2818195lje.143.1527109440418; 
	Wed, 23 May 2018 14:04:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.152.80 with HTTP; Wed, 23 May 2018 14:03:58 -0700 (PDT)
From: Gleb Naumenko <naumenko.gs@gmail.com>
Date: Wed, 23 May 2018 14:03:58 -0700
Message-ID: <CAG0mztWq7RKExwnERQ=-b2Lpq7QYW-4r97RYwnmoLdeNvaVngQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000bab6c4056ce5df68"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 23 May 2018 21:08:03 +0000
Subject: [bitcoin-dev] Peer rotation
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 23 May 2018 21:04:04 -0000

--000000000000bab6c4056ce5df68
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi all,
I'm bringing this up again because since the last time (2014) new papers on
network attacks have been published, and in general I think this is
something that has to be done in one or another form.

### Motivation
It has been shown that revealing the topology of the network may increase
the risk of network-related attacks including partitioning/eclipse (and
consequentially double-spending attacks and attacks on mining) and
deanonymization of transactions.

The current join/leave algorithm makes the network fairly static, which
makes it possible to reconstruct the topology by observing events in the
network (for example, see Dandelion threat model [1] or Exploiting
Transaction Accumulation and Double Spends for Topology Inference in
Bitcoin [2]).
Rotation of the peers is an obvious solution, but there are several
questions to answer.
[The idea has also been discussed here: [3] and in the mailing list: [4],
but ended up not well-researched.]

### Issues with rotation
In P2P network, rotation of peers may cause an additional threat, because
it is safer to stick to the existing connections, due to the fact that
having connections to more different peers increases the chances of
connecting to an attacker. Considering the fact that an attacker can
influence your future behavior including what connections you make, this
may worsen the situation.

One important detail to keep in mind here is that a node may act
legitimately, but just to wait when all of the connections are under the
control of an attacker. So a good idea here is to avoid disconnecting the
most reliable peers.

### Reliable peers
There are several metrics that might be used to consider peers to be
reliable:
Which fraction of recent blocks have a particular node relayed to us?
=E2=80=A6 of recent transactions ... ?
For how long the connection has been maintained?

### Implementation details
Rotation of the outgoing connections only seems to be sufficient yet not
very hard to implement and analyze. In addition, it will cause rotation of
the incoming connections of nodes in the network due to the fact that each
of the outgoing connections is also an incoming connection on the second
side; and due to the scoring mechanism for replacing existing incoming
connections when getting a new one.

Current 8 peers for outgoing connections is an arbitrary number, however,
there is a reason behind keeping a number of outgoing connections low.
Anyway, considering the threat highlighted before it is a good idea to
rotate only a fraction of peers.

Thus, there are 3 values to discuss (N, M, T):
N =E2=80=94 Number of persistent peers which are considered to be trustwort=
hy based
on the metrics as per Section 3
M =E2=80=94 Number of peers to be rotated every T seconds

The trade-off here is how to add enough entropy while not ending up being
connected to dishonest peers only. It is tunable by modifying {N, M}.

Lower bound for T is a value that won=E2=80=99t significantly delay transac=
tion
propagation because of establishing handshakes (and it will not result in
connecting to dishonest peers only), while the upper bound is a value at
which it would be still infeasible to execute an attack.

Figuring out an optimal set {N, M, T} may be done analytically or by
simulation.
I'd be happy to discuss the way of figuring it out.

### Protocol extensions
It may also be useful to keep track of the previous connections (which were
evicted due to the rotation) and get back to those after a while under
certain conditions.

For example, to decrease a chance of connecting to dishonest peers, a peer
may alternate connecting to the brand new peer with connecting to the old
and fairly reliable peer.

### Transactions de-anonymized
Rotation of the peers itself may increase the chance that particular
Bitcoin address or set of transactions would be linked to a node.
In this case either Dandelion [1] or sending own transactions to a static
set of peers (say first 8 peers) may help.

[1] https://github.com/mablem8/bips/blob/master/bip-dandelion.mediawiki
[2] https://fc18.ifca.ai/bitcoin/papers/bitcoin18-final10.pdf
[3] https://github.com/bitcoin/bitcoin/pull/4723
[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-August/006502.=
html

--000000000000bab6c4056ce5df68
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hi all,</div><div>I&#39;m bringing this up again=
 because since the last time (2014) new papers on network attacks have been=
 published, and in general I think this is something that has to be done in=
 one or another form.</div><div><br></div><div>### Motivation</div><div>It =
has been shown that revealing the topology of the network may increase the =
risk of network-related attacks including partitioning/eclipse (and consequ=
entially double-spending attacks and attacks on mining) and deanonymization=
 of transactions.</div><div><br></div><div>The current join/leave algorithm=
 makes the network fairly static, which makes it possible to reconstruct th=
e topology by observing events in the network (for example, see Dandelion t=
hreat model [1] or Exploiting Transaction Accumulation and Double Spends fo=
r Topology Inference in Bitcoin [2]).</div><div>Rotation of the peers is an=
 obvious solution, but there are several questions to answer.</div><div>[Th=
e idea has also been discussed here: [3] and in the mailing list: [4], but =
ended up not well-researched.]</div><div><br></div><div>### Issues with rot=
ation</div><div>In P2P network, rotation of peers may cause an additional t=
hreat, because it is safer to stick to the existing connections, due to the=
 fact that having connections to more different peers increases the chances=
 of connecting to an attacker. Considering the fact that an attacker can in=
fluence your future behavior including what connections you make, this may =
worsen the situation.</div><div><br></div><div>One important detail to keep=
 in mind here is that a node may act legitimately, but just to wait when al=
l of the connections are under the control of an attacker. So a good idea h=
ere is to avoid disconnecting the most reliable peers.</div><div><br></div>=
<div>### Reliable peers</div><div>There are several metrics that might be u=
sed to consider peers to be reliable:</div><div>Which fraction of recent bl=
ocks have a particular node relayed to us?</div><div>=E2=80=A6 of recent tr=
ansactions ... ?</div><div>For how long the connection has been maintained?=
</div><div><br></div><div>### Implementation details</div><div>Rotation of =
the outgoing connections only seems to be sufficient yet not very hard to i=
mplement and analyze. In addition, it will cause rotation of the incoming c=
onnections of nodes in the network due to the fact that each of the outgoin=
g connections is also an incoming connection on the second side; and due to=
 the scoring mechanism for replacing existing incoming connections when get=
ting a new one.</div><div><br></div><div>Current 8 peers for outgoing conne=
ctions is an arbitrary number, however, there is a reason behind keeping a =
number of outgoing connections low.</div><div>Anyway, considering the threa=
t highlighted before it is a good idea to rotate only a fraction of peers.<=
/div><div><br></div><div>Thus, there are 3 values to discuss (N, M, T):</di=
v><div>N =E2=80=94 Number of persistent peers which are considered to be tr=
ustworthy based on the metrics as per Section 3</div><div>M =E2=80=94 Numbe=
r of peers to be rotated every T seconds</div><div><br></div><div>The trade=
-off here is how to add enough entropy while not ending up being connected =
to dishonest peers only. It is tunable by modifying {N, M}.</div><div><br><=
/div><div>Lower bound for T is a value that won=E2=80=99t significantly del=
ay transaction propagation because of establishing handshakes (and it will =
not result in connecting to dishonest peers only), while the upper bound is=
 a value at which it would be still infeasible to execute an attack.</div><=
div><br></div><div>Figuring out an optimal set {N, M, T} may be done analyt=
ically or by simulation.=C2=A0</div><div>I&#39;d be happy to discuss the wa=
y of figuring it out.<br></div><div><br></div><div>### Protocol extensions<=
/div><div>It may also be useful to keep track of the previous connections (=
which were evicted due to the rotation) and get back to those after a while=
 under certain conditions.</div><div><br></div><div>For example, to decreas=
e a chance of connecting to dishonest peers, a peer may alternate connectin=
g to the brand new peer with connecting to the old and fairly reliable peer=
.</div><div><br></div><div>### Transactions de-anonymized</div><div>Rotatio=
n of the peers itself may increase the chance that particular Bitcoin addre=
ss or set of transactions would be linked to a node.</div><div>In this case=
 either Dandelion [1] or sending own transactions to a static set of peers =
(say first 8 peers) may help.</div><div><br></div><div>[1] <a href=3D"https=
://github.com/mablem8/bips/blob/master/bip-dandelion.mediawiki">https://git=
hub.com/mablem8/bips/blob/master/bip-dandelion.mediawiki</a></div><div>[2] =
<a href=3D"https://fc18.ifca.ai/bitcoin/papers/bitcoin18-final10.pdf">https=
://fc18.ifca.ai/bitcoin/papers/bitcoin18-final10.pdf</a></div><div>[3] <a h=
ref=3D"https://github.com/bitcoin/bitcoin/pull/4723">https://github.com/bit=
coin/bitcoin/pull/4723</a></div><div>[4] <a href=3D"https://lists.linuxfoun=
dation.org/pipermail/bitcoin-dev/2014-August/006502.html">https://lists.lin=
uxfoundation.org/pipermail/bitcoin-dev/2014-August/006502.html</a></div></d=
iv><div><br></div></div>

--000000000000bab6c4056ce5df68--