path: root/05/2301a76c020447e16620e10309f2758a351e71

Return-Path: <m@ib.tc>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 98458C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Oct 2020 23:06:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 7D94E20410
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Oct 2020 23:06:52 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id xvjvj8axkO2U
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Oct 2020 23:06:50 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com
 [209.85.221.43])
 by silver.osuosl.org (Postfix) with ESMTPS id 3E5C220415
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat,  3 Oct 2020 23:06:50 +0000 (UTC)
Received: by mail-wr1-f43.google.com with SMTP id s12so5634762wrw.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 03 Oct 2020 16:06:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ib.tc; s=google;
 h=mime-version:from:date:message-id:subject:to;
 bh=p2a70tJFYplXBqEjirjAL0MNuA9Yg6HNLuHwyVsfTAY=;
 b=VEsaWoj2o2LX6HcjztvzeKktOKDLpiFXjhhEdalHYDdABsjRc7KBelDiI7eeJJPjAh
 x5msKV+9ePrWfNQkMd7O7gDbKPAJ3YY5KuD1PO7AJxxPkbaQgdIv0uXcDTBl5zdomB+U
 c1sfU3pEqvl6jkZefY1ncCC7KA9jcUjVW/Mc7qoc/gHl2cufZq2RswNlzrV7S7/5e5g7
 BCR0OkfmbXHZIp5u7jycfJOnCg1uV7BHbXOgdya51hc+G780W4Yr/vnS9KVAjaTiYPMn
 7+Ewr8OLpvNK2pjKPIoFl6I7vylBWnL2qvsPamgLyfKVbZUolrOgbeulbrXlfXHu2qYw
 7jew==
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=p2a70tJFYplXBqEjirjAL0MNuA9Yg6HNLuHwyVsfTAY=;
 b=FWN0nkH/+PSEz6V7h76GGFgquXDDTODMonb+S3QzzEFkq7rprGwx5t5a+u0plTyqmN
 hXUHm3RUPVXYPPIslV+uUt8tOk1CHIL2hZfGgTLe7aBXSujSp/LEMzjI3OrDUCSfSDhc
 Mj0NBCjk8SEzKFfDEyWu60udfScOunIgxWFV7SSOZNui9yZdGZY4txGvO24Ge8qqVmCC
 SR85V2Ng4vn9lWREZ2gFzaupeuR+WU6AjzahLq1TFNYf2B7mi1iQqvxd1VA64SHGFERP
 5Zp6MGQ0yWffWibBSVi9w/cgA06QPnghhvL/JpdZS54bPKYEzusehIEkMontk/K6Iblz
 w46Q==
X-Gm-Message-State: AOAM531Hmc/D+JPhqoEhUf33aF774f4u03NubPuff3kAorTsqaWM9WvF
 ThXv4mJJBTMSQ3hRhA380rRdCO+y2aK8sAhyCQur7YM5V/fKeA==
X-Google-Smtp-Source: ABdhPJzXVXMkaf+Jp36ww+6adzWAMJBBIDpKoixFG2KoO9Z5zS5B8Ll6mvwrfMOGjXT24RdyvLcBFWJX0vjbMky3klc=
X-Received: by 2002:adf:fc4e:: with SMTP id e14mr9990127wrs.329.1601766408257; 
 Sat, 03 Oct 2020 16:06:48 -0700 (PDT)
MIME-Version: 1.0
From: Mike Brooks <m@ib.tc>
Date: Sat, 3 Oct 2020 16:06:19 -0700
Message-ID: <CALFqKjTxPppA_T1i77eddWTXF13XmLkLLWZnL4ZjmBvJ_cbw=g@mail.gmail.com>
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c71a3e05b0cc4deb"
X-Mailman-Approved-At: Sun, 04 Oct 2020 01:36:03 +0000
Subject: [bitcoin-dev] Preferential Treatment in AttemptToEvictConnection()
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Sat, 03 Oct 2020 23:06:52 -0000

--000000000000c71a3e05b0cc4deb
Content-Type: text/plain; charset="UTF-8"

Hey Everyone,

