Bitcoin Core 0.3.22 发布说明详解：手续费调度、DNS 节点引导与早期钱包 RPC 的演进

本文以 doc/release-notes/release-notes-0.3.22.md 为主线，逐条解读 Bitcoin Core 0.3.22 版本的六项显著变更与三项 RPC 变更，并对照当前仓库源码，追踪 -dns 节点解析、listtransactions、settxfee 等特性从 2011 年至今的演变轨迹，帮助读者理解早期手续费调度机制与网络引导机制是如何演化为今天代码库中的对应实现的。

一、版本定位：一次以修复和手续费调度为主的发布

原文档开篇即给出该版本的自我定位：

This is largely a bugfix and TX fee schedule release. We also hope to make 0.3.23 a quick release, to fix problems that the network has seen due to explosive growth in the past week.

即 0.3.22 主体上是缺陷修复 + 交易手续费（TX fee）调度的发布，并预告 0.3.23 将是一次快速跟进发布，以修复网络在"过去一周爆发式增长"中暴露的问题。从这句话可以推断，0.3.22 所处的时代（2011 年前后）正是节点数量与交易流量快速膨胀、网络开始暴露容量与引导问题的阶段——这也正是后文"IRC 溢出""DNS 引导"等变更出现的历史背景。

二、显著变更逐条解读

2.1 手续费调度：节点侧 0.0005 BTC，钱包侧仍按 0.01 BTC/kb 计费

原文档第一条：

Client will accept and relay TX's with 0.0005 BTC fee schedule (users still pay 0.01 BTC per kb, until next version)

含义需要拆成两半理解：

• 节点（网络）侧：客户端开始接受并中继带有 0.0005 BTC 固定手续费调度的交易；
• 钱包（用户）侧：用户的钱包此时仍按 0.01 BTC/KB 的费率构造交易，这个行为要"直到下个版本"才会变化。

也就是说，0.3.22 是一次单边先行的手续费调整：中继阈值先降下来，钱包默认发送费率延后到下一版本再降。这种"网络侧与钱包侧分版本松绑"的调法，在当时是应对交易量激增、让低费率交易能够进入中继网络的实际手段。

放到当前仓库对照，中继费率的代码化程度已完全不同：最低中继费率现在是按 satoshi/KB 的常量定义的，见 src/policy/policy.h：

inline constexpr unsigned int DEFAULT_MIN_RELAY_TX_FEE{100};

即默认 100 satoshi/KB（0.00001 BTC/kb），并通过 src/kernel/mempool_options.h 中的 CFeeRate min_relay_feerate{DEFAULT_MIN_RELAY_TX_FEE}; 传入内存池校验。此外 src/policy/fees/block_policy_estimator.h 中还有 MIN_BUCKET_FEERATE 等历史继承关系注释，说明今天的费率体系已从"固定 0.0005/0.01"演进为一套以 sat/KB 为单位的、含动态费率的估算体系。从 0.01 BTC/kb 到 0.00001 BTC/kb 的量级变化，本身就是这二十年交易规模扩张的一个注脚。

2.2 Testnet 上接受非标准交易

Non-standard transactions accepted on testnet

这条变更明确了主网与测试网在脚本标准性上的分治策略：testnet 上放宽非标准（non-standard）交易的接受。其工程价值在于给非共识层面的实验（非标准脚本模式、非常规输出结构等）提供一个安全的演练场，而不污染主网的中继规则。这一"testnet 先行"的思路在后续 Bitcoin Core 的开发文化中一直是惯例，例如许多共识级特性都会先在测试网络验证再进主网。

2.3 源码树重组，为 autotools 构建做准备

Source code tree reorganized (prep for autotools build)

