除了协议自动拉黑异常对端，比特币核心还允许运维手动封禁 IP 或网段：setban 加时长、listbanned 查现状、clearbanned 一键清空，规则持久化在数据目录的 banlist.dat。本文讲清手动封禁与自动封禁的分野与滥用风险。

硬盘上的链数据没丢、只是数据库逻辑坏了时，比特币核心提供两档重建：-reindex 连块索引一起推倒，-reindex-chainstate 只重算链状态。两者耗时、风险与适用病灶不同，本文给出判别路径。

开了挖矿选项的比特币节点，用 getblocktemplate 从内存池挑交易组块，挑选策略由两个参数塑形：区块权重上限 blockmaxweight 和入场最低费率 blockmintxfee。本文拆解这两个阀门如何决定你的块里装了什么。

钱包创建时只启用了旧地址类型，后来想收 Taproot 怎么办？比特币核心的 createwalletdescriptor 允许在同一个 HD 种子下补建一种地址类型的描述符，不用换钱包、不用动助记词。本文拆解它的参数与备份要求。

开了修剪的钱包节点可能"看不见"某些历史交易，但收款是真实的。比特币核心用 importprunedfunds 把外部提供的原始交易加默克尔证明直接写进钱包，跳过重扫。本文讲清这对命令的工作前提、余额影响与 removeprunedfunds 的对应关系。

比特币核心的 sethdseed 给旧式钱包换一把 HD 种子：新地址从新种子派生，keypool 整体冲刷重来。但已经发出去的旧地址一分钱都不会因此消失。本文拆解这个命令的适用边界、newkeypool 参数语义与备份要求。

Bitcoin Core v31.0 把内存池的实现换成了集群设计：相互有父子关系的交易被划进同一个簇，默认每簇不超过 64 笔、约 101 千字节，节点按簇排序、按簇驱逐。本文讲清这次底层改造与老规则（祖先与后代限制、CPFP carve out）的告别，以及对加急费用策略的实际影响。

Bitcoin Core 28.0 把版本号为 3 的交易纳入标准策略，配套 TRUC（拓扑受限直至确认）规则：一笔 v3 交易至多带一个未确认的 v3 子交易，整包有体积上限。这套契约的目的，是让闪电通道等合约协议的加急费用在任何时候都掷得出。本文拆解这套规则与锚点输出的演进关系。

一笔交易的输入还找不到时，比特币节点不会立刻丢弃它，而是放进一个专门的等待区，边找父交易边收着。本文拆解这个孤儿交易池的容量边界、29.0 与 30.0 版本的规则变化，以及它对转账排查的实际意义。

比特币交易头部的版本字段不只是标签：节点的中继政策只接受版本 1 到 3 的交易，超出的会被标为不标准而拒转。本文拆解版本字段的双重角色、两步放行的部署传统，以及它和共识规则的关系。