📅 Original date posted:2019-10-11 📝 Original message: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. > > github.com/bitaps-com/bips/blob/master/bip-mempool-transactions-filters.mediawiki <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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191011/f88698ba/attachment.html>