Hi Aleksey > BIP 157 unlike BIP 37 not allow apply filters to mempool and check zero confirmation transactions. > Light client that refused to use BIP 37 due to privacy leaks can process unconfirmed transactions only one way and this is loading the entire mempool transaction flow. > > https://github.com/bitaps-com/bips/blob/master/bip-mempool-transactions-filters.mediawiki Instead of using a per tx filter, would it be possible to allow retrieving a complete compact filter of the whole mempool (similar to BIP35)? Maybe using a maximum size of the filter (ordered by feerate). In general, I guess the concerns are DOS and fingerprinting. Maybe DOS could be mitigated via a dynamic filter construction (append elements during the time between blocks, though unsure if possible). The update-interval of a such filter could also be timebases rather than on every new tx in the mempool. Unsure about fingerprinting defence measures. I would expect the following process: * peer generates mempool filter * [timespan A (say 3 seconds)] * light client connects to peer * light client requests mempool-filter * peers sends mempool filter * light client processes filter for relevant txns * eventually, light client sends getdata of relevant txns a) after the initial retrieve... * light client inspects all new txns (inv/getdata) received from peers from this point on (filterless unconfirmed tx detection) Of if a) is to bandwidth expansive, request the mempool filter again after a timeout /jonas