Bitcoin Core 0.7.0 版本技术解读：BIP 22/34/35 落地与 RPC、P2P 体系的演进起点

本篇基于仓库中的历史发布说明 doc/release-notes/release-notes-0.7.0.md，系统回顾 Bitcoin Core（bitcoin/bitcoin）0.7.0 在协议、RPC 与网络层的标志性变更——它淘汰了 getmemorypool，让矿工协议站上 getblocktemplate/submitblock 的舞台，并将 BIP 22、BIP 34、BIP 35 第一次带进主线版本。读完本文，你既能掌握"从旧节点迁移到 0.7.0"的完整操作与跨 Berkeley DB 版本的处理要领，也能顺着当前仓库源码追踪这些设计 13 年后的去向，理解现代 Bitcoin Core 矿池接口、coinbase 高度校验与交易广播机制的起源。

---

1. 0.7.0 的定位与升级指引

0.7.0 发布于 2012 年 9 月，是 Bitcoin Core 从"节点工具"走向"平台化协议栈"的承前启后版本。发布说明明确建议所有运行旧版 bitcoind/Bitcoin-Qt 的用户升级到本版本，唯一的例外是 Mac OS X 10.5 用户。同一次发布还首次成体系地实现了三个 Bitcoin Improvement Proposal，并替换了内部 HTTP 服务与 P2P 地址存储等底层基础设施，因此升级动作本身也值得按发布说明的步骤谨慎执行。

1.1 三种平台的升级操作

发布说明给出的升级路径是"先停旧、后换新"，并且特别强调要让旧进程完全退出——老版本关闭时可能需要数分钟处理数据库：

平台	操作
Windows	关闭旧版后运行安装程序覆盖安装
macOS	关闭旧版后替换 /Applications/Bitcoin-Qt
Linux	关闭旧版后替换 bitcoind / bitcoin-qt 可执行文件

如果读者需要从源码自行构建当前仓库的二进制，可以参考 INSTALL.md 以及 doc/build-unix.md；跨平台依赖统一由 depends 子系统编排。

1.2 跨 Berkeley DB 版本的 -detachdb 迁移

这是本发布说明中最具操作细节的一条历史经验。若旧版本使用不同版本的 Berkeley DB 编译（典型场景是此前使用 PPA 构建、如今切换到官方二进制发布），升级前必须用旧版本以 -detachdb 参数再运行一次并正常关闭。其作用是把钱包数据库从旧版 BDB 的共享环境（environment）中"脱离"出来，否则新版 BDB 将无法读取旧环境的数据库文件，节点会直接报错退出。

# 用旧版本执行一次，等待完全关闭
bitcoind -detachdb

需要说明的是：-detachdb 是一次性的历史迁移参数，随着 BDB 钱包存储在现代 Bitcoin Core 中逐步退出主线，该参数已不存在于当前版本的启动参数表（可对照 src/init.cpp 中的 AddArg 列表，如今钱包层由 src/wallet 管理）。在 0.7.0 时代，它却是跨发行版、跨编译来源升级能否成功的关键开关。

1.3 下载渠道与 PPA 自动更新

发布说明同步提供了源码包与 Ubuntu PPA 两种获取方式。其中由 Matt Corallo 维护的 ppa:bitcoin/bitcoin 是当时 Ubuntu 用户自动跟进版本更新的主流途径：

sudo apt-add-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install bitcoin-qt

注：文中涉及的下载地址（SourceForge 归档、GitHub 源码包等）均为 2012 年的历史分发渠道，现已停用，此处仅作背景还原，不再展开。作者与维护者名单见第 8.3 节。

---

2. 不兼容变更：矿工 RPC 的换代与陈旧接口清理

0.7.0 是一次允许"打破兼容"的发布，发布说明以显著篇幅列出两类不兼容变更，其影响贯穿此后十余年的矿工协议：

1. 用 getblocktemplate/submitblock 与 getrawmempool 取代 getmemorypool——这是为对接 BIP 22 矿池模板协议所做的正名式替换；
2. 彻底移除被取代的 RPC getblocknumber——该接口职责已被 getblockcount 覆盖，属于清理性删除。

2.1 废弃接口在当代代码中的位置

getmemorypool 在 0.7.0 即已宣告死亡，从当前仓库的 RPC 注册表中搜索不到任何残余实现；而它的"继任者"至今仍活跃在代码库中，是验证这段演进的最佳锚点：

