握手时的自我介绍
比特币节点建立 P2P 连接时先交换 version 消息，其中有一个 services 字段，是一组比特位，声明“我能提供哪些服务”。对端据此决定要不要从你这里要数据、要哪类数据。跑全节点的人未必注意，你的机器每天都在把这些能力声明广播给邻居。
常见服务位包括：第 0 位 NODE_NETWORK，表示保存完整区块历史、可供任意区块下载；见证支持通过 NODE_WITNESS（包含 NODE_NETWORK 位并另置第 3 位）宣告；第 2 位 NODE_BLOOM 对应 BIP 37 的布隆过滤服务；第 6 位 NODE_COMPACT_FILTERS 表示可提供 BIP 157 紧凑过滤器；第 10 位 NODE_NETWORK_LIMITED 来自 BIP 133，表示修剪模式的节点愿意提供最近一段区块（规范约定至少最近 288 块，约两天）供新节点追赶时补充用。
默认值的来历
布隆过滤服务值得单独说：BIP 37 让轻客户端把“我关注哪些地址”的过滤器上传给节点代查，既消耗节点资源又泄露隐私，还长期是拒绝服务攻击面。Bitcoin Core 从 0.19 起把 peerbloomfilters 默认值改为 false，即默认不再宣告 NODE_BLOOM、不接受布隆过滤器；也就是说近年默认配置的普通节点大多已不为老式 SPV 钱包服务。替代路线是紧凑过滤器：节点为每个区块生成一份统一的小型集合发给所有轻客户端，客户端自己本地匹配，不再泄露地址列表，见 轻钱包凭什么可信。
怎么自查与怎么看别人
运行中的节点用 RPC getnetworkinfo 看 localservices（自己宣告的）与各邻居的 services 字段，即可核对实际生效的服务位；修剪节点开不开 NODE_NETWORK_LIMITED 取决于 prune 配置与版本，修剪带来的能力取舍见 节点修剪模式。观察全网邻居分布可用 getnodeaddresses 之类的接口抽样。还要提醒：隐私网络上节点宣告自己活跃会暴露“这台机器在用比特币”，Tor 场景下如何权衡见 用 Tor 跑比特币节点。
为什么值得普通用户关心
服务位决定新节点追链时能从哪些对端拿到数据、轻客户端能找到哪些服务型节点。你如果开着修剪节点发现别人从你这取不到古老区块、或自己同步时对可用对端少，多半就是服务位与模式组合的结果，而不是网络故障。理解这组比特，是把“我的节点正常吗”从玄学变成可核对事实的第一步。
风险提示：比特币价格与网络状态波动较大，本文仅作技术与安全科普，不构成任何投资建议；涉及资金操作前请小额试转并逐项核对，所有协议参数以官方规范与源码为准。
同步体验与服务位的对应关系
刚启动的新节点最需要”最近区块”和”完整历史”两种数据源：向宣告 NODE_NETWORK 的邻居下载历史区块，向宣告 NODE_NETWORK_LIMITED 的修剪邻居补最近两天左右的区块做追赶，两条腿都正常时同步最顺。反过来，如果你的节点长期修剪且只开受限服务位，它对新节点的价值集中在尾部区块；而默认关闭了 NODE_BLOOM 后，你的节点依然服务现代轻客户端（走紧凑过滤器），只是不再为老式 SPV 钱包代查交易。运维上值得养成的习惯：升级 Bitcoin Core 大版本后跑一次 getnetworkinfo，对比升级前后的 localservices 变化，发现新增或消失的比特位就去发行说明里找原因——服务位的变动几乎总是对应着一次默认策略或隐私相关的决策，而不是随手改的。也要提醒一句常识边界：这些比特来自源码 protocol.h 中的协议常量，是节点间的行为约定，不是链上共识规则——改服务位不需要软分叉，也不会改变账本，它只改变”谁愿意为谁服务”。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。