A peer that is behind is marked as "on a different chain", which is
ultimately correct, but the response to punish or ban them is too much.
We could very well reconnect later when the situation is resolved.
So, detect when a peer is simply behind and respond by disconnecting
without punishment.
On connect, we should ask for a HEADERS overview from the remote peer,
even if we aren't fully at the tip yet.
Also remove some old lookup no longer used.
Sometimes a node would not be online for a while and we'd incorrectly
ban them for a long time when we just need to mark them as not-
reachable-right-now.
Instead of assigning a privacy segment at connect, wait until we have
determined if this peer is on the same chain as us before we allocate a
peer slot.
This also helps us limit the amount of peers we send our bloom filter to.
This is done in several steps:
1. Separate my height from the remote peer heights.
Instead of assuming we have one height, recognize that a peer may
not be at the tip at the same time we are. We monitor headers/invs
to update the 'peerHeight' variable.
2. Ask for merkle blocks from a peer to the maximum height of that
peer (but not later than what we validated to be true).
This avoids us asking past the remotes tip which they didn't like.
3. Redo the SyncSPVAction to use all this and make it much more
reliable in finding peers to download from and getting all the
changes as fast as possible.
To send out transactions in the p2p net is quite a lot of work,
you need to find multiple peers to send the transaction to. First
you send an INV, then you respond to a getData to actually send
the transaction and last you wait for 'reject' messages that may
indicate that there is something wrong with the transaction.
This introduces the BroadcastTxData class that wraps a transaction
and gets callbacks for sending and for rejects, abstracting away
all the complexity for the user.
Based on the idea that randomly selecting a peer from our database will
prioritize based on the peers punishment score, this sets the punishment
for never connected-to peers at 10 (out of 1000) just to give a minor
benefit to speeding up the meshing.
This avoids a peer once sending acceptable headers and never
being bothered again. Instead we now check regularly and keep
track of when the peer was known to follow the same chain as us.
Avoid deleting and creating connections, which is really a rather rare
event anyway, and simply remember the connection object and reuse it
when a new one is requested.
The NetworkManager usage was mostly for low connection counts and this
made defaults selection easy.
With more usages it is important to allow the NWM-connection to be more
configurable about memory usage and leaner in general.
This changes the headers-buffers (used to create envelopes) to not be per
connection anymore but per thread using the tread_local keyword.
This changes the ring-buffers to become configurable using
NetworkConnections::setMessageQueueSizes().
Also removing some include statements where they were not really needed
in the P2PNet lib.
This changes handling to also remove peers that fail with:
"Cannot assign requested address"
An error seen in a Docker container on a system supporting IPv6.
Additionally we now always assign a error level so an unknown error will
still cause the node to be banned after 5 attempts.
This avoids a race condition on remove/delete of peer where
the connection manager decides to delete a peer while in its own thread
the peer is processing a package.
This moves deletion of the peer to its own strand.
We reuse the NetworkManager lower level code in order to connect
to the Bitcoin P2P network.
This implements the basics for anyone wanting to be a player on
this network.
tomFlowee
TomZ