• getblocktemplate：定义于 src/rpc/mining.cpp，其帮助文本与 rules 参数已随 BIP 9 的落地演进到支持 segwit 等版本位规则，矿池接口从"0.7 模板"长成了"现代版本位协商"形态；
• submitblock：与 getblocktemplate 同处 src/rpc/mining.cpp，负责回传矿工提交的候选区块；
• getrawmempool：定义于 src/rpc/mempool.cpp，用于罗列交易内存池内容，其"展示与过滤未确认交易"的职责延续至今，并衍生出 getmempoolinfo 等姊妹接口。

从代码结构看，0.7.0 引入的"模板提取 + 提交结果"职责切分，正是后来 segwit 激活、版本位（versionbits）升级所依赖的 RPC 骨架，这一判断可以从 src/interfaces/mining.h 与 src/rpc/mining.cpp 对挖矿接口的持续抽象中得到印证。

---

3. 三个 BIP 的实现及其当前仓库佐证

发布说明把 BIP 的实现单独列为一节，这是 Bitcoin Core 首次以版本为单位集中交付"提案工程化"的成果。三者分别覆盖矿工协议、区块结构共识与 P2P 消息语义。

3.1 BIP 22：getblocktemplate 与 submitblock

BIP 22 定义了标准化的区块模板接口：矿池/矿机通过 getblocktemplate 请求一个包含交易集合与元数据的候选区块模板，完成工作量证明后再通过 submitblock 提交。相比旧版 getmemorypool 的轻量设计，它把版本号、previousblockhash、coinbase 附加值、交易依赖关系（depends）等显式暴露给调用方，使"中心化矿池分配任务、去中心化节点验证结果"成为可能。

当前实现位于 src/rpc/mining.cpp，一个典型的调用形态如下：

# 请求候选模板（0.7 时代的简化形态）
bitcoin-cli getblocktemplate '{"rules":["segwit"]}'

# 将算好的区块提交回节点验证并入链
bitcoin-cli submitblock '<hex 编码的区块>'

3.2 BIP 34：block version 2 与 coinbase 内嵌高度

BIP 34 要求新区块使用 version 2，并把区块高度编码进 coinbase 交易的脚本签名中，使节点无需回溯即可快速判定 coinbase 的成熟高度（coinbase maturity）与重组（reorg）边界。这条规则的执行位置直到今天仍是共识层的一等公民：

• 共识参数 BIP34Height 定义于 src/consensus/params.h，注释明确其语义为"BIP34 生效的区块高度与哈希"；
• 主网激活高度被记录为 227,931，见 src/kernel/chainparams.cpp 的 consensus.BIP34Height = 227931；
• coinbase 高度的实际编码逻辑集中在 src/node/miner.cpp 的 coinbase 构建流程中（接口层面的高度参数见 src/interfaces/mining.h 对 getCoinbaseTx() script_sig 前缀的说明）。

值得注意的细节是：BIP 34 的 roll-out 在 0.7.0 时代即已启动，而生效高度由后续版本最终确定——今天的 227,931 是软分叉在矿工算力阈值达成后的正式激活点。读者若在 0.7.0 当时的代码中查找，会看到基于"版本号超多数投票"的过渡逻辑。

3.3 BIP 35：mempool 消息与扩展的 getdata 行为

BIP 35 新增了 P2P 层的 mempool 消息：新同步节点发出 mempool 后，对等节点应答尚未确认的交易清单，帮助新节点快速补齐内存池视图；同时扩展了 getdata 消息的语义。该消息的处理路径在现代代码中依然可逐行核对：

在 src/net_processing.cpp 的 ProcessMessage 中，NetMsgType::MEMPOOL 分支会检查接收方是否通告 NODE_BLOOM 服务或具备 Mempool 权限——若既未开启 bloom filter 又没有相应权限，节点会记录日志并主动断开，这是 0.7 之后为配合 BIP 37 bloom 过滤而叠加的隐私与带宽保护。设置 m_send_mempool 标志后，下一轮消息循环会以 inv 形式向请求方推送内存池中的交易。

---

4. 核心交易处理与区块链数据库改进

发布说明对节点内部（"Core bitcoin handling and blockchain database"）列出了一批性能与健壮性改进，它们共同刻画了 0.7.0 的工程重心：把 CPU 花在刀刃上、把数据库当边界来防御。

