getblocktemplate

在常规的 mode=template 模式下，彼得的软件会收到前一个区块、交易和允许领取的奖励等信息。这是一份工作方案，而不是已经挖出的区块。软件还要构造 coinbase，也就是分配奖励的特殊首笔交易，并完成区块组装。区块头是区块数据的简要汇总。软件随后才会搜索满足挖矿目标的哈希：它是区块头的数字化密码学指纹，满足目标后便构成 Proof of Work，即计算工作的证明。getblocktemplate 本身不接收收款地址，也不启动矿机计算。因此，请求成功并不等于彼得已经开始挖矿。 [1]

假设节点发来的数据格式是彼得的软件无法理解的。因此，请求要在 rules 字段中声明所支持的规则。这里核对的 Bitcoin Core v29.0 要求声明 segwit；在 Signet 测试网络上还要声明 signet。SegWit 的变化之一，是对交易验证数据的处理方式。仅仅填入正确单词不够，软件必须真的能够正确处理这些数据。capabilities 用于声明接口的其他能力，不能代替 rules。具体要求取决于实际采用的实现和版本。 [2]

data 字段包含按程序间传输格式排列的完整交易。这种排列过程称为序列化。字节是这些数据的基本单位，这里用数字 0–9 和字母 a–f 将它们写成十六进制形式。回复中还包含较短的交易标识符。根据技术文档 BIP 145，txid 的计算不包含 witness 数据，而 hash 包含这些数据。Witness 中包括证明支出授权的签名等内容。区块头里的主要 Merkle root 是全部交易的汇总指纹，它使用 txid，而不是 witness hash。混淆这些字段不只是叫错名字，还可能算出错误的汇总指纹，使组装的区块无效。 [3]

彼得不必不停询问节点是否有变化。Long polling 会让请求保持打开，直到服务器希望替换原来的资料。程序取得 longpollid 后将其原样传回，让服务器知道程序正在等待哪种更新，不应试图从其中的字符推断特定含义。BIP 22 要求允许较长的等待超时。如果反复收到不完整或无效的回复，应在重试之间留出间隔，而不是立即循环重试。因此，安静地等待本身并不代表服务故障。 [4]

即使只是重复普通请求，也不能保证每次都重新选择内容。Bitcoin Core v29.0 会缓存准备好的模板。当前一个区块改变时，它会重建模板；或者，当 mempool，也就是本地未确认交易集合发生变化，且距离上次准备已超过五秒时，也会重建。区块头的时间可以单独更新。因此，彼得可能再次拿到相同的交易组合，这并不表示节点卡住了。这种特定版本的行为，也不保证每次调用都会产生独一无二的挖矿任务。 [2]

彼得修改了组块方式，希望在投入大量计算之前发现错误。在 proposal 模式下，他把整个区块用十六进制写入 data。Bitcoin Core v29.0 也会检查 Merkle root，但不要求已经找到有效的 Proof of Work，也就是计算工作的证明。如果方案没有接在节点当前使用的链的最后一个区块之后，返回值是 inconclusive-not-best-prevblk。这表示该检查的前提不成立，并不是对方案有效性的完整判断。这样的预检查也不会把区块广播到网络。 [2]

软件找到所需的工作量证明后，可以通过 submitblock 提交整个区块。hexdata 携带完整的序列化区块，以十六进制表示，而不只是区块头或指纹。Bitcoin Core 29 文档规定，接受时返回 null，否则按规范返回文本结果。可选的第二个参数 dummy 会被忽略，并不用来设置奖励。节点接受区块不保证它会永远得到确认：后续链条的发展可能改变最终保留为主链的是哪一条分支。 [5]

刚启动的节点可能尚未下载并验证所需的历史记录。在主网 mainnet 上，如果没有连接的对等节点，或者还处于初始同步 IBD（initial block download）阶段，Bitcoin Core v29.0 就会拒绝提供模板。这关乎节点是否已经能够参与当前网络，而不是拒绝某个具体区块。因此，排查问题时要分清：long poll 正在等待、节点尚未就绪，还是区块方案检查返回了某种结果。它们看上去都可能是“没有新工作”，却需要不同的处理方式。 [2]