一、先给结论：高度不是备注，是共识规则
比特币的每个区块里第一笔交易叫 coinbase 交易，它没有真正的上一手输出：输入的前置引用是一串全零哈希加索引 4294967295，脚本里塞的也不是签名，而是一段自由数据。BIP34 规定的规则只有一句话：从规则生效起，每个区块的 coinbase 输入脚本必须以该区块高度的最短小端整数推入开头。注意两个关键词——必须以高度开头、必须是最短编码。比如第 900000 号块，脚本开头应是三字节的推数据操作码加 80 70 0D（十六进制小端），如果矿工多用一个前导零字节把它编成四字节，节点会以 bad-cb-height 的理由直接拒绝这个区块，而不是仅仅视为不标准。 这条规则属于共识层的软分叉：它没有加新命令，只是让一部分原本合法的区块变成非法。理解这一点很重要，因为它决定了升级的紧迫性排序——不升级的节点不会丢币，但会把新规则区块当旧规则区块接受，这是分叉风险的经典配方。
二、为什么要立这条规矩
BIP34 的核心动机是给每个区块一个天然唯一的记号。coinbase 的自由数据字段里矿工通常放额外随机数，用来穷举哈希空间，但如果缺少高度这个强制成分，理论上可以构造出两个高度不同、内容却完全一样的 coinbase，进而得到相同交易编号。交易编号相同会带来什么麻烦，BIP30 那篇讲的重复交易攻击就是前车之鉴：两条链各自带同一编号的交易时，节点记账会互相覆盖。把高度钉进 coinbase，等于给每条分叉历史盖了序号章，配合 BIP30 的重复交易禁令，才能彻底堵死”同一编号在两个高度各花一遍”的门缝。 同时诞生的还有区块版本号升级为 2。这里的设计相当务实：规则只对版本号 2 及以上的区块生效，矿工用版本号表明自己已经支持新规则，网络按”看到最近区块大量使用新版本即视为多数就绪”的旧式多数判定推进。按 Bitcoin Core 仓库的 BIP 状态表，高度规则从 2013 年 3 月 5 日的高度 224413 起对版本 2 区块强制生效，2013 年 3 月 25 日的高度 227931 起版本 1 区块彻底不再被接受，此后所有区块都得在 coinbase 里自报身高。
三、今天怎么读这个字段
对普通用户，BIP34 最实际的用处是白拿一个免费的防伪校验。任何区块浏览器、脚本或自己写的小工具，都可以把区块头声明的高度与 coinbase 脚本开头解出的整数对一遍。两者不符的区块一定是畸形数据——要么是你连到的节点在发坏数据，要么是解析工具读错了字节，要么数据本身被篡改过。在一台同步完成的节点上，这类不一致几乎不可能出现在规范链上，所以它是廉价的健康探针。 另一个场景是排障。矿工或矿池接入自建节点时，如果建块程序错误处理了高度编码——例如跨越 255、65535 这类字节边界时没换最短编码，或在错误的高度上建块——收到的报错就是 bad-cb-height，特征非常明确：其他检查全过，只有 coinbase 高度不对。对照上一个成功区块的 coinbase 脚本，一般一眼能看出是差一错误还是编码函数写错。 还要澄清一个常见误解：coinbase 里除高度外的剩余数据（上限为 100 字节减去高度部分）依旧自由，矿工的额外随机数、矿池的署名留言都在这个区域，它们不受 BIP34 约束，也不参与共识判断。规则只管开头那几字节，后面的自由空间照旧。
四、边界与自查清单
有几点不要外推。其一，BIP34 不保护”分叉攻击中两条链的 coinbase 相同”的情形——它只保证同一条链上高度唯一，两条平行链的同一高度本来就可以内容相同，真正对付重放要靠别的机制。其二，高度编码规则只覆盖共识必需部分；有些钱包或分析脚本会把 coinbase 自由数据解读出各种含义，那都是启发式，不是规则。其三，在极老的链上考古时，会看到 2013 年之前版本 1 区块的 coinbase 完全没有高度字段，那是历史合法状态，不是数据损坏。 自查三步：取一个近期区块，对比区块头高度与 coinbase 脚本首段；用最短编码手算一遍应有字节；再取 2013 年前的一个历史块做对照，亲眼看一次规则前后的差异。做完这三步，你对”软分叉如何改写数据格式”的理解就从概念变成了手感。
本文内容仅供信息与教育参考，不构成投资建议、法律或税务意见，也不构成对任何产品或服务的推荐。比特币价格波动剧烈，操作不可逆，涉及资产操作前请自行核实关键参数并评估风险。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。