广播交易被拒却没有任何解释，是比特币网络的默认行为，来自主流实现对 BIP 61 reject 消息的主动拆除：v0.17 加开关、v0.18 宣布弃用、v0.19 默认关闭、v0.20 物理删除。这条回执本身没有密码学强度——对方可以寄假回执，也可以根本不寄。本文复盘四年拆除时间线，并给出今天查拒收原因的正确路径。

BIP-37 把 relay 标志作为可选字段塞进 version 消息，BIP-60 则主张把每个协议版本的消息恢复成固定字段数。本文解释可选字段为什么破坏反序列化纪律，以及 relay 布尔值最终长在哪两个字段之间。

BIP-36 给 version 消息加了 service_count 与 service_list 字段，让节点用字符串名字申报自定义服务，避免抢占稀缺的 64 位 services 位图。本文拆解服务名、服务版本、service_data 三条规则，以及转正为 NODE_* 常数的路径。

BIP-33 在 2012 年提出分层节点：用 NODE_SERVICE 与 NODE_STRATIZED 两个新服务位，让轻量客户端将区块链查询委托给专职节点。本文回溯它与 BCCAPI、Electrum、Stratum 的承继关系，以及四个新查询消息的设计。

两个版本不同的以太坊节点该怎样互相信任地交换消息？EIP-8 在2015年底给 devp2p 协议定了三条互相兼容的规矩：忽略打招呼包里的版本号、忽略消息尾部多出来的字段、未知类型的发现包静默丢弃。这套按网络工程老规矩写的向前兼容要求，让节点网络在协议演进中不必一刀两断。本文讲清它改了什么、为什么这样设计。

当节点被允许丢弃远古历史，谁来担保某个老区块仍然有人可取？EIP-7801 提议新建 etha 子协议：把链历史切成固定长度的条带，节点握手时交出一张位图声明自己存了哪些条带、并承诺续存未来的条带。本文拆解这条 2024 年 10 月的 Networking 草案如何把可用性从碰运气变成可声明的资源。

比特币核心用 version 消息里的 8 字节 nonce 与自家在途外连比对，命中即记 connected to self 并断开；私有广播连接的 nonce 被有意排除，源码注释给出一条完整的钓鱼反例。本文讲机制、触发场景与边界。

v31 源码里 PROTOCOL_VERSION 为 70016、断连线 MIN_PEER_PROTO_VERSION 为 31800，且 v30 起未上调：数字门槛只挡远古实现，功能靠逐项协商降级。本文讲两套编号分工与 version 消息的三道检查。

比特币核心把入站对端 version 消息里的 addrMe 当证言投票，配合网卡、绑定、PCP 与 -externalip 四级来源构建本机地址表，再按 24 小时抖动节拍向对端公告自己。本文按 v31 源码拆解这条流水线。

getpeerinfo 的 connection_type 来自源码里的七类枚举：全中继 8 条、区块专用 2 条加锚定、feeler 每两分钟一条、地址拉取与私有广播用完即关。本文按 v31 源码逐类讲职责、名额与排障读法。