A lot of pressure rides on AttemptToEvictConnection() because it is used to
limit the impact of eclipsing attacks. With continued centralization, fair
connection formation becomes a bigger concern. I am curious how other
members of the community feel about the preferential treatment and odd
comments found in AttemptToEvictConnection().  In short, the concern is
that an adversary which intends on providing the useful service of
data-arbitrage will have preferential treatment in the formation of the
network.

https://github.com/bitcoin/bitcoin/blame/df2129a2349b1877049f250551f49a4592e73765/src/net.cpp#L946-L981

Line 948:
// An attacker cannot predict which netgroups will be protected
->
Perhaps not, but the attacker can have more netgroups than node slots, this
can be optimized for. Simply being in different places does not mean the
nodes are honest or safe. This is probably a good check to have, but it
should not say an "attacker cannot", as this is misleading.

Line 952:
// An attacker cannot manipulate this metric without physically moving
nodes closer to the target.
 ->
Yes, that is exactly what the attacker will do. An attacker can run
tcp-traceroute on the network to find where miners clump up, and run a
malicious message-relay in a nearby datacenter. With a financial motive it
is cheaper to run a low-cost message relay than a mining node.


Line 955:
// Protect 4 nodes that most recently sent us novel transactions accepted
into our mempool. Add recently accepted blocks and txn to
AttemptToEvictConnection.
// An attacker cannot manipulate this metric without performing useful work
.->
If an honest node sees an novel transaction from a new incoming connection,
it will be less likely to remove it. A dishonest centralized-service can
preemptively send novel-transactions as part of the handshake for new
hosts, this will improve the odds of the connection staying open and
cutting contact with an honest node.


line 962:
// Protect 4 nodes that most recently sent us novel blocks.
// An attacker cannot manipulate this metric without performing useful work.
->
This code has the assumption that an adversary will play by the rules. An
attacker will manipluate this metric with the data-arbitrage of novel
blocks. An attacker can move newly created blocks from the source (large
mining pools) to all parts of the network which can be used to garner value
within the connection pool of new hosts.


All of the above checks, except for the one starting on 948 is subject to a
race condition.

All the best,
Michael

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

<div dir=3D"ltr"><div><span style=3D"box-sizing:border-box;font-size:12px;w=
hite-space:pre-wrap"><font face=3D"arial, sans-serif" style=3D"" color=3D"#=
000000">Hey Everyone,</font></span></div><div><span style=3D"box-sizing:bor=
der-box;font-size:12px;white-space:pre-wrap"><font face=3D"arial, sans-seri=
f" style=3D"" color=3D"#000000"><br></font></span></div><div><span style=3D=
"box-sizing:border-box;font-size:12px;white-space:pre-wrap"><font face=3D"a=
rial, sans-serif" style=3D"" color=3D"#000000">A lot of pressure rides on=
=C2=A0AttemptToEvictConnection() because it is used to limit the impact of =
eclipsing attacks.  With continued centralization, fair connection formatio=
n becomes a bigger concern.  I am curious how other members of the communit=
y feel about the preferential treatment and odd comments found in </font></=
span>AttemptToEvictConnection().=C2=A0 In short, the concern is that an adv=
ersary which intends=C2=A0on providing the useful service of data-arbitrage=
 will have preferential treatment=C2=A0in the formation of the network.

</div><div><span style=3D"box-sizing:border-box;font-size:12px;white-space:=
pre-wrap"><font face=3D"arial, sans-serif" style=3D"" color=3D"#000000"><br=
>   <a href=3D"https://github.com/bitcoin/bitcoin/blame/df2129a2349b1877049=
f250551f49a4592e73765/src/net.cpp#L946-L981">https://github.com/bitcoin/bit=
coin/blame/df2129a2349b1877049f250551f49a4592e73765/src/net.cpp#L946-L981</=
a><br><br>Line 948: </font></span></div><div><span style=3D"box-sizing:bord=
er-box;font-size:12px;white-space:pre-wrap"><font face=3D"arial, sans-serif=
" style=3D"" color=3D"#000000">// An attacker cannot predict which netgroup=
s will be protected=C2=A0=C2=A0</font></span></div><div><span style=3D"box-=
sizing:border-box;font-size:12px;white-space:pre-wrap"><font face=3D"arial,=
 sans-serif" style=3D"" color=3D"#000000">-&gt;=C2=A0</font></span></div><d=
