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
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0304011AA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 May 2018 15:46:23 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 52FEEA3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 May 2018 15:46:22 +0000 (UTC)
Received: from [IPv6:2607:fb90:7d6:4119:5206:c22a:4c4e:19e5] (unknown
[172.56.34.52])
by mail.bluematt.me (Postfix) with ESMTPSA id EDA421A569F;
Thu, 17 May 2018 15:46:20 +0000 (UTC)
Date: Thu, 17 May 2018 15:46:18 +0000
In-Reply-To: <20180517154315.pcs6cmx3lx3on4dz@petertodd.org>
References: <d43c6082-1b2c-c95b-5144-99ad0021ea6c@mattcorallo.com>
<20180517154315.pcs6cmx3lx3on4dz@petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----LMBZD6S3EPYT4XDAMO6O7H54MYPNXC"
Content-Transfer-Encoding: 7bit
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <4703B065-AFDA-4AB6-9523-859067CF50F7@mattcorallo.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE
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] 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: Thu, 17 May 2018 15:46:23 -0000
------LMBZD6S3EPYT4XDAMO6O7H54MYPNXC
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
(1) can be accomplished by filtering for the set of outputs in the transact=
ion you created=2E I agree (2) would ideally be done to avoid issues with a=
copied wallet (theft or not), but I am worried about the size of the filte=
rs themselves, not just the size of the blocks downloaded after a match=2E
On May 17, 2018 3:43:15 PM UTC, Peter Todd <pete@petertodd=2Eorg> wrote:
>On Thu, May 17, 2018 at 11:25:12AM -0400, Matt Corallo via bitcoin-dev
>wrote:
>> BIP 158 currently includes the following in the "basic" filter: 1)
>> txids, 2) output scripts, 3) input prevouts=2E
>>=20
>> I believe (1) could be skipped entirely - there is almost no reason
>why
>> you'd not be able to filter for, eg, the set of output scripts in a
>> transaction you know about and (2) and (3) may want to be split out -
>> many wallets may wish to just find transactions paying to them, as
>> transactions spending from their outputs should generally be things
>> they've created=2E
>
>So I think we have two cases where wallets want to find txs spending
>from their
>outputs:
>
>1) Waiting for a confirmation
>2) Detecting theft
>
>The former can be turned off once there are no expected unconfirmed
>transactions=2E
>
>As for the latter, this is probably a valuable thing for wallets to do=2E
>Modulo
>reorgs, reducing the frequency that you check for stolen funds doesn't
>decrease
>total bandwidth cost - it's one filter match per block regardless - but
>perhaps
>the real-world bandwidth cost can be reduced by, say, waiting for a
>wifi
>connection rather than using cellular data=2E
>
>--=20
>https://petertodd=2Eorg 'peter'[:-1]@petertodd=2Eorg
------LMBZD6S3EPYT4XDAMO6O7H54MYPNXC
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body>(1) can be accomplished by filtering for the set o=
f outputs in the transaction you created=2E I agree (2) would ideally be do=
ne to avoid issues with a copied wallet (theft or not), but I am worried ab=
out the size of the filters themselves, not just the size of the blocks dow=
nloaded after a match=2E<br><br><div class=3D"gmail_quote">On May 17, 2018 =
3:43:15 PM UTC, Peter Todd <pete@petertodd=2Eorg> wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; border-left: 1px=
solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On Thu, May 17, 2018 at 11:25:12AM -0400, Matt Coral=
lo via bitcoin-dev wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0pt 0pt 1ex 0=2E8ex; border-left: 1px solid #729fcf; padding-left: 1ex=
;"> BIP 158 currently includes the following in the "basic" filter: 1)<br> =
txids, 2) output scripts, 3) input prevouts=2E<br> <br> I believe (1) could=
be skipped entirely - there is almost no reason why<br> you'd not be able =
to filter for, eg, the set of output scripts in a<br> transaction you know =
about and (2) and (3) may want to be split out -<br> many wallets may wish =
to just find transactions paying to them, as<br> transactions spending from=
their outputs should generally be things<br> they've created=2E<br></block=
quote><br>So I think we have two cases where wallets want to find txs spend=
ing from their<br>outputs:<br><br>1) Waiting for a confirmation<br>2) Detec=
ting theft<br><br>The former can be turned off once there are no expected u=
nconfirmed<br>transactions=2E<br><br>As for the latter, this is probably a =
valuable thing for wallets to do=2E Modulo<br>reorgs, reducing the frequenc=
y that you check for stolen funds doesn't decrease<br>total bandwidth cost =
- it's one filter match per block regardless - but perhaps<br>the real-worl=
d bandwidth cost can be reduced by, say, waiting for a wifi<br>connection r=
ather than using cellular data=2E<br></pre></blockquote></div></body></html=
>
------LMBZD6S3EPYT4XDAMO6O7H54MYPNXC--
|
