From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 98458C0051 for ; 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 ; 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 ; 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 ; Sat, 3 Oct 2020 23:06:50 +0000 (UTC) Received: by mail-wr1-f43.google.com with SMTP id s12so5634762wrw.11 for ; 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 Date: Sat, 3 Oct 2020 16:06:19 -0700 Message-ID: To: bitcoin-dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Hey Everyone,

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 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.
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 "attacker cannot", as this is misleading.

Line 952:


Line 955:
// Protect 4 nod= es 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 per= forming useful work
.->
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 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.


line = 962:
// Protect 4 nodes that most recently sent us novel blocks.
= // An attacker cannot manipulate this metric without performing useful wo= rk.
->
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.


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

All the best,
Michael
=C2=A0
--000000000000c71a3e05b0cc4deb--