不少给比特币节点做配置的人会碰上这样一个开局：配置文件里写了 -peerblockfilters=1，启动时节点却直接罢工，日志里一行”Cannot set -peerblockfilters without -blockfilterindex”。以为是软件坏了，其实这是源码里写死的一条配对规则在把关。这两个开关，一个管”肯不肯把区块过滤器服务给别人”，一个管”这台机器有没有把过滤器算出来存好”，缺了后半句支撑的前半句承诺，比特币核心宁可拒绝启动，也不让节点对外许诺自己做不到的事。这篇把配对逻辑、默认值的版本事实、磁盘代价和服务位点亮条件讲清楚，顺便纠正一个流传很广的误会：以为”新版本早就默认全开了”。
先把概念钉准。BIP 157 定义了”基本区块过滤器”：给每个区块配一份按输出脚本构造的紧凑过滤器，体积通常每块几 KB 到几十 KB。轻钱包不必下载完整区块，先向节点要过滤器做初筛：过滤器说这块没有你的输出，就可以跳过整块；说可能有，再去要区块细看。过滤器允许误报、绝不漏报，轻钱包正是靠这个单向可靠性做快速同步。blockfilterindex 开关让节点在同步链的同时把每个区块的过滤器计算出来、存进数据目录 indexes 子目录下的索引文件；peerblockfilters 开关则是在节点握手里向对端声明”我具备并提供过滤器查询服务”。一个管生产，一个管供货，天然要配套。
配对逻辑在初始化阶段执行：只要 peerblockfilters 打开，而启用的过滤器类型里没有 basic，节点就打那条错误并退出。反向组合是合法的——只开索引不开服务位，等于自己留一份索引自用，不向网络承诺供货。所以配置层面其实只有两种自洽选择：两个都不开，做纯自验证节点；两个都开，做愿意给轻钱包供数据的公开节点。半开状态会被直接拒绝，报错提示里点名另一个参数，等于把”想反对就两个一起开”的路指给你了。
版本事实要按源码说话，这里恰好有个流传广的误传。把 v22 到 v31 各版本的源码逐个数一遍：net_processing.h 里的 DEFAULT_PEERBLOCKFILTERS 从 v22 一直到 v31 都是假；blockfilterindex 的默认值字符串从 v22 的 validation.h 到后来搬家到 index 目录下的头文件，始终是 0。也就是说过滤器功能落地以来，索引和服务位这两个开关在官方源码里默认都是关的，网络里那些带 NODE_COMPACT_FILTERS 服务位的节点，靠的是运营者在配置文件里显式写了这两行，而不是出厂自带。“新版本默认已开”的说法经不起源码核对，判断自己节点状态的正确方法很直接：跑 getindexinfo 看 basic 索引是否存在并处于 synced 状态；没开索引或索引落后的节点，绝不会点亮服务位——服务是有”毕业考试”的，索引不追平就不承诺供货。
磁盘账要提前算。基本过滤器索引要额外占用几十 GB 量级空间，并随链增长；相对全节点动辄上 TB 的区块数据不算大头，但给小容量机器做规划时不能忽略。定位是”只验证自己的钱”的节点，两个开关保持默认的关闭最省心；想给家人朋友的手机轻钱包当后端，就把 -blockfilterindex=1 与 -peerblockfilters=1 一起写进配置，用 getindexinfo 盯到索引 synced 再对外指路。重组时过滤器跟着区块回滚重算，索引损坏时节点宁可拒绝供数也不带病出货——这也是半开状态被硬拒绝的设计哲学：与其在运行中悄悄降级，不如在启动时把话挑明。
使用上的纪律归结为四条。第一，报错时不要图快把 -peerblockfilters 关掉交差，先想清楚这台节点的角色，再选”双关”或”双开”。第二，给他人供服务前确认索引 synced，并接受一个事实：应答查询会让对方节点看到你的 IP，这是隐私账不是功能账。第三，轻钱包用户看到某个后端带过滤器服务位，可以预期它愿意发数据，但正确性保障来自”向多个独立节点交叉询问”的机制设计，单一后端仍可选择性漏报，自建后端的价值在于把这份信任拿回自己手里。第四，过滤器内容是链上数据的可推导投影，任何人用自己的节点都能重算，不存在独家信息，服务位的意义是公共基础设施的互助而非信息优势。
最后给三类角色的速查。纯自验证：两个都关（即默认），省磁盘，省心；家庭轻钱包后端：两个都开并盯 synced；矿工或公开节点：显式双开，同时在带宽预算里为过滤器查询留出余量——它单次很小，但公共节点上会积少成多。风险提示：参数默认值、错误文案与索引行为随比特币核心版本变化，本文以 v22 至 v31 源码核对为准，请以所用版本官方文档复核；节点配置与磁盘规划错误可能导致服务中断，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。