Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
server: Always respond to getheaders.
The existing logic for responding to getheaders is based on the old sync model before headers-first syncing was introduced and thus avoids responding whenever the current local chain is not considered to be current. This existing behavior was important under the the old sync model since it would otherwise lead to unnecessarily downloading a bunch of blocks among other undesirable corner cases, however, it does come with some downsides. For example, one less than ideal consequence of not responding is that it can lead to peers appearing to be unresponsive and/or stalled rather than merely not having anything interesting yet. Also, there are a variety of corner cases where a peer might temporarily no longer consider itself current such as after being unable to communicate with the network for a long time, or in testing scenarios where there are necessarily long periods of time without any new blocks. However, since peers now use the headers to determine what blocks to download, serving up headers before the peer is known to be current no longer leads to undesirable behavior. Taking the aforementioned factors into consideration, this modifies the semantics to always respond to getheaders requests, even before the local chain is fully synced. Further, in order to avoid needlessly sending extra data early during the initial sync process and to provide some additional protection against low-effort DoS attempts, a new check is introduced to respond with empty headers when the local chain does not yet have the minimum cumulative work value already known from the chain parameters to have been achieved on the network. Responding with empty headers signals to the remote peer that there are not any interesting headers available without the local peer appearing unresponsive.
- Loading branch information