Bitcoin Core 0.14.1 发布说明解析：UTXO 内存计量修正、getblocktemplate 挖矿兼容性与 RPC 命名参数变更

本文基于仓库中的 release-notes-0.14.1.md 展开，系统讲解 Bitcoin Core 0.14.1 这个维护版本引入的四类关键变更：UTXO 缓存内存计量修正与 -dbcache 默认值调整、getblocktemplate 对非 SegWit 矿机的兼容性修复、两处破坏性 RPC 命名参数重命名，以及 P2P、构建系统等方面的修复清单。读完本篇，你将理解为什么 0.14.1 被发布为一次“紧急”的后续修复版本，如何评估 -dbcache 对低内存节点的影响，以及下游客户端在升级 0.14.0 时应注意哪些接口兼容性问题，并可结合当前仓库源码验证这些机制的后续演进。

版本定位与发布背景

0.14.1 是 Bitcoin Core 0.14.0 之后发布的一个次版本（minor）修复版本。原文档开篇即说明，该版本包含各类 bug 修复、性能改进以及更新的翻译，官方发布包托管在 bitcoin.org 的下载目录（https://bitcoin.org/bin/bitcoin-core-0.14.1/，该链接为原文档中的外部地址，仅作出处说明）。

从变更内容可以推断，0.14.0 引入了 0.14.1 需要立即修补的几类问题：

1. 0.14.0 新引入的“命名参数（named arguments）”RPC 功能暴露出两处参数命名不严谨的问题，需要对下游客户端做兼容提示；
2. SegWit 网络激活后的挖矿兼容性问题：此前版本中 getblocktemplate 在网络激活 SegWit 后实际要求下游矿机支持 SegWit，这会直接把非 SegWit 矿机排除在网络出块之外，属于必须修复的激活安全性问题；
3. UTXO 缓存内存计量不准导致 -dbcache 限制在缓存刷盘（flush）峰值时被突破，实际内存占用约为配置值的一倍。

原文档同时给出了兼容性范围：Bitcoin Core 在 Linux 内核、macOS 10.8+、Windows Vista 及更高版本上经过充分测试；对 Windows XP 虽不阻止安装运行，但微软已于 2014 年 4 月 8 日终止支持，存在已知不稳定性，官方不接收 XP 相关 issue；其他类 Unix 系统应可运行，但不频繁测试。

RPC 变更：两处命名参数重命名（对 0.14.0 的破坏性变更）

原文档的 “Notable changes / RPC changes” 一节明确列出两处变更：

• createrawtransaction 的第一个位置参数名从 transactions 重命名为 inputs；
• disconnectnode 的参数名从 node 重命名为 address。

原文档特别强调：这些接口变更与 0.14.0 不兼容——当调用方使用 0.14.0 新引入的命名参数功能时，使用旧参数名的客户端软件必须更新。位置参数不受影响，只有命名参数调用会受影响。

从当前仓库源码可以验证这一演进：RPC 客户端参数名映射表 src/rpc/client.cpp 中，createrawtransaction 的第一个位置参数名至今仍是 inputs：

{ "createrawtransaction", 0, "inputs" },
{ "createrawtransaction", 1, "outputs" },

disconnectnode 的参数映射为 nodeid（见 src/rpc/client.cpp 中 { "disconnectnode", 1, "nodeid" }），说明该参数在 0.14.1 的 address 之后又经历过一次重命名。这提醒下游集成方：在依赖命名参数编写 RPC 封装时，应随目标节点版本核对参数名映射表，而不是依赖某一代版本的命名。对仍面向 0.14.1 节点写客户端的场景，正确的命名参数调用形如：

createrawtransaction(inputs, outputs, locktime, replaceable)
disconnectnode(address)

若按 0.14.0 写法使用 transactions / node，则会因参数名不匹配而报错。

挖矿：getblocktemplate 在 SegWit 激活后不再排除非 SegWit 矿机

这是 0.14.1 最重要的行为变更。原文档 “Mining” 一节说明了两点：

1. 此前版本的行为：在 SegWit 于网络激活之后，getblocktemplate 要求下游客户端/矿机具备 SegWit 支持，否则拿到的块模板无法通过验证。这意味着一旦激活发生，不支持 SegWit 的矿机将立即丧失出块能力，等效于强制淘汰。
2. 0.14.1 的修复：getblocktemplate 现在对非 SegWit 客户端也能正常工作——当客户端未声明 SegWit 支持时，返回的块模板会剔除全部 SegWit 交易，使非 SegWit 矿机在激活后仍能继续正确出块。
3. version-bit 信号建议的改变：此前版本因上述局限，getblocktemplate 建议非 SegWit 客户端不要为 SegWit 的 version-bit 发信号；0.14.1 之后这一限制不再存在，getblocktemplate 现在始终建议所有矿机都发出 SegWit 的 version-bit 信号。原文档解释了安全性依据：BIP9 激活机制中，安全激活的必备条件是节点具备“强制执行该规则”的能力，而不是必须实际生产包含该规则交易的块，因此信号而不生产是安全的。

