Received-SPF: pass (sokrates.metanet.ch: connection is authenticated)
From: Jonas Schnelli <dev@jonasschnelli.ch>
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: <mailman.22.1569240010.14875.bitcoin-dev@lists.linuxfoundation.org>
	<E9935F93-B5D2-48FD-96D2-88EF605ADA4B@bitaps.com>
To: "admin@bitaps.com" <admin@bitaps.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <E9935F93-B5D2-48FD-96D2-88EF605ADA4B@bitaps.com>
Message-Id: <1C1A9686-C852-4513-A05C-64F518105516@jonasschnelli.ch>
Subject: Re: [bitcoin-dev] Block Batch Filters for Light Clients
Precedence: list


--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 =
<https://github.com/bitaps-com/bips/blob/master/bip-mempool-transactions-f=
ilters.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

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space;" class=3D"">Hi Aleksey<br =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">BIP 157 =
unlike BIP 37 not allow apply filters to mempool and check zero =
confirmation transactions.<br class=3D"">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.<br =
class=3D""><br class=3D""><a =
href=3D"https://github.com/bitaps-com/bips/blob/master/bip-mempool-transac=
tions-filters.mediawiki" =
class=3D"">https://github.com/bitaps-com/bips/blob/master/bip-mempool-tran=
sactions-filters.mediawiki</a><br class=3D""></blockquote><br =
class=3D"">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).<br class=3D"">In general, I guess the concerns are DOS and =
fingerprinting.<br class=3D""><br class=3D"">Maybe DOS could be =
mitigated via a dynamic filter construction (append elements during the =
time between blocks, though unsure if possible).<br class=3D"">The =
update-interval of a such filter could also be timebases rather than on =
every new tx in the mempool.<br class=3D""><br class=3D"">Unsure about =
fingerprinting defence measures.<br class=3D""><br class=3D"">I would =
expect the following process:<br class=3D"">* peer generates mempool =
filter<br class=3D"">* [timespan A (say 3 seconds)]<br class=3D"">* =
light client connects to peer<br class=3D"">* light client requests =
mempool-filter<br class=3D"">* peers sends mempool filter<br class=3D"">* =
light client processes filter for relevant txns<br class=3D"">* =
eventually, light client sends getdata of relevant txns<br class=3D""><br =
class=3D"">a) after the initial retrieve...<br class=3D"">* light client =
inspects all new txns (inv/getdata) received from peers from this point =
on (filterless unconfirmed tx detection)<br class=3D""><br class=3D"">Of =
if a) is to bandwidth expansive, request the mempool filter again after =
a timeout<br class=3D""><br class=3D"">/jonas<div class=3D""><br =
class=3D""></div></body></html>=

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