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
|
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 BB4D76C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 May 2018 00:42:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com
[209.85.220.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 448D1177
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 23 May 2018 00:42:31 +0000 (UTC)
Received: by mail-qk0-f181.google.com with SMTP id 196-v6so2775742qke.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 22 May 2018 17:42:31 -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=ypfPtrFHMHD6Hl+Kh1Sm6vp4jBhCpGB5DTD16wvI8os=;
b=GklIX90u6WJlXoA4LCGfI8Gv/D4tanlZSQF/A5AXeaTIGZ+gdymQ2KeYq84yIb4S9X
3e5FBoaeKkYOzyNmuuYXsCLY/tqg1GLddc7ut2vodJ1HZjtu5M7jkC9BNCnHHqo0pJcS
M8mU0yuxRWSfAob660+lcY3taFxDr3IzuU7ZlGNoW+1Nl1JPI+OkmhL2cZC0syluEQks
PXx1NnVAERWMkNcXvV2MSBPGTuDkaUq53HuBB/+d2S3Q+1ol5zlYs0G2leBBKx8mTbeu
Nz54qGTy4UWliBEkjVxE0fCt9xyFSTLHfhtxdN6H4DpzQjdO6du7u6E8MFMFXyEsMLX0
wlmg==
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=ypfPtrFHMHD6Hl+Kh1Sm6vp4jBhCpGB5DTD16wvI8os=;
b=f3J1t6OFWrL6B0d4oLrUf7W+Wh8AM6OT4vFbWRJ0zj326W6kiCTNAhKht4EKSdwsMJ
STg5kCS30WkTnvVsEjuzXVz0L6WT0Q2KOjRrSy49cjGIjL9jmRnivVAHWIpR7CnXuspl
14Oy3LwwXejhYx06naxMokJ8M8CASPpELOQgQ7Hayvd1Q07gdoX64htpdfpvjFILnreG
oT21D0OZBIPrcEvNi0Qo1V6ko3UJQlzct5FdqoR42CA9xyPm7CuD1CmF5M0mf7hDsLby
Iwtz+MeOhgFxHHGVsOb7/3yrIzP0egOXvXZ1gM8MyNkuIf2lQRcbnpx7hLi+Qu0xhGFN
AfkQ==
X-Gm-Message-State: ALKqPweH/lA0bLG+jDGyxP9yf6DhjVpR+GqWj1emjs6oFvyVNVTDL3IG
EsTUX176tOoXvSQsR4FLaBhDZCvkWdNZWh9L+5A=
X-Google-Smtp-Source: AB8JxZrLOQQ4gzNI1q0cDIzDz+figHn0GiEMsgSDMCcvjHS/rH87mgR563UeJXzuOlobe4vmDGgRuwNrHv0JfzhQYUw=
X-Received: by 2002:a37:7e87:: with SMTP id
z129-v6mr613947qkc.298.1527036150271;
Tue, 22 May 2018 17:42:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:325c:0:0:0:0:0 with HTTP; Tue, 22 May 2018 17:42:29
-0700 (PDT)
In-Reply-To: <CAD3i26BibcaMdbQv-j+Egz_1y0GuhzepBp5ATNpj=Qv8hi1TVA@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>
<CADZtCShLmH_k-UssNWahUNHgHvWQQ1y638LwaOfnJEipwjbiYg@mail.gmail.com>
<CAAS2fgQLCN_cuZ-3QPjCLfYOtHfEk=SenTn5=y9LfGzJxLPR3Q@mail.gmail.com>
<CADZtCSjYr6VMBVQ=rx44SgRWcFSXhVXUZJB=rHMh4X78Z2eY1A@mail.gmail.com>
<CAO3Pvs9K3n=OzVQ06XGQvzNC+Aqp9S60kWM9VRPA8hWTJ3u9BQ@mail.gmail.com>
<c23a5346-9f99-44f0-abbf-d7e7979bf1d8@gmail.com>
<CAO3Pvs_MA4TtgCCu1NgCBjK2bZRN+rKnGQJN6m4yTrViBXRiPA@mail.gmail.com>
<CAD3i26BibcaMdbQv-j+Egz_1y0GuhzepBp5ATNpj=Qv8hi1TVA@mail.gmail.com>
From: Jim Posen <jim.posen@gmail.com>
Date: Tue, 22 May 2018 17:42:29 -0700
Message-ID: <CADZtCShAYpbN=4qNoX5c8yd1j08+mEZzG8gZwcHrj2suY0mb9w@mail.gmail.com>
To: =?UTF-8?Q?Johan_Tor=C3=A5s_Halseth?= <johanth@gmail.com>,
Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary="0000000000004bd413056cd4cf05"
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: Wed, 23 May 2018 01:09:54 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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: Wed, 23 May 2018 00:42:31 -0000
--0000000000004bd413056cd4cf05
Content-Type: text/plain; charset="UTF-8"
>
> My suggestion was to advertise a bitfield for each filter type the node
> serves,
> where the bitfield indicates what elements are part of the filters. This
> essentially
> removes the notion of decided filter types and instead leaves the decision
> to
> full-nodes.
>
I think it makes more sense to construct entirely separate filters for the
different types of elements and allow clients to download only the ones
they care about. If there are enough elements per filter, the compression
ratio shouldn't be much worse by splitting them up. This prevents the
exponential blowup in the number of filters that you mention, Johan, and it
works nicely with service bits for advertising different filter types
independently.
So if we created three separate filter types, one for output scripts, one
for input outpoints, and one for TXIDs, each signaled with a separate
service bit, are people good with that? Or do you think there shouldn't be
a TXID filter at all, Matt? I didn't include the option of a prev output
script filter or rolling that into the block output script filter because
it changes the security model (cannot be proven to be correct/incorrect
succinctly).
Then there's the question of whether to separate or combine the headers.
I'd lean towards keeping them separate because it's simpler that way.
--0000000000004bd413056cd4cf05
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"><div dir=3D"ltr"><div>My suggestion was to adver=
tise a bitfield for each filter type the node serves,<br></div><div>where t=
he bitfield indicates what elements are part of the filters. This essential=
ly</div><div>removes the notion of decided filter types and instead leaves =
the decision to=C2=A0</div><div>full-nodes.</div></div></blockquote><div><b=
r></div><div>I think it makes more sense to construct entirely separate fil=
ters for the different types of elements and allow clients to download only=
the ones they care about. If there are enough elements per filter, the com=
pression ratio shouldn't be much worse by splitting them up. This preve=
nts the exponential blowup in the number of filters that you mention, Johan=
, and it works nicely with service bits for advertising different filter ty=
pes independently.</div><div><br></div><div>So if we created three separate=
filter types, one for output scripts, one for input outpoints, and one for=
TXIDs, each signaled with a separate service bit, are people good with tha=
t? Or do you think there shouldn't be a TXID filter at all, Matt? I did=
n't include the option of a prev output script filter or rolling that i=
nto the block output script filter because it changes the security model (c=
annot be proven to be correct/incorrect succinctly).</div><div><br></div><d=
iv>Then there's the question of whether to separate or combine the head=
ers. I'd lean towards keeping them separate because it's simpler th=
at way.<br></div></div></div></div>
--0000000000004bd413056cd4cf05--
|
