每个区块的第一笔交易都是矿工的 coinbase 交易：发行收入进它的口袋，区块高度的证明（BIP 34 的脚本压入）藏在输入里，隔离见证时代又有见证承诺（以 0xaa21a9ed 开头的特殊输出）写在其中，池化挖矿的 extranonce 分配合并在输入的脚本数据里。想读这些信息，v31.0 之前的办法很笨重——要么 verbosity 2 起把整个区块的交易数组拖回来再取第一笔，要么用 getblockheader 之外的多种 RPC 凑。v31.0 给 getblock 补了一个专门的 coinbase_tx 对象（#34512），现在 verbosity 1 就够。
对象里只有五个字段
按 v31.1 源码的序列化函数，coinbase_tx 是一张精简档案：
version：交易版本号。矿工版本滚动（BIP 310 风格的位借用）会体现在这里，审计算力行为时是个直接入口。locktime：nLockTime。coinbase 的锁时间几乎总是 0，因为它没有可竞争的输入。sequence：第一个输入的 nSequence 字段。coinbase 只有一个输入，这个字段把”读第一输入序号”变成了直接取数，历史惯例上它固定为0xffffffff，因为相对时间锁对没有真实输入的 coinbase 没有意义。coinbase：第一个输入 scriptSig 的十六进制。BIP 34 要求脚本开头压入区块高度字节（早期孤块重组时代留下的防御），解析挖矿归属、extranonce 结构都从这段字节开始。witness：见证栈的第一个元素，十六进制；只有存在见证数据时才出现。源码对 coinbase 的见证栈有硬性断言——非空时必须恰好一个元素。
五个字段之外没有金额、没有 vout 列表：发行补贴和费用收入的明细仍然要靠 verbosity 2 及以上取完整输出，或者用 getblockstats 看区块级汇总。这个对象的设计目标被发布说明写得很克制：“without fetching the full transaction data at verbosity 2+“——让常见元数据查询不再拖着几百笔交易跑。
实际用途的三个方向
矿池对账：把每个块的 coinbase 字段按约定结构拆出 worker 标识与 extranonce，配合 sequence 和 version 能核查出块方是否与预期一致。协议审计：version 的分布能看出矿工有没有参与版本位相关的信号；sequence 则是临时锚点等 v3 交易规则之外的一处老习惯观察窗。数据索引：只需要”某块高度证明 + 见证承诺”的轻索引程序（比如校验默克尔根承诺链），从 verbosity 1 响应里就能拿全，带宽和 JSON 解析开销都降一档。
别把它当交易对象用
coinbase_tx 不是”完整 coinbase 交易”——它是元数据切片。任何需要输出列表（发行收入给了哪个地址、OP_RETURN 写了什么）的场景仍然要用完整的 tx 数组路径。解析 coinbase 字符串时也请记住它是脚本字节而不是文本，高度前缀之后全是各家矿池自定义的填充格式，跨矿池解析前先看该池的公开格式说明。
与相邻读口的分工
三个读区块的入口各有位置：getblockheader 给区块头本体加链上下文（确认数、在主链与否），不碰交易；getblock 的 verbosity 1 在其上加 txid 清单与 v31.0 新增的 coinbase_tx 档案；verbosity 2 起才有完整交易对象。只要这个块的 coinbase 写了什么，verbosity 1 加档案就够，不必付全量带宽；审计发行输出与费用明细时别硬用切片，老实取完整交易。跨版本兼容的老规矩在这里同样适用：解析器对多出来的字段保持宽容——旧版本不会有 coinbase_tx，新版本也可能再加字段，按名取值、缺名容错，比整包结构断言活得更久。
解析脚本字段的两个提醒
第一个字段 coinbase：BIP 34 要求的高度压入在脚本开头——先一个长度字节，再是高度的小端编码，高度越小这段前缀越短。跨矿池解析务必先剥掉这个固定结构，剩下的才是各家自定义的填充区，各家格式并不互通，拿别家的偏移量硬套会读出乱码。第二个字段 witness：它是十六进制文本，比对承诺值之前先统一编码与大小写；拿字符串直接比较看似省事，遇到前导零的表示差异就会给你假阴性。两个字段合起来足够重建矿池归属判断，但前提永远是你手里有该矿池公开的脚本格式说明。
风险提示：字段行为基于 v31.1 源码，接口在版本间可能调整；本文是数据接口说明，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。