压缩区块传播依赖 sendcmpct 消息谈定的高带宽席位，而节点最多同时保留三个这样的对端。本文基于 Bitcoin Core 31.0 源码拆解 sendcmpct 的版本协商、三席轮换逻辑与保护出站席位的细节。

链顶切换后节点会主动向邻居通报新块，但比特币核心 v31.0 给这件事设了上限：一次最多八个区块哈希，超了就依靠对端自己的同步机制。本文沿源码讲清通告数量是怎么截断的、为什么初始同步阶段完全不中继、队列里为什么要反向插入，以及 headers 消息与 inv 公告两种通告形式的分工。

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

压缩区块靠接收方内存池复原，交易离开内存池后可能落在重建窗口里。本文依据 v31 源码拆解短 ID 复原流程、指纹碰撞的加长补救与额外交易缓冲的账本意义。