矿机矿池对接比特币核心 RPC 时，偶尔会遇到一种古怪故障：模板取到手、签名签好、工作量算对，提交却被拒收，理由指向区块体积。追到根上，常是一个多数人从没配过的参数：-blockreservedweight。它的全部职责是在组装区块模板时预先扣出一段权重，给挖矿软件随后要填的 coinbase 交易留位。v31.0 的帮助文本把这层意思写得很直，但也留下了几个需要源码才能确认的边界。
默认值与两道硬校验
v31.0 源码 policy/policy.h 里，默认常量 DEFAULT_BLOCK_RESERVED_WEIGHT 为 8000，安全下限 MINIMUM_BLOCK_RESERVED_WEIGHT 为 2000。权重与虚拟字节的换算按四比一，预留 8000 权重相当于给模板留出约 2000 虚拟字节的空间——数量级上刚好覆盖区块头之后一条较大的 coinbase 交易。参数注册在初始化阶段就设了两道闸门：配置值大于共识最大区块权重（4000000）时直接 InitError 拒绝启动，低于 2000 同样拒绝启动。也就是说它没有”调小试试”的灰色地带，写错数值连进程都起不来，日志里会指名道姓报出越界数字。
它到底在什么时候起作用
帮助文本里有一容易被略过的半句：“Only affects mining RPC clients, not IPC clients.”。走传统 getblocktemplate 路线的矿池软件受这个预留约束；而进程内多进程挖矿接口（IPC 路径）在客户端各自设定，不吃这个全局值。组装模板的代码把预留值做了钳制：未显式给出用默认，给出后夹在安全下限与共识上限之间。所以即使配置文件里写了天文数字，运行期的模板对象也会按规则收敛——但别忘了启动校验在前，越界值根本到不了运行期。
与 blockmaxweight 的相互作用
另一个高频困惑是它与 -blockmaxweight 的关系。源码注释给出一句耐人寻味的说明：保留权重可以安全地超过 blockmaxweight，代价只是区块模板的其余部分为空。翻译成故障语言——如果 blockmaxweight 设得很小而保留值很大，节点仍能正常出模板，只是里面几乎装不下交易，出块奖励照常、手续费收入归零。这种”合法但亏钱”的状态比启动报错更隐蔽，值得在容量变更后核对一次模板里的交易条数。
需要澄清的边界是：这个参数只影响你自己节点生成模板的取舍，不改变任何共识规则。别人节点验块时看的是最终提交的完整区块，预留多少与它无关；它的意义完全在于”你生成的模板是否给后续组装留了余量”。
什么时候需要动它
默认 8000 覆盖绝大多数矿池的 coinbase 结构。需要调整的场景集中在两类：一是 coinbase 里塞了较大字段（含较多额外数据的 payout 结构或未来协议信号位）导致默认余量不够，症状正是开头说的提交被拒；二是极简自建客户端确定自己只填极小 coinbase，想把余量收回到 2000 的下限以多装交易。两类都应当先用测试网核对模板字节数再改主网配置，并用 getblocktemplate 返回的重量字段验证生效。
排查顺序建议
第一步看启动日志有没有越界报错，确认参数被接受；第二步对比同一高度下改动前后的模板大小字段；第三步确认挖矿客户端真的在组装时补上了 coinbase——预留解决的是”没地方写”，解决不了”写错内容”。如果模板交易数莫名稀少，别忘了检查 blockmaxweight 与 blockmintxfee，三者共同决定模板长相。
与模板大小的日常核对
日常巡检里有一条低成本检查：取一次 getblocktemplate，把返回的 weight 与配置的 blockmaxweight、保留权重三者放在一起看。健康的自挖节点应当满足”模板实际重量接近上限但留有 coinbase 余量”的形态；如果模板重量长期远低于上限而 mempool 明明拥挤，问题多半在 blockmintxfee 的费率地板或保留权重的挤压上。把这条核对写进版本升级后的检查表里，能在第一时间发现默认值或语义的变化——参数不会自己报警，但数字会。
风险提示：本文为挖矿接口参数机制说明，对应 Bitcoin Core v31.0 源码；参数错误可能导致节点无法启动或模板异常，变更前请在测试网验证；不构成任何投资建议或收益承诺。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。