Jonas Schnelli [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-11 📝 Original message:Hi Aleksey > BIP 157 ...
📅 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.
>
> 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>;
📝 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.
>
> 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>;