From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 58821102C for ; 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 ; Wed, 23 May 2018 21:04:02 +0000 (UTC) Received: by mail-wm0-f52.google.com with SMTP id a67-v6so12480347wmf.3 for ; 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 Date: Wed, 23 May 2018 14:03:58 -0700 Message-ID: To: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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 consequ= entially 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 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]).
Rotation of the peers is an= obvious solution, but there are several questions to answer.
[Th= e idea has also been discussed here: [3] and in the mailing list: [4], but = ended up not well-researched.]

### Issues with rot= ation
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.

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.

=
### Reliable peers
There are several metrics that might be u= sed to consider peers to be reliable:
Which fraction of recent bl= ocks have a particular node relayed to us?
=E2=80=A6 of recent tr= ansactions ... ?
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 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.

Current 8 peers for outgoing conne= ctions is an arbitrary number, however, there is a reason behind keeping a = number of outgoing connections low.
Anyway, considering the threa= t highlighted before it is a good idea to rotate only a fraction of peers.<= /div>

Thus, there are 3 values to discuss (N, M, T):
N =E2=80=94 Number of persistent peers which are considered to be tr= ustworthy based on the metrics as per Section 3
M =E2=80=94 Numbe= r 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}.

<= /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>
Figuring out an optimal set {N, M, T} may be done analyt= ically or by simulation.=C2=A0
I'd be happy to discuss the wa= y of figuring it out.

### Protocol extensions<= /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.

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= .

### Transactions de-anonymized
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.
In this case= either Dandelion [1] or sending own transactions to a static set of peers = (say first 8 peers) may help.


--000000000000bab6c4056ce5df68--