• 降低 CPU 占用：消除若干重复的哈希计算。哈希运算集中于 src/hash.cpp 与现代 src/crypto 目录，0.7.0 的优化思路是避免同一数据多次触发 GetHash()/SerializeHash() 全量计算。
• 缓存签名校验：复用已验证过的签名结果，避免冗余的 ECDSA 校验。该思路在当代代码中演化为独立的签名缓存模块，隶属于 src/script 下的脚本执行体系。
• 零值输出交易视为非标准：sum(output value) == 0 或含零值输出的交易不再广播/打包。这条规则是 src/policy 交易标准性（standardness）策略的先声，也是抵御粉尘类 DoS 的基础约束之一。
• 出块排序按 fee-per-kb：创建新区块时，"已付费"（paid）区域按每 KB 费率排序，为后续 BlockAssembler 基于 feerate 的贪心打包算法（见 src/node/miner.cpp）定了基调。
• 数据库加强校验、小幅优化与可靠性提升：对磁盘存储数据做更严格的一致性校验。
• -loadblock=FILE 导入外部区块文件：该启动参数至今仍保留在参数表中，src/init.cpp 的注册文本为 "Imports blocks from an external file on startup. Obfuscated blocks are not supported."，实际导入循环位于同文件约 src/init.cpp 处。
• 新增 DoS 防御措施：发布说明末尾还特别致谢 Sergio Lerner 报告了本版本修复的若干拒绝服务漏洞。
• 在区块 193,000 处新增检查点（checkpoint）：用于加速早期区块的校验确认。历史上这些硬编码检查点最终被"assumevalid + 头同步限制"机制取代，现代同步保护的思路可参考 doc/design/assumeutxo.md。

---

5. JSON-RPC API 与内部 HTTP 服务器的重构

0.7.0 对 RPC 层的改动是架构级的，发布说明概括为五点，后文逐一结合当前仓库给出落点。

5.1 HTTP 服务器：从单线程队列到 thread-per-connection

内部 HTTP 服务器从"单线程队列"改为每连接一线程，消除了网络 I/O 阻塞导致整个 RPC 服务停摆的问题；同时支持 HTTP/1.1、请求流水线（pipelined requests）与 keep-alive 长连接。现代实现位于 src/httpserver.cpp 与 src/httprpc.cpp：前者管理 socket 生命周期与连接分发，后者把 HTTP 请求翻译为 JSONRPCRequest 并交给 src/rpc/server.cpp 的路由表。0.7.0 的"并发连接模型"如今已是 bitcoind 服务能力的默认前提。

5.2 JSON-RPC 2.0 批量请求

HTTP 层支持在一个请求内封装多个 JSON-RPC 调用（batch），显著降低轮询式客户端（如 GUI 余额刷新、矿池调度）的网络往返。批量请求的处理在现代版本中由服务端逐条路由、逐条返回结果，客户端侧则可通过 src/bitcoin-cli.cpp 构造多请求序列。

5.3 新 RPC 与重做清单

发布说明的 RPC 变更可整理为下表，右列为各接口在当前仓库的实现文件：

0.7.0 变更	说明	当前仓库实现
IPv6 支持	RPC 监听与连接层支持 IPv6 地址族	src/httpserver.cpp、src/netbase.cpp
新增 raw transaction API	直接广播/查询原始交易（sendrawtransaction、getrawtransaction 一族）	src/rpc、src/wallet/rpc 的原始交易接口
新增 getrawmempool	列出交易内存池内容	src/rpc/mempool.cpp
新增 getpeerinfo	列出每个已连接对等节点的详情（含 ping 时间等字段，GUI 的 src/qt/peertablemodel.h 也消费这些数据）	src/rpc/net.cpp
新增 listaddressgroupings	便于更好的 coin control（按地址分组展示余额归属）	src/wallet/rpc/addresses.cpp、src/wallet/rpc/wallet.cpp
重做 getblock	返回结构重新组织，提供更清晰的区块视图	src/rpc/blockchain.cpp
移除 getblocknumber	清理陈旧接口	—
移除 getmemorypool	由 BIP 22 接口取代	—
listtransactions 改进	输出"智能"时间显示，新增 blocktime 与 timereceived 字段	钱包交易列表 RPC 见 src/wallet/rpc/wallet.cpp

