区块过滤器索引默认不建：blockfilterindex 开启后换来什么

用全节点钱包做历史扫描时，有人会遇到 scanblocks 返回 requires blockfilterindex 的提示。这句话指向 blockfilterindex 参数，而它的答案和许多老教程相反：在比特币核心 v31.0 源码里，默认值是 DEFAULT_BLOCKFILTERINDEX = "0"——默认关闭，且 v28.0 同样是 0。换句话说，不写配置就没有这个索引。

它是什么？2019 年前后社区为轻客户端设计的紧凑区块过滤器（BIP 157/158 思路）：每个区块附带一条由该区块脚本要素压缩成的短过滤器，客户端拿自己的描述符去匹配，命中才请求完整区块。blockfilterindex 就是节点为这些过滤器按高度建立的本地数据库。开启方式要么 -blockfilterindex=1（全部类型，当前即 basic），要么按类型列表启用。它换来三件事：其一，scanblocks RPC 可用——钱包扫描历史时先查过滤器再取候选块，扫描几分钟到几小时不等，官方帮助文本还提醒这条调用可能耗时，建议把 RPC 客户端超时设为 0；其二，你的节点能通过 P2P 协议向对等节点供过滤器（需同时开 -peerblockfilters）；其三，getblockfilter RPC 有数据可答。顺带记住过滤器性质：它会为不存在的要素答”可能有”，绝不为真实要素答”没有”。

代价是一份独立磁盘数据库。判断逻辑很简单：扫描全链区块体的网络与 CPU 开销，换成一笔固定量级的本地存储。对只查自己余额的个人节点，这笔交换通常划算；对存储紧张的剪枝节点，则需要权衡后再开。

与 txindex 的分界要划清：txindex 回答”这笔交易在哪个块”，过滤器索引回答”这个块里可能出现哪些脚本要素”，用途与成本都不重叠，不存在谁替代谁。另一条边界来自过滤器本身的性质：它可能假阳性——为不存在的要素答”可能有”，但绝不会为真实要素答”没有”；scanblocks 的选项里甚至注明假阳性大约百万分之一量级，也可选择花更力气过滤（剪枝节点上可能失败）。所以”扫出候选块比交易历史多”是设计使然，后续要用候选块做精确匹配，不是扫描器出错。

故障与验收场景排一遍：新节点开启参数后需要逐块补建索引，期间 RPC 报索引不可用属正常，getindexinfo 可看进度；配置 -peerblockfilters=1 却没开过滤器索引会触发 Cannot set -peerblockfilters without -blockfilterindex 的启动错误（这一对早被专门写过）；剪枝节点上 filter_false_positives 选项可能失败，遇到报错回退默认选项即可。隐私视角顺带一提：桌面全节点钱包用过滤器扫描历史时，只需取回少量真正相关的区块，其余区块不用下载，这正是不少隐私指南推荐的组合。

部署顺序上也有一条容易踩的先后关系：过滤器索引与隐私扫描的收益，只在”钱包用描述符挂到这个节点上”的场景里完全兑现。典型玩法是把桌面全节点钱包的描述符交给一个支持 scanblocks 的流程——先在节点本地按过滤器圈出候选高度，再只对候选高度取块精配，全链扫描期间的下载量从”所有块”降到”命中块加过滤器的传输”。注意官方帮助对这条调用的提醒：它可能要几分钟以上，RPC 客户端超时建议设成不限时，否则你会得到”看起来卡死”的假象，而服务端其实仍在扫描。用异步动作加轮询状态的姿势调用，比把超时拉满硬等更稳。

从网络贡献的角度顺带一句：开启过滤器索引并配合 -peerblockfilters 的节点，让轻客户端能像查询普通数据一样向公共节点索取过滤器而不暴露精确查询意图，这是公共基础设施性质的贡献。个人节点是否要承担这份磁盘开销，可以按”我是否用它做隐私扫描、我是否愿意服务轻客户端”两问来定，两问都为否则保持默认关闭即可，不必制造用不上的索引。

再补一条与剪枝的互斥常识：filter_false_positives 精滤选项在剪枝节点上可能直接失败——精滤需要回读候选块的原始数据，而剪枝节点未必还留着；该选项的说明同时注明，若不启用精滤，假阳性会以过滤器参数约定的低比例出现。规划磁盘预算时，把”索引库 + 精滤需求 + 链上数据保留策略”三件事放在一起排，而不是开了剪枝再惊讶于选项报错。所有开关的当前默认值以你版本帮助文本里 default 字段为准，这一句对本文所有参数都成立。