1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 16EFE1A7E
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 =
<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--
|