这一变更与 BIP9 的激活安全准则直接相关，可以推断其发布动机：在 SegWit 临近激活的窗口期内，如果网络中部分矿机因使用旧版 getblocktemplate 而被变相强制升级，会造成算力被无谓压制，甚至引发对激活过程公正性的质疑。0.14.1 将“能强制规则”与“能生产 SegWit 块”解耦，保证任何矿机只要运行了支持规则验证的节点就能参与信号与出块。

当前仓库中 getblocktemplate 的实现在 src/rpc/mining.cpp，其帮助文本保留了 BIP9 的官方示例调用，体现了同一接口演进至今的形态：

getblocktemplate '{"rules": ["segwit"]}'

即客户端通过 rules 字段声明它支持的额外规则（SegWit），节点据此决定是否在模板中包含相应交易——这正是 0.14.1 所确立的“按客户端声明裁剪模板”思路的直接延续。

UTXO 内存计量修正与 -dbcache 默认值调整为 450MiB

0.14.1 的第三个重点变更是 UTXO 缓存（UTXO cache）内存计量的准确性修正，原文档 “UTXO memory accounting” 一节给出两个关键事实：

1. 计量修正：此前版本在缓存刷盘（flush to disk）导致内存使用达到峰值时，配置的 -dbcache 上限实际会被突破。旧版计量逻辑估计只覆盖了峰值实际用量的一半左右，因此 0.14.1 改进了计量方式，使配置的 -dbcache 限制在内存峰值时也能被遵守。
2. 默认值变更：本版本将 -dbcache 默认值调整为 450 MiB。

原文档据此给出两条运维建议：

• 当前已将 -dbcache 设为较高值（目的是让 UTXO 尽量完整驻留内存以获得最佳性能）的用户，升级后应考虑调高该值，才能达到与之前版本相同的缓存效果——因为旧版本“虚高”的计量使得同样的配置值实际能容纳约一倍的缓存量；
• 低内存系统（1 GiB 或更少内存）的用户应考虑调低该参数，以避免触发 swap 抖动（thrashing）。

原文档还指向了一个外部 gist 上的“低内存系统运行 Bitcoin Core 的附加信息”（https://gist.github.com/laanwj/efe29c7661ce9b6620a7，外部地址仅作出处说明）。值得注意的是，仓库中现已将该指南沉淀为正式文档 doc/reduce-memory.md，可作为本篇主题的权威后续参考，其要点与 0.14.1 的变更直接呼应：

• -dbcache=<n>：UTXO 数据库缓存大小（MiB），最小值为 4；文档说明其默认值为 1024（当检测到的系统内存小于 4096 MiB 时为 450），并且未使用的 mempool 分配内存会与 UTXO 缓存共享（-maxmempool 默认 300 MB），因此降内存时通常应优先限制 mempool；
• 当检测到 -dbcache 相对系统内存过大时，节点会在启动时给出警告——这一启动警告机制在当前源码 src/node/caches.cpp 的 LogOversizedDbCache 中仍然保留，提示文案为 “A %zu MiB dbcache may be too large for a system memory of only %zu MiB.”；
• 其他降内存手段还包括调低 -maxconnections、使用 -blocksonly（将默认内存占用降到约 5MB 并使节点不再接收/中继交易）、调整 -par 等线程数，以及在 Linux 上通过 MALLOC_ARENA_MAX=1 缓解 glibc 多 arena 造成的内存放大。

从当前仓库源码看，450 MiB 这个默认值在 0.14.1 确立后一直保留为内核层的基准值：src/kernel/caches.h 定义

inline constexpr uint64_t DEFAULT_KERNEL_CACHE{450_MiB};

而 src/node/caches.cpp 中的 GetDefaultDBCache 在此之上做了动态提升：64 位系统且检测到总内存不小于 4 GiB（HIGH_DEFAULT_DBCACHE_MIN_TOTAL_RAM）时，默认值提升到 1 GiB（HIGH_DEFAULT_DBCACHE）；用户显式设置 -dbcache 时则由 CalculateDbCacheBytes 解析并夹在最小值与最大值之间。也就是说，0.14.1 把 450 MiB 作为“保守基准”，后续版本再按机器条件向上调整——理解了 0.14.1 的计量修正，才能理解为什么这个基准值可以放心地作为低内存场景的默认。

0.14.1 完整变更清单（Change Log）

以下按原文档的分类完整继承 0.14.1 的变更日志（包含 PR 号与合并提交的短 hash），用于定位代码变更与对应讨论：

RPC and other APIs

• #10084 142fbb2 Rename first named arg of createrawtransaction (MarcoFalke)
• #10139 f15268d Remove auth cookie on shutdown (practicalswift)
• #10146 2fea10a Better error handling for submitblock (rawodb, gmaxwell)
• #10144 d947afc Prioritisetransaction wasn't always updating ancestor fee (sdaftuar)
• #10204 3c79602 Rename disconnectnode argument (jnewbery)

其中 Remove auth cookie on shutdown 值得注意：RPC 认证 cookie（.cookie 文件）在节点关闭时被删除，消除了关机后残留凭据被本地其他用户读取的风险。

Block and transaction handling

• #10126 0b5e162 Compensate for memory peak at flush time (sipa)
• #9912 fc3d7db Optimize GetWitnessHash() for non-segwit transactions (sdaftuar)
• #10133 ab864d3 Clean up calculations of pcoinsTip memory usage (morcos)

第一条即上文“UTXO 内存计量”变更对应的实现：在刷盘时补偿峰值内存，使 -dbcache 上限得到遵守。

P2P protocol and network code

• #9953/#10013 d2548a4 Fix shutdown hang with >= 8 -addnodes set (TheBlueMatt)
• #10176 30fa231 net: gracefully handle NodeId wrapping (theuni)

-addnode 达到 8 个及以上时关闭挂死的修复，对依赖手动添加节点（如 I2P/Tor 隐藏服务场景、私有节点）的用户是重要的可用性修复；NodeId wrapping 修复则处理了节点 ID 在大量节点连接/断开后回绕（wrap-around）时的边界情况，从当前仓库的网络代码结构看，NodeId 的发放与复用逻辑至今仍以该修复为基础。

Build system

• #9973 e9911d1 → 原文档写作 e9611d1 depends: fix zlib build on osx (theuni)

修复 depends 构建系统在 macOS 上编译 zlib 的问题，影响使用官方 depends 工具链交叉/本地构建 macOS 二进制的场景。

GUI

• #10060 ddc2dd1 Ensure an item exists on the rpcconsole stack before adding (achow101)

修复 GUI RPC 控制台在尚无条目时追加输出可能越界的防御性问题。

Mining

• #9955/#10006 569596c Don't require segwit in getblocktemplate for segwit signalling or mining (sdaftuar)
• #9959/#10127 b5c3440 Prevent slowdown in CreateNewBlock on large mempools (sdaftuar)

第一条即上文详述的 SegWit 激活兼容性修复；第二条修复了内存池规模较大时 CreateNewBlock 组装区块模板变慢的问题，属于挖矿路径上的性能改进，与 0.14.1 “bugfixes and performance improvements” 的定位一致。

Tests and QA

• #10157 55f641c Fix the mempool_packages.py test (sdaftuar)

修复功能测试 mempool_packages.py（对应仓库 test/functional/ 目录下的测试套件），保证包（package）中继相关回归测试可用。

Miscellaneous

• #10037 4d8e660 Trivial: Fix typo in help getrawtransaction RPC (keystrike)
• #10120 e4c9a90 util: Work around (virtual) memory exhaustion on 32-bit w/ glibc (laanwj)
• #10130 ecc5232 bitcoin-tx input verification (awemany, jnewbery)

其中 32 位 glibc 系统虚拟内存耗尽的 workaround 对仍在 32 位环境（部分嵌入式路由、树莓派一代等）运行 Bitcoin Core 的用户是必要的稳定性修复；bitcoin-tx 的输入校验修复则强化了命令行离线交易工具的健壮性。

贡献者

原文档 Credits 一节列出直接贡献者：Alex Morcos、Andrew Chow、Awemany、Cory Fields、Gregory Maxwell、James Evans、John Newbery、MarcoFalke、Matt Corallo、Pieter Wuille、practicalswift、rawodb、Suhas Daftuar、Wladimir J. van der Laan，以及通过 Transifex 参与翻译的各方。

面向升级者的行动清单

综合原文档与当前仓库源码证据，从 0.14.0 升级到 0.14.1（或在当前版本中沿用这些机制）时，建议核对以下事项：

1. RPC 封装审计：检索代码中所有以命名参数方式调用 createrawtransaction（使用 transactions 键）和 disconnectnode（使用 node 键）的位置并更新参数名；参考当前映射表 src/rpc/client.cpp 核对目标版本参数名。
2. 矿机/节点协同检查：确认矿机控制端支持 BIP9 的 rules 信号语义；非 SegWit 矿机在激活后应依赖 0.14.1+ 的模板裁剪逻辑继续出块，同时按节点建议发出 SegWit version-bit 信号。
3. 内存配置复核：按 doc/reduce-memory.md 的思路评估 -dbcache——高内存机器（≥4 GiB）在当前版本默认 1 GiB、其余 450 MiB（见 src/node/caches.cpp 与 src/kernel/caches.h）；低内存节点应保持低值并关注启动时的 dbcache 过大警告；依赖旧版“虚高”缓存效果的高配置用户应显式上调 -dbcache。
4. 运维场景回归：使用 ≥8 个 -addnode 的部署在升级后验证节点可正常关闭；32 位 glibc 环境验证不再出现虚拟内存耗尽。

本篇所有 0.14.1 的行为事实均以 doc/release-notes/release-notes-0.14.1.md 为准，源码级佐证（参数名映射、缓存默认值、getblocktemplate 帮助文本、dbcache 过大警告）则来自当前仓库中对应文件的实际内容；文中对后续版本演进的部分均基于当前仓库代码结构，属于“从源码结构看”的事实陈述。