net: only use the 15s block retry spacing at the tip

nRequestTime lives in mapAlreadyAskedFor, which is global to the inv, so
the spacing AskFor applies is not per-peer pacing: it is what strings the
getdatas for one block across its announcers. Shortening it to 15s was
right at the tip and wrong everywhere else, and the eight-entry cap that
made the failover table safe for catch-up does not cover this at all --
it is a different mechanism.

At two minutes a second announcer's queued request almost always fired
after the block had arrived, so AlreadyHave dropped it. At fifteen
seconds, with a peer working through a 500-deep queue and block N
legitimately minutes away, the second announcer is asked at +15s, the
third at +30s, and the bulk download arrives once per announcer -- up to
eight times over, with nothing bounding it.

So the fast spacing is now conditional on tracking the tip, measured off
the age of our own best block. Not off a peer-reported height:
nStartingHeight is optional in the version message and every node
released so far sends the short form, so it is -1 for essentially every
peer, and where it does get filled in later it comes from the height of
a block that peer served us, which during catch-up tracks our own height
and would answer "at the tip" for the entire download. Block timestamps
are the one clock a peer cannot move, being bounded above by CheckBlock
and below by AcceptBlock's median-time rule.

Thirty block intervals is the threshold: far longer than any stall worth
failing over from, far shorter than catching up. Failover at the tip
does not rest on this in any case -- mapBlockFetch re-issues a stalled
getdata to the next peer on its own 15s timer, and that is what actually
answers #33.

0 files changed, 0 insertions, 0 deletions