概述

当添加一个新消息-“sendheaders”时，比起“inv”消息来，节点更喜欢通过 “headers” 消息来接收新块的广播。

动机

自 0.10 引入“headers-first”下载块以来，假设块不能够连接到（有效）头文件链，块将不会被处理。因此，块的广播工作通常如下：

节点（N）用包含块 hash 的“inv”消息来广播新的tip
其他节点（P）用“getheaders”消息（请求 headers 直到有新的tip出现）和新的tip本身的“getdata”消息来响应“inv”
N 用一个“headers”消息（带有新 block 的 headers 以及任何前面的 headers，P 未知）和包含一个新 block 的“block”消息来响应

然而，在建立tip且其中一个新的 block 被广播的情况下，对于一个新区块这通常是更加高效的，就是这个节点 N 只广播block-header而不是去广播 block-hash 以及保存其他节点生成和传输的 getheaders 消息（和所需的block 定位符）。

在 reorg 的情况下，其中 1 个或多个 blocks 被断开连接，节点当前只是为新提示发送“inv”。在请求这些块之前，需要等到中间块的 headers 被交付，此时其他节点可以立即请求新的提示。通过广播 headers，其他节点可以立即请求从上一个fork点开始到块公告中的新提示出现所有中间块。

规范

sendheaders消息被定义为一个空的消息，其中 pchCommand == “sendheaders”
收到“sendheaders”消息后，将允许节点（但不是必需）通过发送新块的block-header来通知新的blocks（为了块连接，节点所认为的对等点可能需要与其他的块一起）
通过检查协议 version >= 70012 来启用功能发现