比特币专题

六个月一个里程碑：比特币核心的版本节奏和哪些升级真正重要

核心项目官方承诺大约六个月一个主版本，维护版本只修 bug、不加功能，但共识规则变化例外。本文按官方生命周期与发布流程文档，拆解版本号的解耦设计，以及一次发布背后那些与钱包和节点用户有关的例行维护动作。

节点选链看最重不是最长：累计工作量怎么决定哪条是正史

比特币节点在分叉之间做选择时比较的不是区块个数，而是累计工作量。本文从节点源码里的选链函数语义出发，解释工作量的构成、它和"最长链"说法的偏差，以及重组发生时未确认交易和余额会发生什么。

RPC 也会排队和超时：线程数、工作队列与长任务的正确等法

比特币核心的 RPC 是一个带线程池和工作队列的小型 HTTP 服务器：默认 16 个线程、64 层队列、30 秒服务端超时。扫描钱包、导入描述符这类长任务会怎样挤占队列、返回 503 或提前断开，本文按源码默认值给出排障与调度纪律。

链级流量账本：getchaintxstats 的窗口字段和快照同步下的盲区

想算比特币最近一个月平均每笔交易花多少空间、链上一共多少笔交易，getchaintxstats 是官方统计入口。本文按 RPC 文档逐项读它的可选窗口与各字段返回条件，重点讲用 assumeutxo 快照同步时哪个字段会缺失。

把节点的世界锁进几个对端：-connect 与 -addnode 的语义边界

想让比特币节点只连指定的机器，有 -connect 配置项和 addnode 命令两套机制。本文按节点帮助文本与源码注释逐项对比：谁关闭自动发现、谁有独立限额、排障时怎么用，以及长期只连少数对端在隐私和日蚀风险上的代价。

自动生成的隐藏入口：listenonion 怎么让节点无需公网地址就能被找到

装了 Tor 的比特币节点默认会自动创建一个 onion 服务，不需要公网 IP 和端口映射。本文拆解 -listenonion 的默认行为、它和 -listen 开关的冲突规则，以及 bind 地址加 onion 标记这条手工路线的差别。

重发交易为什么会暴露自己：sendrawtransaction 的两道闸门

离线签名、手动补播场景最后一步常是 sendrawtransaction。官方文档写明了两个要点：它会把交易无条件发给所有对端、重发会泄露交易起源；同时带默认 0.10 BTC/kvB 的费率上限。本文拆解这两个属性的成因与规避流程。

avoid_reuse开启后余额为何变了？

Bitcoin Core的avoid_reuse会跟踪地址重用相关的clean与dirty coins，并让getbalances和listunspent出现used、reused字段。本文给出开启前后验收方法。

include_empty如何补全收款地址表？

listreceivedbyaddress默认不返回零收款地址，开启include_empty后才适合做地址全量清点。本文解释minconf、最近确认数、累计金额和UTXO差异。

getreceivedbyaddress为何不是余额？

getreceivedbyaddress返回钱包内某地址达到确认门槛的累计收款，即使币后来已花出也不会回退。本文用水表与水库模型对照当前UTXO和钱包余额。