The filteradd message tells the receiving peer to add a single element to a previously-set bloom filter, such as a new public key.

Part of the connection bloom filtering mechanism as described in BIP-37.

The element is sent directly to the receiving peer; the peer then uses the parameters set in the “filterload” message to add the element to the bloom filter.

Because the element is sent directly to the receiving peer, there is no obfuscation of the element and none of the plausible-deniability privacy provided by the bloom filter. Clients that want to maintain greater privacy should recalculate the bloom filter themselves and send a new “filterload” message with the recalculated bloom filter.


Data Type






The element to add to the current filter. Maximum of 520 bytes, which is the maximum size of an element which can be pushed onto the stack in a pubkey or signature script. Elements must be sent in the byte order they would use when appearing in a raw transaction; for example, hashes should be sent in internal byte order.

Note: a “filteradd” message will not be accepted unless a filter was previously set with the “filterload” message.

The annotated hexdump below shows a “filteradd” message adding a TXID. (The message header has been omitted.) This TXID appears in the same block used for the example hexdump in the “merkleblock” message; if that “merkleblock” message is re-sent after sending this “filteradd” message, six hashes are returned instead of four.

20 ................................. Element bytes: 32
9dee312d666187ed77ee7d26af16cb0b ... Element (A TXID)