[bitcoin-dev] Block Batch Filters for Light Clients

Jonas Schnelli dev at jonasschnelli.ch
Fri Oct 11 15:44:54 UTC 2019


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 <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191011/f88698ba/attachment.html>


More information about the bitcoin-dev mailing list