This makes sure that retransmits by a whitelisted peer also actually result in a retransmit. This was a bug introduced in 9524c4d3 (which is in 0.11.1).
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. This part may be acceptable as an alternative to #7099.
utACK-we-should-do-this-over-nothing. I will test too.
I still think that whitelist drastically changing our P2P behavior (instead of merely bypassing resource limits/banning/eviction) is highly surprising, and undermines the utility of whitelisting if we’re unable to unlink them; so I’d rebase 7099 on top of this and be open to making it default to on.
I think long term we should have another p2p message type which means “force relay this transaction” which we ignore the force part for non-whitelisted peers. … we we don’t manage to get initial transaction broadcast out of the basic p2p relaying mechanism first.
Would you oppose adding a non-debug log to this every time it does a forced relay and any time it fails to do one (due to DOS)?
Having it logged would help a lot with someone putting whitelisting things they shouldn’t while this behavior exists (like mining software) and spamming the network.
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.
