Remaining p2p issues

[pavel-kokolemin]

The list of some remaining p2p issues:

High priority:

• [x] Outbound connections should only be made to full nodes.
• [x] Initiate new outbound connections when a stale tip is detected, such as when there has been no new block for a long time.
• [x] Block-relay only/anchor peers are not implemented (to mitigate topology inference and Eclipse attacks). Two additional outbound connections should be established for which only blocks are sent. The node should attempt to maintain connections to the same nodes after a restart.
• [x] Ensure that upgrading the protocol will allow sending new messages without having a conflict with older versions, such that we older peers never ban newer peers for sending messages they don't understand.
• [x] Drop announced transactions in peer v2 after some time to avoid cluttering memory. This problem has to be studied even further to see whether storing these transaction ids makes sense in the first place.

Low priority:

• [x] Peer eviction logic does not take into account which peers are sending novel blocks and transactions.
• [x] Minimum relay fee is low (DoS).
• [x] Hard-coded list of reachable nodes (in ChainConfig) is not used in cases when all DNS servers are unavailable. Also add current DNS seeds to ChainConfig.
• [x] Unlimited address storage in PeerDb (DoS).
• [x] Feeler connections (used to test new addresses) are missing.
• [x] IP whitelisting is not implemented. It may be difficult to establish persistent connections between your own nodes.
• [x] Possible to ban output Tor nodes (bitcoin uses discouraging for this reason), forcing the node to use malicious exit nodes. (If we ban IP addresses, an attacker can cause the IP addresses of "honest" exit nodes to be banned (by connecting from Tor exit nodes and breaking the protocol). Once all the "honest" exit nodes in the network are banned, only malicious exit nodes will be available. Thus, when users connect through Tor, they would be forced to connect through malicious exit nodes, allowing various attacks. To prevent this attack, Bitcoin lowers the priority of misbehaving peers, but allows incoming connections.) Note: for mainnet we decided to just reduce ban time from 24h to 30 min. In general, we still have to decide what to do with banning, see #1388
• [x] Using Tor socks proxy has some deanonymization risks because we use static noise keys.
• [x] Transactions are relayed without delay, allowing deanonymization attacks.
• [x] Address list responses are not cached to prevent fingerprinting. (Bitcoin caches IP addresses returned in the AddressList request for 24 hours. Without this, it's possible to infer the network topology)

Extensive reference to most known p2p attacks in the bitcoin network: https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9877811

Some of the existing TODOs:

• [x] Currently we always query dns seeds early even if outbound connections exist. This was done to ease new protocol version testing, where we would start multiple nodes on the same machine inside docker containers and pass their addresses to each other as "boot nodes". Without the early dns query, the nodes would first connect only to each other and then get stuck doing nothing until the "stale_tip_time_diff" interval had passed. But in general, querying dns seeds should better be done only if there are no other means of obtaiing peer addresses (except for the predefined address list, which has even lower priority), so that if a dns seed is compromised, it can only influence a limited number of nodes (e.g. the fresh ones or the ones struggling to find a peer). Perhaps, we need a command line switch to force an early dns query to use when testing and disable it in general.
• [x] Currently when establishing a new automatic outbound connection we ignore addresses in address groups that already have an automatic outbound connection. But should we also ignore those that have manual outbound connections?
• [x] During outbound peer eviction, when filtering out connections that are not old enough, we should also filter out those that have a block in-flight.
• [x] Banning vs discouragement. We should phase out banning peers and use discouragement, in the sense we disconnect them, stop connecting to them actively and stop sharing their address, and a few more things.

Additionally:

• [ ] p2p/README.md is outdated

[TheQuantumPhysicist]

@pavel-kokolemin What's the status on this?

[TheQuantumPhysicist]

To be clear I'm asking because it seems that we're working on some of them.

[TheQuantumPhysicist]

Maybe update the readme file and let's close this one.