iv><span style=3D"box-sizing:border-box;font-size:12px;white-space:pre-wrap=
"><font face=3D"arial, sans-serif" style=3D"" color=3D"#000000">Perhaps not=
, but the attacker can have more netgroups than node slots, this can be opt=
imized for. Simply being in different places does not mean the nodes are ho=
nest or safe.  This is probably a good check to have, but it should not say=
 an &quot;attacker cannot&quot;, as this is misleading.<br><br>Line 952:</f=
ont></span></div><div><span style=3D"box-sizing:border-box;font-size:12px;w=
hite-space:pre-wrap"><font face=3D"arial, sans-serif" style=3D"" color=3D"#=
000000">    // An attacker cannot manipulate this metric without physically=
 moving nodes closer to the target.</font></span></div><div><span style=3D"=
box-sizing:border-box;font-size:12px;white-space:pre-wrap"><font face=3D"ar=
ial, sans-serif" style=3D"" color=3D"#000000">=C2=A0-&gt; <br>Yes, that is =
exactly what the attacker will do. An attacker can run tcp-traceroute on th=
e network to find where miners clump up, and run a malicious message-relay =
in a nearby datacenter. With a financial motive it is cheaper to run a low-=
cost message relay than a mining node.</font></span></div><div><br></div><d=
iv><br></div><div><span style=3D"box-sizing:border-box;font-size:12px;white=
-space:pre-wrap"><font face=3D"arial, sans-serif" style=3D"" color=3D"#0000=
00">Line 955:</font></span></div><div><span style=3D"box-sizing:border-box;=
font-size:12px;white-space:pre-wrap"><div><span style=3D"box-sizing:border-=
box"><font face=3D"arial, sans-serif" color=3D"#000000">   // Protect 4 nod=
es that most recently sent us novel transactions accepted into our mempool.=
 Add recently accepted blocks and txn to AttemptToEvictConnection.</font></=
span></div></span></div><div><span style=3D"box-sizing:border-box;font-size=
:12px;white-space:pre-wrap"><font face=3D"arial, sans-serif" style=3D"" col=
or=3D"#000000">    // An attacker cannot manipulate this metric without per=
forming useful work</font></span></div><div><span style=3D"box-sizing:borde=
r-box;font-size:12px;white-space:pre-wrap"><font face=3D"arial, sans-serif"=
 style=3D"" color=3D"#000000">.-&gt;<br>If an honest node sees an novel tra=
nsaction from a new incoming connection, it will be less likely to remove i=
t. A dishonest </font>centralized-service can preemptively send novel-trans=
actions as part of the handshake for new hosts, this will improve the odds =
of the connection staying open and cutting contact with an honest node.<fon=
t face=3D"arial, sans-serif" style=3D"" color=3D"#000000"><br><br><br>line =
962:<br>   // Protect 4 nodes that most recently sent us novel blocks.<br> =
  // An attacker cannot manipulate this metric without performing useful wo=
rk.</font><font face=3D"SFMono-Regular, Consolas, Liberation Mono, Menlo, m=
onospace" style=3D"color:rgb(106,115,125)"><br></font></span></div><div><fo=
nt color=3D"#000000" face=3D"arial, sans-serif"><span style=3D"font-size:12=
px;white-space:pre-wrap">-&gt; </span></font></div><div><font color=3D"#000=
000" face=3D"arial, sans-serif"><span style=3D"font-size:12px;white-space:p=
re-wrap">This code has the assumption that an adversary will play by the ru=
les.  An attacker will manipluate this metric  with the data-arbitrage of n=
ovel blocks.  An attacker can move newly created blocks from the source (la=
rge mining pools)  to all parts of the network which can be used to garner =
value within the connection pool of new hosts.</span></font></div><div><fon=
t color=3D"#000000" face=3D"arial, sans-serif"><span style=3D"font-size:12p=
x;white-space:pre-wrap"><br></span></font></div><div><font color=3D"#000000=
" face=3D"arial, sans-serif"><span style=3D"font-size:12px;white-space:pre-=
wrap"><br></span></font></div><div>All of the above checks, except for the =
one starting on 948 is subject to a race condition.=C2=A0</div><div><br></d=
iv><div>All the best,</div><div>Michael</div><div>=C2=A0</div></div>

--000000000000c71a3e05b0cc4deb--