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
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
Return-Path: <jim.posen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6A60936
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 May 2018 20:19:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com
[209.85.220.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E4B7D6A3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 May 2018 20:19:18 +0000 (UTC)
Received: by mail-qk0-f169.google.com with SMTP id d125-v6so4694925qkb.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 17 May 2018 13:19:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=iv0TCaZzIjDfZrH2PPp5F8EAAEPXWd3j602StFfqCvk=;
b=PZncOYop8c1e6OZzSCvD11ikYr8xUoLECBnRRnq7/E/lPXBzSizkqVNY4ED4kIQe3h
nRvkaXuHbAxYFVJntE+nxY3imnIislyDq3Efs4DAGC9fSNNYU8ooAk5kni1htbMNKKy0
agOcxsYz0Heeju1IMozERkcLET0ivroGjTKlIY58IK7L5DD6MAM43E3pW+plWoKkLN0W
8bqHNgSH4Bk7YYBthxxD3SpXn3PwAe68AtpmP2u2UTFDmGsQxFjcSQVbNgXIwpb/9/XR
/RIq1tPiPEU0ZHGCUYB7E1Hf0xW8IZk+n1J3IGCwwIC4FQd34z7uvIjaCSrq+Mt2hhCR
j03w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=iv0TCaZzIjDfZrH2PPp5F8EAAEPXWd3j602StFfqCvk=;
b=Z0IXrza2GiPk/XFDFWrJwNrEaKlnFtNeV0VadCrwaKI6EYMqjKsfYpbnQRzTYCnvlu
xzeHBqfABNhtsL+BDraMZdmTje0U9z6hPLyCY6TU7BCQrwxzWd1W3D2bv7BuKbD1kw3x
8kTUEYp6NtXl0/raZVSKwhjjU8tZR05XUUbvlMj6P0RBE7KCXq37bZIa3M+ro3r79+Ew
haNT39rJAeONtJMjnbAL4iGaYoc0mwtOjQdssA6zDNojRwNuPrbTCXY3ltPR1MdSb75L
B44iKnLKxO3m2Itg+b5/s7TUeb9F0n+7N4GPCO9Kx3OEDCLQ04xfmajTfd4820iJDCUA
QrEQ==
X-Gm-Message-State: ALKqPwdIcWtzOTd+45mAk03fPTQA5GVQ/ZHQ89RN+o6n0T8tgcCcmzed
hToAySeobo9Hswq42SZH9hyXb+3M5zGvf7pncjM=
X-Google-Smtp-Source: AB8JxZp1DTUDl0PgSHzN0xAGBbBfP8qG4eHpSf/JnVrGlr81DZRkblnCanO5Wyia2c7hnrQbwhXBaS5tng6xXUv0p4k=
X-Received: by 2002:a37:2287:: with SMTP id
i129-v6mr6169195qki.209.1526588357955;
Thu, 17 May 2018 13:19:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.50.92 with HTTP; Thu, 17 May 2018 13:19:17 -0700 (PDT)
In-Reply-To: <CAAS2fgR3QRHeHEjjOS1ckEkL-h7=Na56G12hYW9Bmy9WEMduvg@mail.gmail.com>
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>
From: Jim Posen <jim.posen@gmail.com>
Date: Thu, 17 May 2018 13:19:17 -0700
Message-ID: <CADZtCShLmH_k-UssNWahUNHgHvWQQ1y638LwaOfnJEipwjbiYg@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cb58c4056c6c8c87"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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
X-Mailman-Approved-At: Thu, 17 May 2018 20:21:04 +0000
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 20:19:19 -0000
--000000000000cb58c4056c6c8c87
Content-Type: text/plain; charset="UTF-8"
>
> I think lite clients cross checking is something which very likely
> will never be implemented by anyone, and probably not stay working
> (due to under-usage) if it is implemented. This thought is driven by
> three things (1) the bandwidth overhead of performing the check, (2)
> thinking about the network-interacting-state-machine complexity of it,
> and by the multitude of sanity checks that lite clients already don't
> implement (e.g. when a lite client noticed a split tip it could ask
> peers for the respective blocks and check at least the stateless
> checks, but none has ever done that), and...
>
In my opinion, it's overly pessimistic to design the protocol in an
insecure way because some light clients historically have taken shortcuts.
If the protocol can provide clients the option of getting additional
security, it should.
On the general topic, Peter makes a good point that in many cases filtering
by txid of spending transaction may be preferable to filtering by outpoint
spend, which has the nice benefit that there are obviously fewer txs in a
block than txins. This wouldn't work for malleable transactions though.
I'm open to the idea of splitting the basic filter into three separate
filters based on data type, but there are some bandwidth concerns. First,
the GCS encoding gets better compression with a greater number of elements,
though as I recall in my analysis, that starts to tail off at ~1000
elements per filter with P=20, in which case it's not as much of a concern
given current block sizes. The other is that clients need to download
and/or store the filter header chain for each filter type, which are 32
bytes each per block. So if a client is expected to download all three
filter types anyway, or even two of three, it's less efficient in these
terms. It would be possible though to split the filters themselves, but
still have the basic filter header cover all three filters. This would mean
that full nodes could not support just a subset of the basic filters --
they'd have to compute all of them to compute the filter header.
--000000000000cb58c4056c6c8c87
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">I think lite clients cross checking is something=
which very likely<br>
will never be implemented by anyone, and probably not stay working<br>
(due to under-usage) if it is implemented.=C2=A0 This thought is driven by<=
br>
three things=C2=A0 (1) the bandwidth overhead of performing the check, (2)<=
br>
thinking about the network-interacting-state-<wbr>machine complexity of it,=
<br>
and by the multitude of sanity checks that lite clients already don't<b=
r>
implement (e.g. when a lite client noticed a split tip it could ask<br>
peers for the respective blocks and check at least the stateless<br>
checks, but none has ever done that), and...<br></blockquote><div><br></div=
><div><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-=
size:small;font-style:normal;font-variant-ligatures:normal;font-variant-cap=
s:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent=
:0px;text-transform:none;white-space:normal;word-spacing:0px;background-col=
or:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:ini=
tial;float:none;display:inline">In my opinion, it's overly pessimistic =
to design the protocol in an insecure way because some light clients histor=
ically have taken shortcuts. If the protocol can provide clients the option=
of getting additional security, it should.</span><br class=3D"gmail-Apple-=
interchange-newline">=C2=A0</div><div>On the general topic, Peter makes a g=
ood point that in many cases filtering by txid of spending transaction may =
be preferable to filtering by outpoint spend, which has the nice benefit th=
at there are obviously fewer txs in a block than txins. This wouldn't w=
ork for malleable transactions though.</div><div><br></div><div>I'm ope=
n to the idea of splitting the basic filter into three separate filters bas=
ed on data type, but there are some bandwidth concerns. First, the GCS enco=
ding gets better compression with a greater number of elements, though as I=
recall in my analysis, that starts to tail off at ~1000 elements per filte=
r with P=3D20, in which case it's not as much of a concern given curren=
t block sizes. The other is that clients need to download and/or store the =
filter header chain for each filter type, which are 32 bytes each per block=
. So if a client is expected to download all three filter types anyway, or =
even two of three, it's less efficient in these terms. It would be poss=
ible though to split the filters themselves, but still have the basic filte=
r header cover all three filters. This would mean that full nodes could not=
support just a subset of the basic filters -- they'd have to compute a=
ll of them to compute the filter header.</div></div></div></div>
--000000000000cb58c4056c6c8c87--
|
