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
|
Return-Path: <laolu32@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 33CAFACC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 May 2018 03:12:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8967CB0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 May 2018 03:12:23 +0000 (UTC)
Received: by mail-wm0-f52.google.com with SMTP id x12-v6so5462300wmc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 May 2018 20:12:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=MtowvWTG2hcPpawNaX3nEm44hErtrOfSST7KydiQBbw=;
b=ZnjdYRSN1xNCe+TkAHA4WOCAzBCEq/j9U54/ahm0SNeKkzNMSemhlng8VFT8VAgkKo
D35zsGtO4TBGqn2uexDF6zAzHCSOG1KuoDHAlzp4FJZ5dxOTeng+ZJahde4PTdsXGDSh
dO8T3Y5LDCIA7dTcbM2EdygfH6i8c4Lb/H53p9kqeZsrKlXgsldlV65kd5QsAXi4rIKH
hDYpmKB7/3rfvOMZ/Irzr711bIpNYDoinpA4NWQroTBmHdYP7UeRSx0KXBa6NhP1e0Eh
deBaOVThbC+Gd4XR5llH161w4/qCaTb0dJvBtNGtcRATGMk2z7gUjg4N7TgsPf2UCeL/
9nxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=MtowvWTG2hcPpawNaX3nEm44hErtrOfSST7KydiQBbw=;
b=Hymry23u1LeBseKRpvnJzZ0UWK7vekW4T4u4mvfH8qYYDt6782nHQ5L3g1cKhFTIUb
sjAjufq5gB6ng5dsPcLzdCd+HxN1joKOPXTmkOKjdHueNosN6iEbj/yLHhq7xSCYBfk5
ouCzXGLbt7L/aXK06zKQMjuRvUGxcEk1rUbQ+UAVZM8ovN97msg5Ju79n4KecDpgQKbG
sS83HYrSmp9St2ZOtbbcGXZB/eUu5S/E4rnrsxzIFpUa9YFWe2UIkIYtOmjFtA1MS4MU
odtHSkxzDC2ss+ZjF147vRbRbXXeoM1ijkTnL1gRKwc0MlxkXxD5n/Uul2zM0zxpvQLj
/8cg==
X-Gm-Message-State: ALKqPwdecyZIwnJX2KdvJyyPc+A3G1M4J3xmPOwJbeeY2IedyZKgX/CB
Zzzp3CUatXKS5JJsTMk7a2+aeHe7FUBknqDAsDg8pw==
X-Google-Smtp-Source: AB8JxZr51WY7RVe8jy8JBzKVmvxx61XzAuf4f7FUH6Fmg7P7v95uwS6IxVFuoFrVo/26Xp2sEF7vIghMh95p8tpj6nQ=
X-Received: by 2002:a50:d311:: with SMTP id
g17-v6mr14285427edh.160.1526699542159;
Fri, 18 May 2018 20:12:22 -0700 (PDT)
MIME-Version: 1.0
References: <d43c6082-1b2c-c95b-5144-99ad0021ea6c@mattcorallo.com>
<CAAS2fgRF-MhOvpFY6c_qAPzNMo3GQ28RExdSbOV6Q6Oy2iWn1A@mail.gmail.com>
<22d375c7-a032-8691-98dc-0e6ee87a4b08@mattcorallo.com>
<CAAS2fgR3QRHeHEjjOS1ckEkL-h7=Na56G12hYW9Bmy9WEMduvg@mail.gmail.com>
<CADZtCShLmH_k-UssNWahUNHgHvWQQ1y638LwaOfnJEipwjbiYg@mail.gmail.com>
<CAAS2fgQLCN_cuZ-3QPjCLfYOtHfEk=SenTn5=y9LfGzJxLPR3Q@mail.gmail.com>
<CADZtCSjYr6VMBVQ=rx44SgRWcFSXhVXUZJB=rHMh4X78Z2eY1A@mail.gmail.com>
In-Reply-To: <CADZtCSjYr6VMBVQ=rx44SgRWcFSXhVXUZJB=rHMh4X78Z2eY1A@mail.gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Fri, 18 May 2018 20:12:09 -0700
Message-ID: <CAO3Pvs9K3n=OzVQ06XGQvzNC+Aqp9S60kWM9VRPA8hWTJ3u9BQ@mail.gmail.com>
To: Jim Posen <jim.posen@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e3a647056c866f1e"
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size
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: Sat, 19 May 2018 03:12:24 -0000
--000000000000e3a647056c866f1e
Content-Type: text/plain; charset="UTF-8"
On Thu, May 17, 2018 at 2:44 PM Jim Posen via bitcoin-dev <bitcoin-
> Monitoring inputs by scriptPubkey vs input-txid also has a massive
>> advantage for parallel filtering: You can usually known your pubkeys
>> well in advance, but if you have to change what you're watching block
>> N+1 for based on the txids that paid you in N you can't filter them
>> in parallel.
>>
>
> Yes, I'll grant that this is a benefit of your suggestion.
>
Yeah parallel filtering would be pretty nice. We've implemented a serial
filtering for btcwallet [1] for the use-case of rescanning after a seed
phrase import. Parallel filtering would help here, but also we don't yet
take advantage of batch querying for the filters themselves. This would
speed up the scanning by quite a bit.
I really like the filtering model though, it really simplifies the code,
and we can leverage identical logic for btcd (which has RPCs to fetch the
filters) as well.
[1]:
https://github.com/Roasbeef/btcwallet/blob/master/chain/neutrino.go#L180
--000000000000e3a647056c866f1e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, May 17=
, 2018 at 2:44 PM Jim Posen via bitcoin-dev <bitcoin-=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">Monitoring inputs by scr=
iptPubkey vs input-txid also has a massive<br>
advantage for parallel filtering:=C2=A0 You can usually known your pubkeys<=
br>
well in advance, but if you have to change what you're watching block<b=
r>
=C2=A0N+1 for based on the txids that paid you in N you can't filter th=
em<br>
in parallel.<br></blockquote><div><br></div></div></div></div><div dir=3D"l=
tr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Yes, I'l=
l grant that this is a benefit of your suggestion.</div></div></div></div><=
/blockquote><div><br></div><div>Yeah parallel filtering would be pretty nic=
e. We've implemented a serial filtering for btcwallet [1] for the use-c=
ase of rescanning after a seed phrase import. Parallel filtering would help=
here, but also we don't yet take advantage of batch querying for the f=
ilters themselves. This would speed up the scanning by quite a bit.=C2=A0</=
div><div><br></div><div>I really like the filtering model though, it really=
simplifies the code, and we can leverage identical logic for btcd (which h=
as RPCs to fetch the filters) as well.=C2=A0</div><div><br></div><div>[1]:=
=C2=A0<a href=3D"https://github.com/Roasbeef/btcwallet/blob/master/chain/ne=
utrino.go#L180">https://github.com/Roasbeef/btcwallet/blob/master/chain/neu=
trino.go#L180</a>=C2=A0</div></div></div>
--000000000000e3a647056c866f1e--
|
