从Bitcoin-0.14升级至0.25时创世区块哈希不匹配问题求助

核心问题分析 #

从0.14到0.25的版本迭代中，Bitcoin核心对创世块生成的细节（尤其是交易输入脚本scriptSig的序列化逻辑、区块/交易的序列化规则）做了隐性调整，直接复用新版模板或简单修改参数会导致字节序列不一致，最终哈希不匹配。

具体修复步骤 #

• 严格对齐旧版scriptSig的字节序列
  旧版0.14中CScript() << height << std::vector<unsigned char>(...)的序列化结果，和新版用CScriptNum插入的字节流可能存在差异（比如整数的编码长度、字节序）。不要依赖CScript的重载操作符，直接硬编码旧版scriptSig的原始字节数组：

  // 替换新版的scriptSig构造代码，用旧版生成的字节数组直接赋值
  txNew.vin[0].scriptSig = ParseHex("这里填入0.14版本中生成的创世交易scriptSig的十六进制字符串");
  

  你可以在0.14版本的节点中，通过调试输出或调用scriptSig.ToString()获取对应的十六进制字节串。

• 完全复刻创世块的所有参数
  确保以下参数和0.14版本的创世块完全一致，任何微小差异都会导致哈希变化：

  • 区块层面：nVersion、nTime、nBits、nonce
  • 创世交易层面：nVersion、nLockTime、输出的scriptPubKey、挖矿奖励金额

• 禁用交易序列化的新增特性
  0.25版本默认可能包含一些新的序列化逻辑（比如见证数据字段），需确保创世交易的序列化和旧版一致：

  // 生成创世块时，使用旧版的序列化方式（不包含见证数据）
  uint256 hashGenesisBlock = block.GetHash();
  // 注意：不要使用GetWitnessHash()，创世块交易无见证
  

• 对比区块原始字节定位差异
  在0.14版本中导出创世块的原始十六进制字节（block.ToString()或调试输出block.SerializeToString()），然后在0.25版本中生成创世块后，同样导出原始字节，逐字节对比找出差异点——通常问题出在scriptSig、交易版本的序列化格式上。

验证方法 #

修改完成后，先注释掉哈希断言，运行节点生成创世块，导出其原始字节和哈希，确认与旧版一致后再恢复断言。

内容的提问来源于stack exchange，提问作者queryman2000