其中 getpeerinfo 后来还承担了 ping RPC 的结果载体——src/rpc/net.cpp 对 ping 的注释仍明确写着 "Results are provided in getpeerinfo"，说明 0.7.0 确立的"测量命令与查询命令分离"的交互模式沿用至今。

---

6. P2P 网络层：IPv6、Tor 与地址管理重构

P2P 一节是 0.7.0 信息量最密集的更新域，它同时回答了"如何连接更多网络"与"如何把连接状态管得更稳"两个问题。

6.1 传输与隐私能力扩展

• IPv6 支持：节点可与 IPv6 地址建立连接，为后续 IPv4/IPv6 双栈部署铺路。
• Tor 隐藏服务支持：0.7.0 引入了在 Tor 网络上以 .onion 隐藏服务身份提供/发起连接的能力，历史文档指引为 doc/Tor.txt，当代版本沉淀为 doc/tor.md，实现位于 src/torcontrol.cpp。
• SOCKS5 默认代理：代理协议默认切换为 SOCKS5，并支持把主机名交给代理解析——这使得节点可以经由代理连接域名形式的对等端。

6.2 地址簿：从 BDB 的 addr.dat 到自管 peers.dat

发布说明指出 0.7.0 用内部管理的 peers.dat 取代了 Berkeley DB 维护的 addr.dat，彻底摆脱了"地址缓存也要依赖 BDB 环境"的沉重包袱。这条架构决定保持至今：当前 src/addrdb.cpp 依旧以 peers.dat 为唯一持久化地址源，其日志分支可以逐条对上 0.7.0 的设计意图——文件缺失时记录 "Creating peers.dat because the file was not found"、版本不兼容时自动备份为 peers.dat.bak 并重建、损坏时给出显式错误提示。地址在内存中的表结构说明见 src/addrman.h（异步整表落盘到 peers.dat）。

6.3 新启动参数：出站网络的精细控制

0.7.0 一并引入了一批至今仍在使用的连接控制参数。结合当前仓库 src/init.cpp 的参数注册文本，可整理为下表：

参数	0.7.0 引入的功能	当前注册文本要点（src/init.cpp）
-seednode=<ip>	连接指定节点仅用于获取对等地址后即断开；走代理时以此替代 DNS seeds	见 src/init.cpp，支持多次指定
-externalip=<ip>	声明本节点对外公布的公共地址	见 src/init.cpp，且与 -discover 存在参数联动
-discover	开关本机公网地址自动发现	见 src/init.cpp，默认在监听且未设 -externalip/-proxy 时开启
-onlynet=<net>	只与指定网络（IPv4/IPv6/Tor）建立自动出站连接	见 src/init.cpp，可多次指定以放行多个网络
-bind=<addr>	独立监听 socket，按地址绑定入站监听	连接层选项
—	默认发送缓冲区由 10MB 下调至 1MB	降低单连接内存占用

参数之间还有精细的交互逻辑，例如 src/init.cpp 中设置 -proxy 或 -listen=0 会联动关闭 -discover，显式给出 -externalip 同样会抑制自动发现（保护隐私）；-onlynet 若排除了 IPv4/IPv6 则会自动关闭 -dnsseed（src/init.cpp）。这些"参数相互作用"（parameter interaction）规则正是 0.7.0 那批参数在后继版本中不断打磨的产物。

6.4 "卡死区块下载"修复

发布说明提到修复了"卡住的区块链下载"问题，这与地址簿重写、连接管理（peer 重试与超时）以及区块请求调度机制的调整相关。现代版本中区块下载调度逻辑位于 src/net_processing.cpp 的 ProcessGetBlockData/headers 同步路径，0.7.0 的修复是这条长链路早期的关键一跳。

---

7. Qt GUI：向"可运维桌面钱包"进化

0.7.0 的 GUI 改动密集，核心取向是把节点状态和钱包状态透明化，同时收敛交互细节。以下按发布说明的要点还原并适当分类：

调试与状态可见性

• 新增 UI 控制台 / 调试窗口（RPC console），用户可免命令行直接对节点发 RPC；
• 概览页新增两个标签，分别显示钱包与交易状态（过时 obsolete / 当前 current）；
• 概览页新增 immature balance（未成熟余额） 显示——与 BIP 34 对 coinbase 成熟规则的强调同源呼应；
• 区块数变化时持续轮询余额变化，保证 GUI 数据与链上进度一致；
• 区块下载期间采用细粒度 UI 更新，界面更平滑。

