avoid sending redundant blocks to peers that have already seen the block

[antiochp]

Can we avoid sending full blocks to peers if they have already seen the block? Blocks could be significantly large and it would be desirable to avoid the network traffic if we can avoid sending redundant data.

Currently we see the following on the receiving end if the node determines it has already seen the block sent by a peer -

Nov 09 04:13:14.728 INFO Rejected block c960e75f at 239: Unfit("already known")
Nov 09 04:13:14.728 DEBG Block c960e75f refused by chain: Unfit("already known")

Possible solution - Can we send the block_header or even the hash and have the receiving node request the block if it has not yet seen it?

[ignopeverell]

There are 2 different things:

• Not sending anything if we know a peer already has that information.
• Not sending a whole block right.

The first point should normally be handled with this:

https://github.com/mimblewimble/grin/blob/master/p2p/src/peer.rs#L184

Is this not working for you? There's always the case of A mining a block and sending to both B and C, neither B nor C knows the other has the block so they will have to try sending no matter what.

Now regarding the 2nd point, it may be a good idea to switch to header first. So we first only send the header (which is much smaller) and a peer can then choose to request the body if it has never seen it.

[antiochp]

Looks like #257 covers the 2nd point :+1:. And yeah the known collection in the adapter handles this on the receiving side - I was thinking more in terms of the bandwidth of sending full blocks to peers that may be highly likely to have already seen them (particularly once we go beyond a handful of test nodes).

[antiochp]

Closing this - covered in #257.