Enable high-priority alerts to put the RPC into safe mode
This reverts the changes in 986b5e257e and adds a priority check.
Continuation of #1337Closes#1106
Upstream patch: Fix and improve relay from whitelisted peers
https://github.com/bitcoin/bitcoin/pull/7106
a9f3d3db5c0c8d1697998ed9b3e192ddbf9a31f4
An extra commit modifies the log message string, otherwise there are are a number of commits that need be to backported to add methods e.g. GetDebugMessage. These commits modify the interface in consensus/validation.h so there are conflicts to be resolved. e.g.
9003c7c
a9ac95c
5f12263
fbf44e6
This makes sure that retransmits by a whitelisted peer also actually
result in a retransmit.
Further, this changes the logic to never relay in case we would assign
a DoS score, as we expect to get DoS banned ourselves as a result.
The setAskFor duplicate elimination was too eager and removed entries
when we still had no getdata response, allowing the peer to keep
INVing and not responding.
mapAlreadyAskedFor does not keep track of which peer has a request queued for a
particular tx. As a result, a peer can blind a node to a tx indefinitely by
sending many invs for the same tx, and then never replying to getdatas for it.
Each inv received will be placed 2 minutes farther back in mapAlreadyAskedFor,
so a short message containing 10 invs would render that tx unavailable for 20
minutes.
This is fixed by disallowing a peer from having more than one entry for a
particular inv in mapAlreadyAskedFor at a time.
