Updated.

Did some basic testing, and looks good to me.

Mental note: perhaps this should limit itself to 8-16 new entries or so. If it's more, rely on peer's incremental synchronization to catch up (inspired by a comment by @sdaftuar in #5982).

EDIT: implemented

I guess one side effect of this is that when announcing a reorg to an 0.10 peer, this increases the overhead. Say there are N blocks announced in the inv generated here. Then an 0.10 peer will generate N getheaders messages (with the same locator in each, but with a different hashstop), and the 0.10 peer will therefore receive N headers responses, with {0,1,...,(N-1)} headers in each message.

The total overhead is still not that large in absolute terms I think, but with N^2 behavior here, maybe this argues for the cap being more like 4 or 6, rather than 16?

Also I think in the case that we are truncating the inv's, perhaps it would be better to revert to only inv'ing the tip, rather than announcing up to our cap (whatever we pick for that value), since 0.10 nodes would otherwise be requesting the same long chain of headers multiple times.

@sdaftuar Hmm, maybe that's a reason to only send all hashes when using 'headers' announcements, not 'inv' announcement (#5982)?

@sipa Yes I think that's reasonable, and that's the approach I'm trying for #5982 -- when inv-ing, only announce the tip; but when announcing headers, be willing to announce everything back to the last fork point (with some limits, as discussed in that issue).

concept and light review ACK.

Main comment: If many nodes on the network are re-org'ing at once, doesn't this cause traffic to spike?

I'll see if I can queue up some worst case local testing in a week or so, if nobody beats me to it.

Superseded by #6494.