Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 16EFE1A7E for ; Fri, 11 Oct 2019 15:51:38 +0000 (UTC) X-Greylist: delayed 00:06:39 by SQLgrey-1.7.6 Received: from sokrates4.ch-meta.net (sokrates4.ch-meta.net [80.74.145.74]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3184E81A for ; Fri, 11 Oct 2019 15:51:37 +0000 (UTC) Received: from [192.168.0.3] (cable-static-140-182.teleport.ch [87.102.140.182]) by sokrates4.ch-meta.net (Postfix) with ESMTPSA id DE40819E031A; Fri, 11 Oct 2019 17:44:54 +0200 (CEST) Authentication-Results: sokrates.metanet.ch; spf=pass (sender IP is 87.102.140.182) smtp.mailfrom=dev@jonasschnelli.ch smtp.helo=[192.168.0.3] Received-SPF: pass (sokrates.metanet.ch: connection is authenticated) From: Jonas Schnelli Content-Type: multipart/alternative; boundary="Apple-Mail=_A962AF1C-B0BE-42D6-BB58-F14304F2A954" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) Date: Fri, 11 Oct 2019 17:44:54 +0200 References: To: "admin@bitaps.com" , Bitcoin Protocol Discussion In-Reply-To: Message-Id: <1C1A9686-C852-4513-A05C-64F518105516@jonasschnelli.ch> X-Mailer: Apple Mail (2.3594.4.19) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Block Batch Filters for Light Clients X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 15:51:38 -0000 --Apple-Mail=_A962AF1C-B0BE-42D6-BB58-F14304F2A954 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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. >=20 > = https://github.com/bitaps-com/bips/blob/master/bip-mempool-transactions-fi= lters.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 --Apple-Mail=_A962AF1C-B0BE-42D6-BB58-F14304F2A954 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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-tran= sactions-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

= --Apple-Mail=_A962AF1C-B0BE-42D6-BB58-F14304F2A954--