Backport Bitcoin PR #8282: net: Feeler connections to increase online addrs in the tried table.

[OlegGirko]

This is backport of Bitcoin PR bitcoin#8282.

It implements a countermeasure against eclipse attack.

The original PR description follows.

These changes implement countermeasures 3 (feeler connections) suggested in our paper: "Eclipse Attacks on Bitcoin’s Peer-to-Peer Network".

Design:

We observe that a node's resistance to eclipse attacks grows as the number of online addresses in the tried table grows. To increase the number of online addresses in the tried table the following logic is implemented in net.cpp's ThreadOpenConnections:

1. Every 2 minutes a short lived feeler connection is made to a randomly selected address in new.
2. If the tested address is online and running bitcoind, this address is moved to the tried table.
3. The feeler connection to the tested address is closed.

Only one feeler connection is attempted at any one time and feeler connections are only attempted after all outgoing connections slots of filled.

Advantages:

• In our paper we sample several peer lists. We found that a large percentage of addresses in tried tables are stale IP addresses (the lowest was 72 percent stale, the highest was 95 percent stale). This large number of stale IP addresses increases the risk of eclipse attacks. This change remedies this by ensuring that the tried table grows quickly and contains many recently online addresses.
• Not only do feeler connections provide a direct benefit to the node doing the testing but the tested node, if online, learns about our node and adds it to its tried table (conferring herd immunity even under partial deployment).
• Countermeasure 3 (test-before-evict) builds on the feeler connections introduced in this change. This is the first step to deploying countermeasure 3.

Risk mitigation:

• To limit the network impact of the feeler connections we only make one new connection every 2 minutes. Compared with other networking tasks that bitcoind performs the bandwidth increase is very slight.
• To avoid issues of synchronization we introduce a random sleep of between 0 and 1000 milliseconds prior to making a feeler connection.
• To avoid threading issues the feeler connections are made in the same thread as non-feeler connections.

Test plan:

1. I'm currently running two EC2 nodes with public IP addresses. One is running this pull request and the other is running standard bitcoind. Both are running with arg -debug=1. At the end of the week I will post results from the logs looking at differences in the size of the tried table and examining the logs for any errors. I will also use the peer.dat files generated from this test to evaluate each nodes resistance to eclipse attacks.
2. I will also use packet captures to ensure behavior and bandwidth behaves as expected.
3. I invite anyone would like to help to run standard and feeler connection nodes and email me ([email protected]) the pcaps, logs and peers.dat files. I will post the results of this analysis here.

This change was suggested as Countermeasure 4 in
Eclipse Attacks on Bitcoin’s Peer-to-Peer Network,
Ethan Heilman, Alison Kendler, Aviv Zohar, Sharon Goldberg.
ePrint Archive Report 2015/263. March 2015.

[UdjinM6]

utACK