MSG_FILTERED_WITNESS_BLOCK

MSG_FILTERED_WITNESS_BLOCK is inventory code 0x40000003, reserved when segwit's peer rules were written in 2016 and never given an implementation. Bitcoin Core carries it as an enum entry with a comment recording exactly that. The light-wallet feature it would have extended, BIP37 bloom filtering, was switched off by default in Bitcoin Core 0.19.0, which matters to you only if your phone wallet still leans on it.

How it works

Status: reserved and never built. BIP144 named the type; Bitcoin Core carries it as an enum entry in src/protocol.h with a comment recording that no handler exists. The BIP37 filtering it would have served has been disabled by default since Bitcoin Core 0.19.0 in November 2019, and BIP157 and BIP158 compact block filters are the replacement.

Understanding the gap means understanding what a filtered block was. A light client using BIP37 sends a filterload message describing, loosely, the addresses it cares about. It then requests inventory type 3, MSG_FILTERED_BLOCK, and the serving node replies with a merkleblock message: the 80-byte block header, a transaction count, a partial merkle branch, and a bitfield saying which way to walk the tree. Matching transactions follow as separate messages. The client checks that each one really hangs off the header's merkle root, and it does that using txids alone.

Witnesses never entered that arithmetic. Since the merkle root is built from txids, a light client can prove inclusion without a single signature, so the follow-up transactions were sent stripped. The reserved type 3 with the witness flag added, 0x40000003, would have let a client ask for those transactions in full. Nobody built it, because nobody producing light wallets wanted more BIP37.

The reason is privacy, not effort. The filter a client uploads tells the serving node roughly which addresses belong to it, and research through the mid-2010s showed those filters leaked far more than intended. Bitcoin Core's answer was to stop serving them by default rather than repair the design. BIP158 inverts the flow instead: the node builds one small Golomb-coded filter per block, tuned to a false positive rate of one in 784,931, and publishes it. The client downloads filters, tests them locally, and only fetches a whole block on a hit, so the server learns nothing about which addresses were of interest.

Where you see it

Almost nowhere, which is the honest answer for anyone who finds MSG_FILTERED_WITNESS_BLOCK in a reference table.

Grep Bitcoin Core for the constant and you find a single enum member. Alternative implementations such as btcd mirror the name in their wire packages for completeness, again with no behaviour behind it. No wallet has ever sent it.

Where the topic does touch a buyer is in how a mobile wallet gets its data. If a wallet describes itself as SPV and connects to random public nodes with bloom filters, it is using a mechanism the reference implementation stopped serving by default years ago, and it is telling those nodes something about your addresses. Wallets built on compact block filters, the design behind lnd's Neutrino, ask for far less. A wallet pointed at its vendor's own server is the third option, and the most common: fast, private from strangers, and fully visible to the vendor.

MSG_FILTERED_WITNESS_BLOCK vs merkle block

A merkle block is the answer; MSG_FILTERED_WITNESS_BLOCK is a request that was never wired to produce one. The merkleblock message is a real, implemented structure that proves a set of transactions belongs to a block without sending the block. The reserved witness variant would only have changed what came after that proof, namely whether the matching transactions arrived with their signatures. Since inclusion proofs work off txids, the missing feature cost nobody anything.