This protect any not-already-protected peers who were the most recent to relay transactions and blocks to us.
This also takes increases the eviction agressiveness by making it willing to disconnect a netgroup with only one member.
This protect any not-already-protected peers who were the most recent to relay transactions and blocks to us.
This also takes increases the eviction agressiveness by making it willing to disconnect a netgroup with only one member.
956 | + vEvictionCandidates.erase(vEvictionCandidates.end() - std::min(4, static_cast<int>(vEvictionCandidates.size())), vEvictionCandidates.end()); 957 | + 958 | + if (vEvictionCandidates.empty()) return false; 959 | + 960 | + // Protect 4 nodes that most recently sent us blocks. 961 | + // An attacker cannot manipulate this metric without performing useful work.
Ack
Actually, I think an attacker can manipulate this metric without performing useful work. It's quite trivial to for a node to send blocks invs to all its connected nodes as soon as it sees a block inv for a new block, and this can mean that many nodes see the block inv from this "cheating" node first since it didn't even need to start downloading the block before it was able to do this. Nodes try to download the block from the first node that alert about it, which would mean it was this "cheating" node that would be the node that provides the full block, and therefore this would mean that BOTH the block propagation is slowed down AND that the node(s) responsible for this happening continue to be prioritized due to this code. A better solution would be to regularly test which of the connected nodes actually deliver the block quickest - perhaps by requesting blocks during quiet periods (when a new block hasn't just been released) and see which deliver it fastest. Also, it might be that the node which broadcasts the block inv first becomes one of the slowest nodes to relay the actual block due to the fact that so many nodes are requesting the block from it. Perhaps the 2nd or 3rd node that sent the block inv would be able to deliver the block quicker. Perhaps, depending on the bandwidth of the sending and the receiving node, it would be more efficient and safer to request the newly announced block from 2 or more nodes concurrently, and reward the node (in this code) that delivered it soonest. The bandwidth of nodes (ours and theirs) could be tested and this information used to determine the best way to request the blocks.
856 | @@ -852,6 +857,21 @@ static bool ReverseCompareNodeTimeConnected(const NodeEvictionCandidate &a, cons 857 | return a.nTimeConnected > b.nTimeConnected; 858 | } 859 | 860 | +static bool CompareNodeBlockTime(const NodeEvictionCandidate &a, const NodeEvictionCandidate &b) 861 | +{ 862 | + if (a.nLastBlockTime != b.nLastBlockTime) return a.nLastBlockTime < b.nLastBlockTime;
Isn't this backward? This sorts by increasing last block time, and erases the last items.
Erasing protects them from being evicted, thus keeping the most recent sources.
Ah!
Can be attacked by sending the same block repeatedly.
Fixed. (@sipa is this what you suggested?)
Indeed!
Can one of the admins verify this patch?
utACK e6d8aaed0e4cc2a82715969371a0c026a3fc47fd
Needs rebase.
Rebased.
needs rebase.
Rebased.
No problem.
858 | @@ -854,7 +859,22 @@ static bool ReverseCompareNodeTimeConnected(const NodeEvictionCandidate &a, cons 859 | 860 | static bool CompareNetGroupKeyed(const NodeEvictionCandidate &a, const NodeEvictionCandidate &b) { 861 | return a.nKeyedNetGroup < b.nKeyedNetGroup; 862 | -}; 863 | +} 864 | + 865 | +static bool CompareNodeBlockTime(const NodeEvictionCandidate &a, const NodeEvictionCandidate &b) 866 | +{ 867 | + if (a.nLastBlockTime != b.nLastBlockTime) return a.nLastBlockTime < b.nLastBlockTime;
Please add a comment here explaining why there is a fail through.
ACK 3b3f45d532bd8f4c917ff78340b63e355da0cf13
Anything more needed here?
This protects any not-already-protected peers who were the most
recent four to relay transactions and most recent four to send
blocks to us.
With the latest additions there are enough protective measures that
we can take the training wheels off.
utACK
utACK 6ee7f05622c32431a9815a96b31a6a65a821fdcc
ACK 6ee7f05622c32431a9815a96b31a6a65a821fdcc