0.3.22 时期源码目录结构被重新组织，目标是引入 autotools 构建系统。从当前仓库结构可以印证这次重组是长期构建系统演进的第一步：如今仓库根目录已同时存在 CMakeLists.txt、CMakePresets.json 与 depends/Makefile 等多套构建设施，depends/ 下还按主机/目标平台拆分了 hosts/*.mk、builders/*.mk（如 depends/hosts/linux.mk、depends/hosts/darwin.mk），这正是当年为跨平台自动化构建所铺设目录骨架的延续形态。

2.4 移除 GUI"挖矿"入口与 4 路 SSE 矿工

Remove "Generate Coins" option from GUI, and remove 4way SSE miner. Internal reference CPU miner remains available, but users are directed to external miners for best hash production.

这条变更有两层含义：

1. GUI 中的 "Generate Coins" 选项被移除；
2. 4 路 SSE 硬件加速 CPU 矿工被移除；内部保留了一个参考实现级别的 CPU 矿工（reference CPU miner），但官方明确引导用户去使用外部矿工以获得最佳哈希产量。

从产品层面看，这是 Bitcoin Core 明确"节点软件与挖矿软件解耦"的早期标志：客户端不再作为挖矿工具定位，挖矿交由专职的独立软件完成。这一结论可以从当前仓库找到直接佐证——今天的代码库中已不存在任何 CPU 矿工实现，而功能性测试数据目录 test/functional/data/README.md 明确写明测试区块是用外部 CPU 矿工（如 cpuminer 一类工具）生成的："mine a block using a CPU miner … The CPU miner is kept running as follows"。也就是说，"去内置化"的矿工策略从 0.3.22 一直延续至今。

2.5 IRC 引导通道扩容：#bitcoin00 至 #bitcoin99

IRC is overflowing. Client now bootstraps to channels #bitcoin00 - #bitcoin99

当时节点间的对等发现依赖 IRC 机器人频道（#bitcoin-sirc，通过服务器地址列表引导新节点），由于节点数量爆发，单一频道已经溢出。0.3.22 的对策是把引导频道扩展为 #bitcoin00 到 #bitcoin99 共 100 个分片频道，每个节点进入其中一个分片获取种子地址。

这是一种典型的"水平分片扩容"：不做中心化的大规模列表分发，而是把同一类轻量引导负载分散到 N 个同质频道上。从当前仓库结构看，今天的节点发现已经不再依赖 IRC：固定种子节点（fixed seed nodes）列表以二进制形式直接编译进了 src/chainparamsseeds.h，文件头注释标明其由 contrib/seeds/generate-seeds.py 自动生成（AUTOGENERATED by contrib/seeds/generate-seeds.py），而 contrib/seeds/ 目录下的 makeseeds.py、generate-seeds.py 以及 nodes_main.txt、nodes_test.txt、nodes_testnet4.txt、nodes_signet.txt 等文件构成了完整的种子节点生成工具链。从源码结构看，2011 年"靠 IRC 分片撑住引导流量"的临时方案，最终被"编译期固定种子 + DNS 种子 + 对等发现"的多层结构所取代。

2.6 -addnode / -connect 支持 DNS 名称（配合 -dns 开关）

DNS names now may be used with -addnode, -connect (requires -dns to enable)

这条变更让命令行指定的节点不再局限于 IP 地址：-addnode 与 -connect 开始接受 DNS 域名，但必须以 -dns 启动参数显式开启。

这个特性在当前仓库中依然存活，且定义清晰，见 src/init.cpp：

argsman.AddArg("-dns", strprintf("Allow DNS lookups for -addnode, -seednode and -connect (default: %u)", DEFAULT_NAME_LOOKUP), ArgsManager::ALLOW_ANY, OptionsCategory::CONNECTION);

注意两点演变：一是帮助文本显示如今的支持范围已扩展为 -addnode、-seednode 和 -connect 三个参数（当年文档只列了前两者对应的场景）；二是该值被读入 src/init.cpp 的 fNameLookup 全局开关（fNameLookup = args.GetBoolArg("-dns", DEFAULT_NAME_LOOKUP);），而 -addnode 的解析处理仍在 src/init.cpp 的启动流程中逐个遍历完成。可以推断，这个在 0.3.22 引入的开关因使用成本低、场景真实（私有节点、多 IP 主机），被一直保留到今天的代码库中。

三、RPC 变更：三个钱包接口的行为修正与新增

原文档的 RPC changes 部分共三条，均是针对钱包账本与交易构造的实用修正：

3.1 listtransactions 增加 from 参数，支持范围查询

'listtransactions' adds 'from' param, for range queries

0.3.22 之前 listtransactions 只能整表拉取，新增 from 参数后支持从指定位置开始的范围查询，对账本较大时的分页遍历是直接的工程改进。

对照当前仓库，src/rpc/client.cpp 中该 RPC 的参数表已演变为：

{ "listtransactions", 0, "label", ParamFormat::STRING },
{ "listtransactions", 1, "count" },
{ "listtransactions", 2, "skip" },
{ "listtransactions", 3, "include_watchonly" },

即当年的 from 语义已被 count + skip 这一对更明确的"取多少条 / 跳过多少条"参数取代，并新增 label 过滤与 include_watchonly 标志，实际实现位于 src/wallet/rpc/transactions.cpp。参数命名从"起始偏移"改为"数量 + 跳过"，是后来钱包 RPC 面向多账户场景重新设计账本模型的结果。

3.2 move 允许账户余额为负

'move' may take account balances negative

在多账户（account）模型下，move 是账户间转移资产的 RPC。此前的限制要求源账户余额足够，0.3.22 放宽为允许余额被扣成负数，这在当时被用于"先记账后归集"的记账习惯（把尚未到账的预期收入先记入目标账户）。

值得注意的是，这一行为所依附的整套账户（account）API 生命周期并不长：从 doc/release-notes/release-notes-0.18.0.md 可以看到，The 'account' API is removed after being deprecated in v0.17——账户 API 在 0.17 弃用、0.18 彻底移除，move 随之退出历史舞台。换言之，0.3.22 中"允许负余额"这一补丁，是围绕一个后来被整体淘汰的模型做的行为修正，阅读它时应注意其历史语境。

3.3 新增 settxfee：手动设定交易手续费

'settxfee' added, to manually set TX fee

配合 2.1 节的手续费调度变更，settxfee 给出了运行时手动设定每笔交易手续费的 RPC 手段，与"钱包默认 0.01 BTC/kb"的自动费率形成互补：默认费率不变，但用户可按需覆盖。

从当前仓库的发布说明可以完整还原这条特性链的后续命运：

• doc/release-notes/release-notes-0.21.0.md 记录了其边界收紧："The settxfee RPC will fail if the fee was set higher than the -maxtxfee"（超过 -maxtxfee 上限时直接报错）；
• doc/release-notes/release-notes-30.0.md 声明 -paytxfee 启动参数与 settxfee RPC 弃用；
• doc/release-notes/release-notes-31.0.md 宣布二者在删除周期后正式移除。

从源码结构看，今天的费率决定权已交给钱包端的动态费率估算（对应 src/policy/fees/block_policy_estimator.h 所在的 fee 策略层），"让用户自己敲定一个静态费率"的 settxfee 因此失去了存在必要。

四、从 0.3.22 看早期发布说明的阅读方法

0.3.22 的发布说明虽然只有十余行，但每一条变更都对应一个可验证的机制演进，适合作为阅读早期 Bitcoin Core 历史文档的样本：

1. 手续费相关条目要区分"网络侧接受/中继规则"与"钱包侧发送费率"，0.3.22 正是两者分版本调整的典型案例（0.0005 BTC 中继 vs 0.01 BTC/kb 发送）；
2. 网络引导类条目要放在节点增长曲线下理解，IRC 分片（#bitcoin00–#bitcoin99）是过渡方案，其后继形态是编译进 src/chainparamsseeds.h 的固定种子列表与 contrib/seeds/ 工具链；
3. RPC 条目要追踪到参数的后续演化，from 变为 count/skip（src/rpc/client.cpp），move 随账户 API 在 0.18 移除，settxfee 在 30.0 弃用、31.0 删除；
4. 移除类条目往往代表产品定位决策，移除内置矿工后，"节点只做共识与中继，挖矿交给外部工具"的分工在今天的 test/functional/data/README.md 中依然可见。

以上所有结论均可在当前仓库中按文中列出的相对路径复核：原文档为 doc/release-notes/release-notes-0.3.22.md，关键对照源码为 src/init.cpp、src/rpc/client.cpp、src/wallet/rpc/transactions.cpp、src/policy/policy.h 与 src/chainparamsseeds.h。