From: Mike Brooks <m@ib•tc>
To: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Preferential Treatment in AttemptToEvictConnection()
Date: Sat, 3 Oct 2020 16:06:19 -0700 [thread overview]
Message-ID: <CALFqKjTxPppA_T1i77eddWTXF13XmLkLLWZnL4ZjmBvJ_cbw=g@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2560 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 5586 bytes --]
reply other threads:[~2020-10-03 23:06 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALFqKjTxPppA_T1i77eddWTXF13XmLkLLWZnL4ZjmBvJ_cbw=g@mail.gmail.com' \
--to=m@ib$(echo .)tc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox