Bitcoin Core 0.12.0 版本发布说明详解：libsecp256k1 验签、内存池限制、BIP 125 RBF 与 RPC Cookie 认证的源码级剖析

Bitcoin Core 0.12.0 版本发布说明详解：libsecp256k1 验签、内存池限制、BIP 125 RBF 与 RPC Cookie 认证的源码级剖析

【免费下载链接】bitcoinBitcoin Core integration/staging tree项目地址: https://gitcode.com/GitHub_Trending/bi/bitcoin

本文为 Bitcoin Core 0.12.0 版本发布说明（doc/release-notes/release-notes-0.12.0.md）的完整技术解读。0.12.0 是比特币客户端历史上影响深远的重大版本：验签引擎切换为 libsecp256k1、内存池引入硬性上限与淘汰机制、支持 BIP 125 可选 RBF 交易替换、RPC 引入随机 Cookie 认证、剪枝模式支持钱包等特性均在此版本落地。读完后，你将理解每一项特性解决的节点运维痛点、对应的命令行参数与默认值，并能结合当前仓库源码定位这些机制的后续演进位置。

版本定位与升级、降级注意事项

0.12.0 是一个新的大版本（major release），带来新特性与多项改进。发布说明中的下载与问题反馈地址为官方二进制目录与 issue tracker（此处不再列出外部链接，可自行检索获取）。

如何升级

如果你正在运行旧版本，先将其关闭；老版本完全关闭可能需要几分钟，等它彻底退出后，在 Windows 上运行安装程序，在 macOS 上覆盖/Applications/Bitcoin-Qt，在 Linux 上覆盖bitcoind/bitcoin-qt即可。

降级警告一：降回 0.10.0 之前

由于 0.10.0 及以后采用 headers-first 同步与并行块下载，块文件和数据库不再向后兼容0.10 之前的版本：

• 块文件在磁盘上乱序存储（按接收顺序而非高度顺序），某些工具或其他软件无法处理，旧版本的重建索引（reindex）也因此失效；
• 块索引数据库（block index）会保存磁盘上没有对应块文件的头部（header），旧版本无法理解这种状态。

若要平滑降级，必须对整个数据目录做完整备份；否则降级后节点需要从头重新同步（或重新导入 bootstrap.dat）。完全同步的 0.10 节点数据在旧版本上“原样可用”的可能性存在，但官方不支持，且旧版本一旦尝试重索引就可能损坏数据。钱包的前向/后向兼容性不受此影响。

降级警告二：降回 0.12.0 之前

0.12.0 起，每次全新同步或 reindex 都会对链状态（chainstate，即 UTXO 数据库）进行混淆（obfuscate）存储，因此 chainstate 与 0.12 之前的版本不兼容。如果你在使用 0.12.0 或更高版本完成过 reindex 之后想降级，在首次启动 0.11 或更早版本时需要重新 reindex。

链状态混淆的源码印证

从当前仓库源码结构看，chainstate 混淆机制至今仍是存储层的核心特性：UTXO 键的混淆实现在 src/dbwrapper.cpp 与 src/coins.cpp 中，其设计目的就是防止数据库文件中的键可被离线枚举，从而保护在线节点上的用户隐私。

验签引擎：切换至 libsecp256k1

交易中的 ECDSA 签名验证从此使用 libsecp256k1 库，取代 OpenSSL。这是 0.12.0 最重要的性能改进之一：

• 原始签名验证速度因平台而异，x86_64 上提升超过 5 倍；
• 实际效果：完整重索引（reindex）与新块验证的耗时不到之前的一半；
• 副作用：libconsensus（共识验证动态库）从此不再依赖 OpenSSL。

在当前的仓库中，libsecp256k1 以子模块形式内置于 src/secp256k1 目录，包含独立的 CMake 构建体系、Sage 数学验证脚本与完整的单元测试；构建入口见 cmake/secp256k1.cmake。从源码结构看，验证侧仍延续 0.12.0 确立的架构：共识关键路径上的签名校验完全走 secp256k1 的预编译实现，OpenSSL 不再出现在验证代码路径中。

降低上传流量：-maxuploadtarget

全节点的主要出站流量来自向处于初始块下载（IBD）状态的节点提供历史块。0.12.0 新增-maxuploadtarget参数来控制该流量：

• 它不是硬性限制，而是用来最小化出站流量的阈值。当 24 小时累计上传量接近目标值时，节点通过**停止提供历史块（一周前的块）**来削减上传量；
• 此外，请求 filtered block（Bloom 过滤器压缩块）的 SPV 对等节点会被断开连接；
• 单位是MiB/天，默认关闭（-maxuploadtarget=0）；
• 官方推荐的最小设置是144 × MAX_BLOCK_SIZE（当时为 144 MB/天），即大约保证每天能传完一个正常出块速率下的全部新块；
• 白名单（whitelist）节点永远不会被断开，但其流量会计入目标统计。

当前仓库中该参数的定义可以直接查证，src/init.cpp 中的帮助文本为：

-maxuploadtarget=<n> Tries to keep outbound traffic under the given target per 24h. Limit does not apply to peers with 'download' permission or blocks created within past week. 0 = no limit (default: 0). ...

其中统计周期（1 天）与默认值定义在 src/net.cpp 与 src/net.h，而对等节点的“download 权限”（豁免该限制、IBD 期间允许 getheaders）则在 src/net_permissions.cpp 中定义。更完整的低流量节点运维建议见 doc/reduce-traffic.md。

BIP 130：直接头部广播（Direct Headers Announcement）

在兼容的对等节点之间，0.12.0 启用 BIP 130 头部直传：新块直接广播其完整 header，而不再是只广播哈希。发生重组（reorg）时，会发送所有新头而不仅是新的链尖（tip）。这常常能在下载实际块数据前省掉一个额外的往返（roundtrip），缩短新区块的传播延迟。

该机制由变更日志中 “#7129 Direct headers announcement (rebase of #6494, Pieter Wuille)” 引入，对应功能测试在当前仓库为 test/functional/p2p_sendheaders.py（变更日志中提到的sendheaders.py测试用例）。

内存池限制：-maxmempool与最低费率淘汰

背景：无上限内存池的 DoS 风险

0.12 之前，内存池（mempool）大小仅由“交易费率是否达到节点最低中继费率”来隐性约束，没有硬性上限。攻击者可以发送大量仅略高于默认最低中继费率的交易，用相对低廉的内存成本打崩 RAM 较小的节点。此前版本的临时缓解措施是调高最低中继费率。

0.12.0 的机制

0.12.0 为内存池引入严格的最大尺寸：

• 默认300 MB，可通过-maxmempool配置；
• 当一笔新交易会使内存池超过上限时，节点会淘汰总费率（feerate，按“包/连同内存池中的后代交易”计）最低的那笔交易；
• 同时，节点的有效最低中继费率（effective minimum relay feerate）被抬高到“被淘汰交易的费率 + 初始最低中继费率”，从而阻止同样低费率的后续交易进入；
• 初始最低中继费率设为1000 satoshi/kB。

未确认交易链的新策略限制

0.12.0 同时引入针对内存池中未确认交易链（unconfirmed transaction chains）长度与总体积的默认策略限制：一般将链长限制在25 笔交易、总体积 101 KB。这些限制可用命令行参数覆盖，详见扩展帮助（--help -help-debug）。

从当前仓库源码看，这一机制演进为更细粒度的多维权重控制：src/node/mempool_args.cpp 中解析-limitancestorcount、-limitancestor-size、-limitclustercount、-limitclustersize等参数并写入kernel::MemPoolLimits（定义在 src/kernel/mempool_limits.h），而淘汰与有效最低费率的逻辑仍保留在 src/txmempool.cpp 中。0.12 的“25 笔 / 101 KB”链限制正是后来-limitancestorcount/-limitancestor-size的雏形。

BIP 125：可选 RBF 交易替换

0.12.0 允许在内存池中替换交易（Replace-by-Fee），规则如下：

• 只有当被替换交易的任一输入的nSequence小于0xffffffff - 1（即0xfffffffe）时，它才被视为“可选 RBF”并允许被替换；
• 替换交易必须支付足够高的费率，具体规则遵循 BIP 125；
• 可以用新参数-mempoolreplacement=0关闭替换行为。此时，符合 BIP 125 信号的交易仍可进入内存池，但后续替换请求会被拒绝。该参数面向希望沿用旧版交易选择行为的矿工；
• 注意：变更日志显示该参数最初名为-permitrbf（#7386），后更名为-mempoolreplacement并提供最小字符串列表前向兼容（#7440）。

对钱包用户的告诫

-mempoolreplacement=0并不推荐给想“避免收到可替换未确认交易”的钱包用户，因为它并不阻止符合 BIP 125 的替换交易被接受（它只阻止后续替换；而实现了 BIP 125 的其他节点仍会中继并可能挖掘这些交易）。钱包用户应改用增强后的 RPC：gettransaction与listtransactions的输出新增了bip125-replaceable字段，标明某笔交易是否可在 BIP 125 下被替换。

另外要注意：0.12.0 的钱包尚不能创建BIP 125 可替换交易（创建端支持在后续版本才加入）。

RPC 安全：随机 Cookie 认证

0.12.0 之前，如果未配置-rpcpassword，bitcoind启动后会直接拒绝 RPC 访问，用户必须手工生成认证凭据。0.12.0 引入了随机 Cookie 文件认证：

• 未指定-rpcpassword时，守护进程在启动时生成一个内容为随机字节的 cookie 文件，退出时删除；
• 该文件内容即认证令牌，对它的读权限就决定了谁可以访问 RPC；
• 默认存放在数据目录，可用-rpccookiefile覆盖路径；
• 设计参考了 Tor 的 CookieAuthentication 机制；
• 最大价值：零手工配置即可安全地运行 bitcoind（本地进程凭文件读权限访问）。

在当前仓库中这一机制仍然完整存在，src/rpc/request.cpp 中的关键实现与发布说明完全对应：

static const std::string COOKIEAUTH_USER = "__cookie__"; static const char* const COOKIEAUTH_FILE = ".cookie";

GenerateAuthCookie()先写入临时文件再原子重命名为目标路径（避免半成品文件被读取），并通过fs::permissions设置受限权限；日志中会打印 “Generated RPC authentication cookie …” 与所用权限。配合该机制，仓库内 share/rpcauth/rpcauth.py 则用于需要静态用户名/密码时的 Basic Auth 凭据生成（0.12 变更日志 #7044 同时支持了多 RPC 用户）。

中继策略变化

OP_RETURN 输出放宽

此前，带数据的OP_RETURN输出只有在单一 pushdata时才被中继和挖矿。0.12.0 取消了这一限制：OP_RETURN之后允许任意组合的数据压栈与数值常量操作码（OP_1到OP_16）。同时，OP_RETURN输出大小限制改为作用于整个序列化后的 scriptPubKey，默认83 字节（旧的 80 字节默认值加上 3 字节开销：OP_RETURN本身、锁定指令与长度前缀）。

剪枝模式下的块中继与getblocks

• 以剪枝（pruned）模式运行的客户端现在会中继新区块（此前不做中继）；
• 响应getblocks消息时，只返回磁盘上存在且预计会在合理时间窗（1 小时）内保留的块的哈希，而非之前那样返回所有相关哈希。

优先级交易：中继与挖矿策略调整

Bitcoin Core 一直有一组基于**币值与账龄（coin value and age）**的启发式“优先级（priority）”计算，用于：中继未付最低费率的交易、以及按优先级为挖掘块排序交易。相关参数：

• -limitfreerelay=<r>：控制优先级中继的量，默认r=15kB/分钟；
• -blockprioritysize=<s>：控制为优先级交易保留的挖矿空间。

0.12.0 的关键变化：

1. 内存池达到上限后，抬升后的有效最低中继费率立即生效：即使某交易在优先级启发式下排名很高，只要它不满足新的有效最低费率，就不会被中继或挖入块中；
2. 基于优先级挖矿默认关闭（默认-blockprioritysize=0）。如需恢复旧行为，设置-blockprioritysize=<n>；旧默认是 50 kB，要近似保留旧策略可设-blockprioritysize=50000；
3. 由于计算简化（避免输入交易确认时重算金额），含未确认输入的交易其优先级数值低于旧版本；
4. 通过prioritisetransactionRPC 对外部已入池交易做优先级增排仍然有效；但注意，若优先级挖矿保持关闭，优先级增量（priority delta）会被忽略，只有费率指标起作用。

发布说明还指出：这一内部自动优先级处理在 0.13 中被考虑完全移除（事实上后续版本已移除该机制），链式未确认交易的更精确优先级计算是否恢复在当时未定——发布说明特别向社区征求方向性意见。

Tor 隐藏服务自动化

从 Tor 0.2.7.1 起，可以通过 Tor 控制套接字（control socket）API 以编程方式创建和销毁“临时（ephemeral）”隐藏服务。0.12.0 的 Bitcoin Core 利用了这一能力：

• 只要 Tor 正在运行且授权信息正确，Bitcoin Core 会自动创建并监听一个隐藏服务，无需任何手工配置；
• 当控制套接字可以成功打开时，节点还会自动通过 Tor 连接其他.onion节点，这有助于增加可用的.onion节点数量及其使用率；
• 默认在“节点正在监听且能连上 Tor”时启用；
• 相关配置项：-listenonion（是否监听隐藏服务）、-torcontrol（控制套接字地址）、-torpassword（控制套接字口令），调试信息用-debug=tor打开。

对应实现在 src/torcontrol.cpp 与 src/torcontrol.h，变更日志中的 “#6639 net: Automatically create hidden service, listen on Tor” 与 “#7090 Connect to Tor hidden services by default (when listening on Tor)” 即这两个方向的落地提交。

ZeroMQ 通知

0.12.0 的bitcoind支持（可选地）通过ZMQ PUB 套接字异步通知客户端新交易与新块的到达。该功能要求：

• 安装ZMQ C API 4.x库；
• 通过命令行或配置文件启用并配置主题（如tx、rawblock、hashblock等）。

完整操作细节见 doc/zmq.md，通知的 C++ 实现位于 src/zmq/，对应变更日志条目为 “#6103 Add ZeroMQ notifications (João Barbosa)”。这是后续构建外部索引、链上数据管道的基础设施。

钱包：交易费率体系重构

0.12.0 对钱包费率计算做了多处改进，形成一套完整的费率参数体系：

费率估算与回退逻辑的演进（如 “#7296 Add sane fallback for fee estimation”）可在变更日志的 Wallet 一节中追溯；当前仓库中估算代码位于 src/wallet/feerates.cpp 等文件。

钱包：负确认数与冲突检测

• 钱包现在对冲突交易报告负确认数，其绝对值表示冲突在链中的深度。例：交易 A 有 5 个确认且与钱包交易 B 花费同一输入，则 B 报告为-5个确认；若另一钱包交易 C 又花费 B 的输出，C 同样报告-5；
• 要检测与链上历史交易的冲突，可能需要一次性执行-rescan；
• 与旧版本不同，未确认但不冲突的交易永远不会得到负确认数；它们被视为可花费的前提是“来自自己（找零）且已被本地内存池接受”。listtransactions输出新增trusted字段，标明某笔未确认交易的输出是否被视为可花费。

变更日志中的 “#7105 Keep track of explicit wallet conflicts instead of using mempool (Pieter Wuille)” 是这一“显式冲突跟踪”机制的落地提交。

钱包：移除 Merkle 分支存储

此前每笔钱包交易都存储一条证明其位于某块中的 Merkle 分支，但多年来只被用于一个昂贵的健全性检查。0.12.0 起不再存储这些分支。注意兼容性方向：把 0.12 的钱包载入旧版本时，旧版本会自动 rescan 以避免检查失败。

钱包 + 剪枝模式

0.12.0 首次允许剪枝模式下的钱包使用，可将磁盘占用从约60 GB 降到约 2 GB。代价是：

• rescan 被禁用；
• importwallet、importaddress、importprivkey等 RPC 被禁用（变更日志中 “#6645 Enable wallet key imports without rescan in pruned mode” 使部分密钥导入在无 rescan 情况下可用）。

启用剪枝：

prune=<N>

写在命令行或bitcoin.conf中，N是分配给原始块与 undo 数据的 MiB 数：

• 0关闭剪枝；
• 大于 0 的最小值是550；
• 钱包在高N值下的安全性与低N值下相同；更高的值只是保证区块链发生超过约 2 天深度的重组时节点不会因此停摆（实践中极少发生）。发布说明还提到，未来版本中较高的值可能有助于全网络——存储的块可供其他节点下载。

剪枝的进一步背景可参阅 doc/release-notes/release-notes-0.11.0.md 中的块文件剪枝章节；-prune=<n>的当前定义见 src/init.cpp。

P2P 协议：NODE_BLOOM服务位（BIP 111）

0.12.0 在 P2P 协议代码中加入NODE_BLOOM服务位支持：

• BIP 111 定义了一个服务位，让对等节点可以显式声明自己支持 Bloom 过滤器（SPV 客户端使用）；
• 同时提升协议版本号，用于识别“没有新服务位却仍然允许对其连接做 Bloom 过滤”的旧节点；
• 本版本中该限制只对发送协议版本>= 70011的对等节点强制；计划在下一个大版本移除该豁免；
• 建议 SPV 客户端在对方报告版本新于 70011 时检查NODE_BLOOM服务位。

变更日志对应 “#6579 Add NODE_BLOOM service bit and bump protocol version (Matt Corallo)”，另有关联参数-enforcenodebloom（#7087）。

命令行选项解析行为变化

命令行选项现在严格按出现顺序解析：以前-X -noX会得到反直觉的结果——-X优先于-noX，X 最终被设为开。0.12.0 起最后出现的选项生效，与其他软件保持一致。对应变更日志 “#6284 Fix argument parsing oddity with -noX”。

RPC/REST 低层 API 变化

0.12.0 还有若干直接影响脚本集成代码的 API 变化：

1. 货币金额可以传字符串：例如sendtoaddress的金额可以传"0.0001"而不是0.0001。当 JSON 库对数字坚持使用有损浮点类型时这一点尤其重要（对货币金额是危险的）。配合变更日志 #6379，RPC 同时接受科学计数法。
2. asm属性显示签名哈希类型：每个 scriptSig 的asm属性现在会为每个带有有效已定义哈希类型的签名解码并显示该类型。受影响的接口（包含脚本签名汇编表示的输出）包括：
   • RPCgetrawtransaction
   • RPCdecoderawtransaction
   • RPCdecodescript
   • REST/rest/tx/（JSON 格式）
   • REST/rest/block/（包含扩展交易详情的 JSON 格式）
   • bitcoin-tx -json
3. OP_NOP2更名为OP_CHECKLOCKTIMEVERIFY（BIP 65 正式命名）。

例如，某交易输入的scriptSig.asm之前显示为：

304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c509001 400000 OP_NOP2

现在显示为：

304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c5090[ALL] 400000 OP_CHECKLOCKTIMEVERIFY

即签名尾部多了[ALL]哈希类型标注，OP_NOP2变为OP_CHECKLOCKTIMEVERIFY。注意：RPCdecodescript的输出本身没有变化，因为它专门处理 scriptPubKey 而非 scriptSig 脚本。

RPC SSL 支持移除与迁移方案

RPC 的 SSL 支持（原-rpcssl选项）已从客户端与服务端两侧移除，这是为彻底移除守护进程对 OpenSSL 的依赖所做的准备。继续尝试使用-rpcssl会得到错误：

Error: SSL mode for RPC (-rpcssl) is no longer supported.

对仍依赖该功能的使用者，发布说明给出两条灵活的迁移路径：

方案一：stunnel 隧道

用 stunnel 将任意 TCP 连接封装进 SSL。在 Ubuntu 上安装：

sudo apt-get install stunnel4

然后把 28332 端口的 SSL 连接到绑定在 localhost:18332 的 RPC 服务器：

stunnel -d 28332 -r 127.0.0.1:18332 -p stunnel.pem -P ''

也可以按 inetd 风格系统级部署。

方案二：HTTP 反向代理

搭一个 httpd 反向代理，还能顺带获得不同认证方式、负载均衡、在线压缩与缓存。Apache2 示例配置：

Listen 443 NameVirtualHost *:443 <VirtualHost *:443> SSLEngine On SSLCertificateFile /etc/apache2/ssl/server.crt SSLCertificateKeyFile /etc/apache2/ssl/server.key <Location /bitcoinrpc> ProxyPass http://127.0.0.1:8332/ ProxyPassReverse http://127.0.0.1:8332/ # optional enable digest auth # AuthType Digest # ... # optional bypass bitcoind rpc basic auth # RequestHeader set Authorization "Basic <hash>" # get the <hash> from the shell with: base64 <<< bitcoinrpc:<password> </Location> # Or, balance the load: # ProxyPass / balancer://balancer_cluster_name </VirtualHost>

挖矿代码优化与 P2P 其他变化

• 挖矿代码：0.12.0 的挖矿代码被显著优化，更快且更省内存。作为其中一部分，共识关键计算在交易被接受进内存池时即被缓存，挖矿代码依赖内存池的一致性来组装块；不过所有块在组装后仍然会接受完整的合法性测试（变更日志 “#6898 Rewrite CreateNewBlock (Alex Morcos)”）。
• 封禁列表持久化：被封禁对等节点的列表现在存储在磁盘上而不是内存中，重启bitcoind不再清空封禁列表；新 RPCclearbanned用于手动清空，setban用于手动封禁/解除封禁（变更日志 #6310、#6158）。

0.12.0 变更日志要点

发布说明附有完整变更日志（含 PR 编号、合并提交与作者，覆盖行为变化而非纯代码搬迁/重构/字符串更新）。按类别摘录关键条目：

RPC 与 REST

• 466f0ea全源码树从 json_spirit 迁移到 UniValue（#6121，Jonas Schnelli）
• fd5dfdarpc: 实现基于随机 Cookie 的认证（#6388）
• 240b30erpc: 接受字符串形式的货币金额（#6380）
• c52e8b3rpc: JSON 中接受科学计数法货币金额（#6379）
• 9aa9099基于 libevent 的 HTTP 服务器（#5677，Wladimir J. van der Laan）
• 0abfa8a新增 setban/listbanned RPC（#6158）
• 26f5b34getmempoolinfo 暴露 maxmempool 与有效最低费率（#6877）
• b2f2b85401 响应中增加 WWW-Authenticate 头（#7472）
• fd4bd50新增 abandontransaction RPC（#7312）
• e25b158RPC 标注哪些交易可被替换（#7222）

配置与命令行选项

