轻节点靠区块过滤器对账，全节点靠索引存过滤器。比特币核心的 /rest/blockfilter 与 /rest/blockfilterheaders 两个 REST 端点，把 BIP157 的 basic 过滤器按区块哈希和连续段两种粒度开放出来。本文按 v31.0 源码讲清请求格式、两千克拉取闸门与索引前置条件。

比特币核心开着 -rest 时，/rest/mempool/info 和 /rest/mempool/contents 这两个 HTTP 端点把内存池的总量指标与逐单明细直接摊在 URL 上，还支持 verbose 与 mempool_sequence 两个查询参数。本文按 v31.0 源码拆解端点行为、参数互斥关系，以及它没有鉴权这层事实带来的暴露面。

v29 放弃 UPnP 支持并把外部映射库换成内建的 PCP 与 NAT-PMP 实现，v30 让 -natpmp 默认开启并彻底删除 -upnp。本文按发布说明与 v31 源码复盘这场换代：两者管什么、哪些开关会联动，以及家用节点怎么确认映射真的生效。

getpeerinfo 一次返回每台对端的几十个字段，混着身份、流量、时钟、同步进度四类信息。本文按比特币核心 v31.0 源码的字段定义，把这份对端档案分格拆解，并给出排障时真正该盯的几组读法。

重组时比特币核心 v31.0 不会把被拆区块的交易立刻塞回内存池，而是先放进一个上限两千万字节的暂存容器，等整段重组处理完再统一回灌。本文拆解这个容器的排序规则、超限时的递归删除、回灌时绕过限额与忽略失败的原因，以及它如何解释钱包里交易从一确认退回零确认。

比特币核心 v31.0 下载区块时受三个常量约束：向前一千零二十四个高度的下载窗口、按出块间隔倍数计算并随并发对端放宽的超时线，以及默认只有两秒却会自适应翻倍的卡死阈值。本文按源码解释这三道闸门各自的算法与适用场景，并回答节点为什么看起来频繁断开对端。

比特币核心 v31.0 里，节点收到区块或区块头时并不直接入库，还要先看调用方有没有做过反消耗战的工作量检查。本文拆解 min_pow_checked 参数的三种取值路径、GetAntiDoSWorkThreshold 留 144 个区块余量的算法，以及 too-little-chainwork 为什么不会连累你的对端被处罚。

assumeUTXO 快照同步期间，比特币节点内部同时存在快照链与回填验证链两本账，getblockchaininfo 只汇报活动一条，getchainstates 会把全部链状态按工作量排列列出：各自的进度、难度、缓存拆分，以及标记快照血统的 snapshot_blockhash 和补课完成的 validated 布尔值。本文按 v31.1 源码给出双账阶段的监控判据。

v29.0 起，比特币核心提供两段式历史对账：scanblocks 先圈出可能相关的区块，getdescriptoractivity 再把每个区块拆成 spend 与 receive 事件列表，带金额、出处 prevout、脚本和确认高度，未确认活动靠字段省略来标识。它不需要常驻索引，但帮助文本明说可能跑上几分钟。本文按 v31.1 源码拆解两组必填参数、返回结构与超时处理。

mempool.dat 记录的不只是交易，还有原节点的入场时间、费用加权值和未广播集合三本本地账。v26.0 新增的 importmempool RPC 让你不重启、不改数据目录就把别的节点的账本灌进内存池，但帮助文本警告：导入不受信文件的元数据是危险的。本文按 v31.1 源码拆解 use_current_time、apply_fee_delta_priority、apply_unbroadcast_set 三个开关的默认值与取舍。