交互与可用性

• 重新启用 Windows 下 URI 处理，并加安全校验与托盘通知；
• 统一菜单与按钮上的省略号（"..."）使用规范——菜单保留、按钮不滥用；
• 选项对话框扩展（如语言选择）并重构为分页 UI；
• 签名/验证消息合并到单个分页窗口；
• 切换比特币单位时立即刷新所有使用该单位的界面元素；
• 更新二维码对话框；改善启动错误报告；
• 移除 UI 中对地址中 0/i 的自动纠正；托盘菜单按更合理顺序重排；
• 对使用分段进度条的平台覆盖进度条样式，保证可读性。

平台与工程

• 翻译质量大幅提升；
• （仅 Windows）为 bitcoin-qt.exe 启用 ASLR 与 DEP 并附加元数据（描述信息等）。

GUI 的全部实现与翻译资源位于 src/qt 目录（含 67 个 .cpp、69 个 .h、19 个 .ui 与 100 个 .ts 翻译文件），语言选择等 0.7.0 打下的交互骨架在该目录中延续至今。

---

8. 内部工程与杂项改进

• 更多单元测试：src/test 与 src/bench 两个目录承载了后续十余年的测试资产，0.7.0 的"补测试"动作是其起点之一；
• 编译警告清理：与 CI 中 ci/lint、ci/test 体系后来的严格告警检查一脉相承；
• 收到 SIGHUP 后重新打开 debug.log：便于运维在日志轮转（logrotate）后向节点发送 SIGHUP 让它重新打开日志文件，而不必重启进程。当代日志实现集中在 src/logging.cpp；
• bitcoind(1) 的 Bash 可编程补全：完整补全脚本至今保留在 contrib/completions/bash，是命令行用户快速上手 RPC 的低成本辅助；
• 在支持的 OS 上为每个线程赋予可读名称：现代实现见 src/util/threadnames.cpp，线程名前缀统一为 b-（例如 b-txrecommit），配合日志与调试器可以一眼识别线程职责。

8.1 致谢名单与安全披露

发布说明在结尾感谢了 0.7.0 的全部贡献者（涵盖 Gavin Andresen、Pieter Wuille、Gregory Maxwell、Wladimir J. van der Laan、Luke Dashjr、Jeff Garzik 等核心开发者），并特别致谢 Sergio Lerner 报告了本次修复的拒绝服务漏洞。这些信息还原了 0.7.0 在社区协作与安全披露机制上的样本意义——安全研究员私下报告、维护者集中修复、随版本统一致谢。

---

9. 延伸：如何在当前仓库中对照研究 0.7.0 的遗产

若想进一步验证本文的每一处论断，推荐按下表路径顺藤摸瓜：

研究主题	仓库路径
0.7.0 发布说明原文	doc/release-notes/release-notes-0.7.0.md
getblocktemplate/submitblock（BIP 22）	src/rpc/mining.cpp
getrawmempool（BIP 35 的 RPC 侧）	src/rpc/mempool.cpp
BIP 34 激活参数与主网高度 227,931	src/consensus/params.h、src/kernel/chainparams.cpp
mempool P2P 消息处理	src/net_processing.cpp
peers.dat 地址簿（替代 addr.dat）	src/addrdb.cpp
连接控制参数 -seednode/-onlynet/-externalip 等	src/init.cpp
HTTP/RPC 服务（thread-per-connection、批量请求）	src/httpserver.cpp、src/rpc/server.cpp
Tor 与 IPv6	doc/tor.md、src/torcontrol.cpp
Bash 补全与线程命名	contrib/completions/bash、src/util/threadnames.cpp

总体上，0.7.0 的意义不在于"发布当时有多新"，而在于它为后续每个版本划定了接口边界：矿工交互以模板协议为准绳，共识规则以 BIP 为立法入口，P2P 层以可配置网络（IPv4/IPv6/Tor）与自管地址簿为底座，RPC 层以并发 HTTP 与批量语义为性能前提。沿着这些主线去阅读 doc 目录下的各时代发布说明与 src 的实现，就能拼出 Bitcoin Core 协议演化的一整条清晰年轮。