• 66227939164引入-maxuploadtarget（#6622，Jonas Schnelli）
• 628410ac38e修复-noX参数解析的怪异行为（#6284）
• 7386da83ecd新增-permitrbf（后更名-mempoolreplacement，#7386/#7440）
• 6462c384800新增uacomment配置（BIP-0014 用户代理注释）
• 6993b632145新增-blocksonly选项（#6993）

块与交易处理

• 64107cdefb9内存池精确内存计量（#6410，Pieter Wuille）
• 6654b0ce450内存池包（package）跟踪（#6654，Suhas Daftuar）
• 66504fac576链状态混淆（#6650，James O'Beirne）
• 67223b20e23内存池限制：丢弃最廉价交易并抬高最低中继费率（#6722，Matt Corallo）
• 6566ff057f4BIP-113 内存池式中位时间戳（MTP）执行（#6566）
• 677138ed190降低交易链默认限制（#6771）
• 68710e93586基于 nSequence 的 Full-RBF 可选信号（#6871，Peter Todd）
• 7008eb77416优先级下限约束（#7008）

P2P 协议与网络

• 6498219b916用滚动 Bloom 过滤器跟踪近期被拒交易（#6498）
• 637469dc5b5连接槽耗尽 DoS 缓解（#6374，Patrick Strateman）
• 6148999c8be剪枝模式下中继块（#6148）
• 6639bd629d7自动创建隐藏服务并在 Tor 上监听（#6639）
• 71295d5ef3a直接头部广播（#7129）
• 7133f31955d用滚动 Bloom 过滤器替代 setInventoryKnown（#7133）
• 743986755bc新增whitelistforcerelay控制强制中继（#7439）

验证（Validation）

• 59278d9f0a6降低检查点（checkpoints）对共识的影响（#5927）
• 63512a1090dCHECKLOCKTIMEVERIFY（BIP65）软分叉（#6351，Peter Todd）
• 6954e54ebbf切换为基于 libsecp256k1 的 ECDSA 验证（#6954，Pieter Wuille）
• 650861457c2Merkle 根/分支算法改为恒定空间（#6508）

钱包

• 608891389e5fundrawtransaction（#6088，Matt Corallo）
• 65505b77244钱包不再存储 Merkle 分支（#6550）
• 710530c2d8c显式跟踪钱包冲突而不再依赖内存池（#7105）
• 7296a36d79b费率估算的合理回退（#7296）

完整列表以仓库中的 doc/release-notes/release-notes-0.12.0.md 为准，其中还包含构建系统（gitian、depends、Qt4/Qt5 选择）、GUI（节点封禁 UI、debug 窗口等）、测试与 QA（p2p-fullblocktest、mempool_limit 测试、lcov 覆盖率等）及杂项的全部条目。

总结

Bitcoin Core 0.12.0 的发布说明清晰地勾勒出该版本的主线：性能（libsecp256k1 验签、挖矿代码缓存）、抗 DoS（内存池硬上限与费率淘汰、未确认链限制、连接槽耗尽缓解）、运维友好（Cookie 认证零配置 RPC、上传流量上限、剪枝 + 钱包、Tor 隐藏服务自动化）以及协议演进（BIP 130 头部直传、BIP 125 RBF、NODE_BLOOM、BIP 65 CLTV 软分叉、BIP 113 MTP）。发布说明中的每一类参数（-maxuploadtarget、-maxmempool、-mempoolreplacement、-rpccookiefile、-prune、-torcontrol、-paytxfee/-txconfirmtarget/-fallbackfee等）都给出了默认值与推荐取值，并在当前仓库的 src/init.cpp、src/rpc/request.cpp、src/node/mempool_args.cpp、src/torcontrol.cpp、doc/zmq.md、doc/reduce-traffic.md 等位置可以找到对应的（持续演进的）实现与文档，可据此将历史发布说明与现行代码一一对照。

【免费下载链接】bitcoinBitcoin Core integration/staging tree项目地址: https://gitcode.com/GitHub_Trending/bi/bitcoin