Bloom Filter Implementation

They argue that this would negatively affect performance gains by causing a round-trip. Instead, they propose a solution to do bulk getblocks on hundreds/thousands of blocks at a time, allowing data to stream in.To save bandwidth and network round-trips, the writer suggests using a class called CLiteMerkleTx and a class called CMerkleBlock. These classes include variables such as nVersion, hashPrevBlock, hashMerkleRoot, nTime, nBits, nNonce, and vMatchedTxns, and provide transactions immediately in the block.The author mentions implementing a new bloom filter and block relay type in response to the "New P2P commands for diagnostics, SPV clients" thread. This implementation enables faster relay for clients with transactions in the memory pool. SPV clients can request that all future MSG_TX inv messages and blocks are filtered by sending a filterload message with a serialized bloom filter.Nodes can add particular data blocks to the filter using filteradd messages (not recommended for anonymity) and disable filtering on a node's connection until re-enabled by calling filterclear. The filter matches transactions with script data elements in either a scriptPubKey or scriptSig, spends an input whose COutPoint is in the filter, has a hash in the filter, or has a script data element in a prevout's scriptPubKey. Matching of prevouts only occurs on free txes, not those in blocks.The writer advises SPV clients to update the remote node's filter before requesting a block, if necessary, to ensure it includes the hash of any transaction that would not otherwise match the filter. This allows the node to know when its transactions are included in blocks.While the author is not keen on requiring SPV nodes to constantly update the filter when they learn about new transactions, they believe it is not worth loading all prevouts when a node is in IBD to fix the issue.For those interested, the branch of this implementation can be found at https://github.com/TheBlueMatt/bitcoin/compare/master...bloom.