MSG_FILTERED_WITNESS_BLOCK

MSG_FILTERED_WITNESS_BLOCK 是清单代码0x40000003，于2016年制定隔离见证的节点规则时被保留，此后从未有过实现。Bitcoin Core 将其作为枚举项保留，并附有注释，恰如其分地记录了这一点。它本应扩展的轻钱包功能，即 BIP37 布隆过滤，已在 Bitcoin Core 0.19.0中默认关闭，只有当您的手机钱包仍依赖它时，这件事才与您相关。

运作方式

状态：已保留，从未实现。BIP144 为该类型命名；Bitcoin Core 在 src/protocol.h 中将其作为枚举项保留，并附有注释，说明不存在任何处理程序。它本应服务的 BIP37 过滤功能，自2019年11月发布的 Bitcoin Core 0.19.0起已默认禁用，BIP157 和 BIP158 的紧凑区块过滤器是其替代方案。

要理解这一空缺，就要先理解过滤区块是什么。使用 BIP37 的轻客户端会发送 filterload 消息，大致描述自己关心的地址。随后它请求清单类型3，即 MSG_FILTERED_BLOCK，提供服务的节点则以 merkleblock 消息作答：80字节的区块头、交易数量、部分默克尔分支，以及一个指明如何遍历该树的位字段。匹配的交易随后作为单独的消息发来。客户端核实每笔交易确实挂靠在区块头的默克尔根之下，而这一核实仅使用 txid。

见证数据从未进入这一运算。由于默克尔根由 txid 构建，轻客户端无需任何签名即可证明交易被包含在区块中，因此后续发送的交易都是去除见证数据的。保留的类型，即加上见证标志的类型3，也就是0x40000003，本可让客户端请求这些交易的完整版本。没有人实现它，因为没有任何制作轻钱包的人想要更多的 BIP37。

原因在于隐私，而非实现难度。客户端上传的过滤器会大致告诉提供服务的节点哪些地址属于它，2010年代中期的研究表明，这些过滤器泄露的信息远超预期。Bitcoin Core 的做法是默认停止提供这类服务，而不是修补该设计。BIP158 则反转了流程：节点为每个区块构建一个小型 Golomb 编码过滤器，误报率调整为784,931分之一，并将其发布。客户端下载过滤器，在本地测试，只有在命中时才获取整个区块，因此服务器无从得知哪些地址是客户端关心的。

在哪里会遇到它

几乎无处可见，这也是对在参考表中看到 MSG_FILTERED_WITNESS_BLOCK 的人最诚实的回答。

在 Bitcoin Core 中用 grep 搜索这个常量，只会找到一个枚举成员。btcd 等其他实现为求完整，在其 wire 包中同样保留了这个名称，同样没有任何行为逻辑。从来没有钱包发送过它。

这一话题与买家相关之处，在于移动钱包如何获取数据。如果一款钱包自称是 SPV 钱包，并使用布隆过滤器连接随机的公共节点，那么它使用的是参考实现多年前就已默认停止提供的机制，同时也在向这些节点透露有关您地址的信息。基于紧凑区块过滤器的钱包（lnd 的 Neutrino 即采用这一设计）索取的信息要少得多。让钱包连接其供应商自己的服务器是第三种选择，也是最常见的一种：速度快，对陌生人保密，但对供应商完全可见。

MSG_FILTERED_WITNESS_BLOCK vs 默克尔区块

默克尔区块是应答；MSG_FILTERED_WITNESS_BLOCK 是一个从未被接入以生成应答的请求。merkleblock 消息是一个真实存在且已实现的结构，无需发送整个区块即可证明一组交易属于某个区块。保留的见证变体只会改变该证明之后的内容，即匹配的交易是否连同签名一起送达。由于包含证明基于 txid 运作，这项缺失的功能没有给任何人造成损失。