summaryrefslogtreecommitdiff
path: root/df/49f0c3ad35f7c03740cdda2a51765b822b2b49
blob: 3dd237b2fb2016021bce1bcda3679a14acb72f27 (plain)
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
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
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 0143E722
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  9 Jun 2017 03:50:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com
	[209.85.161.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 032F5A6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  9 Jun 2017 03:50:48 +0000 (UTC)
Received: by mail-yw0-f179.google.com with SMTP id 63so18015984ywr.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 08 Jun 2017 20:50:48 -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; 
	bh=YIj+feVYejOCzGqJc0XLcZ/WS+iYs6SQhl5FtsbZebk=;
	b=KC4IOzffOHeDWs+7ezwDfTWiSVxlIgjUs0jrYzdUbik/ozG+DGUhHSDH+1bMOB8XCs
	BkrE9/FsjoDReEL7jnxAJnm32hK6223OYohmQN++nRd5ZWAgBcvYmYjxuj8/QUTjlW+O
	O7t4npIUM4aiopJt1nnKzvftcz6kCvKwWzMJLoKD0ijJMTfQFn81LgRLawCOTS59Fwkp
	CN4kUs18dVUeFsyAhVCnX6lySrqQleH2U3oZC8nomWE6xrOtm/2hogCKlHfwld29X9m7
	j+2iJ+4pHmU1lWDPzjDac9g4aghOKnVajTJZ98V1MuEXAQTdeav17ZpIiywTdA7iYEhC
	B/hQ==
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;
	bh=YIj+feVYejOCzGqJc0XLcZ/WS+iYs6SQhl5FtsbZebk=;
	b=LjWjVaUMYeHuny5QQEXAmigMpLQ25orJ4NTRowags9jXHAM8pjq7oj7DNluRDifDIM
	8exIPGLCLbhFpaWrp4fbKAbTUktUf69PvCoazeS3LXRe7IWTaJLBjrd+HkKg5GEi/WaP
	vtrtYj0NlYwZdVL729qeSsSEvJ5xf+wWIUIaGgs9H7JvoZ9Yo0Uyv21IkfrISJxm/Aoa
	OCkwFSOiovaJLELbHEiXMHMQrXlaSlNoX1Ix3v9i8xISS5wAswV8KwQ1Fo/rmGv2UUTW
	g3+Z1+rbB5JfrfuEQ6q/LjaXQTCt4kwX5c4mLV5LG2HpjmfUlBBcOm5gVMA/I/ncZ3vg
	xRAg==
X-Gm-Message-State: AODbwcClwdLzxiBaN6X9pwzrdmPtEzql67FJGv/JpvKDXR10QNgyo54E
	8INgVfUewo71hxUiTM3AekkGKtVE5Ss8
X-Received: by 10.129.88.138 with SMTP id m132mr13838303ywb.22.1496980248199; 
	Thu, 08 Jun 2017 20:50:48 -0700 (PDT)
MIME-Version: 1.0
References: <CAO3Pvs8ccTkgrecJG6KFbBW+9moHF-FTU+4qNfayeE3hM9uRrg@mail.gmail.com>
	<1496915408.1583369.1002689000.641E8EAB@webmail.messagingengine.com>
In-Reply-To: <1496915408.1583369.1002689000.641E8EAB@webmail.messagingengine.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Fri, 09 Jun 2017 03:50:37 +0000
Message-ID: <CAO3Pvs_0r1xOL9JMSXf7taG-vFcOanPEh7d4nuQKEPSNLZ6kXQ@mail.gmail.com>
To: Tomas <tomas@tomasvdw.nl>, bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="001a114925f0ee095305517edfeb"
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 Proposal: Compact Client Side Filtering 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, 09 Jun 2017 03:50:50 -0000

--001a114925f0ee095305517edfeb
Content-Type: text/plain; charset="UTF-8"

Tomas wrote:
> A rough estimate would indicate this to be about 2-2.5x as big per block
> as your proposal, but comes with rather different security
> characteristics, and would not require download since genesis.

Our proposal _doesnt_ require downloading from genesis, if by
"downloading" you mean downloading all the blocks. Clients only need to
sync the block+filter headers, then (if they don't care about historical
blocks), will download filters from their "birthday" onwards.

> The client could verify the TXIDs against the merkle root with a much
> stronger (PoW) guarantee compared to the guarantee based on the assumption
> of peers being distinct, which your proposal seems to make

Our proposal only makes a "one honest peer" assumption, which is the same
as any other operating mode. Also as client still download all the
headers, they're able to verify PoW conformance/work as normal.

> I don't completely understand the benefit of making the outpoints and
> pubkey hashes (weakly) verifiable. These only serve as notifications and
> therefore do not seem to introduce an attack vector.

Not sure what you mean by this. Care to elaborate?

> I think client-side filtering is definitely an important route to take,
> but is it worth compressing away the information to verify the merkle
> root?

That's not the case with our proposal. Clients get the _entire_ block (if
they need it), so they can verify the merkle root as normal. Unless one of
us is misinterpreting the other here.

-- Laolu


On Thu, Jun 8, 2017 at 6:34 AM Tomas via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Jun 1, 2017, at 21:01, Olaoluwa Osuntokun via bitcoin-dev wrote:
>
> Hi y'all,
>
> Alex Akselrod and I would like to propose a new light client BIP for
> consideration:
>    *
> https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki
>
>
>
> Very interesting.
>
> I would like to consider how this compares to another light client type
> with rather different security characteristics where each client would
> receive for each transaction in each block,
>
> * The TXID (uncompressed)
> * The spent outpoints (with TXIDs compressed)
> * The pubkey hash (compressed to reasonable amount of false positives)
>
> A rough estimate would indicate this to be about 2-2.5x as big per block
> as your proposal, but comes with rather different security characteristics,
> and would not require download since genesis.
>
> The client could verify the TXIDs against the merkle root with a much
> stronger (PoW) guarantee compared to the guarantee based on the assumption
> of peers being distinct, which your proposal seems to make. Like your
> proposal this removes the privacy and processing  issues from server-side
> filtering, but unlike your proposal retrieval of all txids in each block
> can also serve for a basis of fraud proofs and (disprovable) fraud hints,
> without resorting to full block downloads.
>
> I don't completely understand the benefit of making the outpoints and
> pubkey hashes (weakly) verifiable. These only serve as notifications and
> therefore do not seem to introduce an attack vector. Omitting data is
> always possible, so receiving data is a prerequisite for verification, not
> an assumption that can be made.  How could an attacker benefit from "hiding
> notifications"?
>
> I think client-side filtering is definitely an important route to take,
> but is it worth compressing away the information to verify the merkle root?
>
> Regards,
> Tomas van der Wansem
> bitcrust
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a114925f0ee095305517edfeb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Tomas wrote:</div><div>&gt; A rough estimate would in=
dicate this to be about 2-2.5x as big per block</div><div>&gt; as your prop=
osal, but comes with rather different security</div><div>&gt; characteristi=
cs, and would not require download since genesis.=C2=A0</div><div><br></div=
><div>Our proposal _doesnt_ require downloading from genesis, if by</div><d=
iv>&quot;downloading&quot; you mean downloading all the blocks. Clients onl=
y need to</div><div>sync the block+filter headers, then (if they don&#39;t =
care about historical</div><div>blocks), will download filters from their &=
quot;birthday&quot; onwards.</div><div><br></div><div>&gt; The client could=
 verify the TXIDs against the merkle root with a much</div><div>&gt; strong=
er (PoW) guarantee compared to the guarantee based on the assumption</div><=
div>&gt; of peers being distinct, which your proposal seems to make</div><d=
iv><br></div><div>Our proposal only makes a &quot;one honest peer&quot; ass=
umption, which is the same</div><div>as any other operating mode. Also as c=
lient still download all the</div><div>headers, they&#39;re able to verify =
PoW conformance/work as normal.</div><div><br></div><div>&gt; I don&#39;t c=
ompletely understand the benefit of making the outpoints and</div><div>&gt;=
 pubkey hashes (weakly) verifiable. These only serve as notifications and</=
div><div>&gt; therefore do not seem to introduce an attack vector.</div><di=
v><br></div><div>Not sure what you mean by this. Care to elaborate?=C2=A0</=
div><div><br></div><div>&gt; I think client-side filtering is definitely an=
 important route to take,</div><div>&gt; but is it worth compressing away t=
he information to verify the merkle</div><div>&gt; root?</div><div><br></di=
v><div>That&#39;s not the case with our proposal. Clients get the _entire_ =
block (if</div><div>they need it), so they can verify the merkle root as no=
rmal. Unless one of</div><div>us is misinterpreting the other here.</div><d=
iv><br></div><div>-- Laolu</div><div><br></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr">On Thu, Jun 8, 2017 at 6:34 AM Tomas via bitcoin-dev &l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@list=
s.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div><div>On Thu, Jun 1, 2017, at 21:01, Olaoluwa Osuntokun via bitcoin-d=
ev wrote:<br></div>
<blockquote type=3D"cite"><div dir=3D"ltr"><div>Hi y&#39;all,=C2=A0<br></di=
v>
<div><br></div>
<div>Alex Akselrod and I would like to propose a new light client BIP for<b=
r></div>
<div>consideration:=C2=A0<br></div>
<div>=C2=A0 =C2=A0* <a href=3D"https://github.com/Roasbeef/bips/blob/master=
/gcs_light_client.mediawiki" target=3D"_blank">https://github.com/Roasbeef/=
bips/blob/master/gcs_light_client.mediawiki</a><br></div>
<div><br></div>
<div><br></div>
</div>
</blockquote><div><br></div>
</div><div><div>Very interesting. <br></div>
<div><br></div>
<div>I would like to consider how this compares to another light client typ=
e with rather different security characteristics where each client would re=
ceive for each transaction in each block, <br></div>
<div><br></div>
<div>* The TXID (uncompressed)<br></div>
<div>* The spent outpoints (with TXIDs compressed)<br></div>
<div>* The pubkey hash (compressed to reasonable amount of false positives)=
<br></div>
<div><br></div>
<div>A rough estimate would indicate this to be about 2-2.5x as big per blo=
ck as your proposal, but comes with rather different security characteristi=
cs, and would not require download since genesis. <br></div>
<div><br></div>
<div>The client could verify the TXIDs against the merkle root with a much =
stronger (PoW) guarantee compared to the guarantee based on the assumption =
of peers being distinct, which your proposal seems to make. Like your propo=
sal this removes the privacy and processing=C2=A0 issues from server-side f=
iltering, but unlike your proposal retrieval of all txids in each block can=
 also serve for a basis of  fraud proofs and (disprovable) fraud hints, wit=
hout resorting to full block downloads.<br></div>
<div><br></div>
<div>I don&#39;t completely understand the benefit of making the outpoints =
and pubkey hashes (weakly) verifiable. These only serve as notifications an=
d therefore do not seem to introduce an attack vector. Omitting data is alw=
ays possible, so receiving data is a prerequisite for verification, not an =
assumption that can be made.=C2=A0 How could an attacker benefit from &quot=
;hiding notifications&quot;?<br></div>
<div><br></div>
<div>I think client-side filtering is definitely an important route to take=
, but is it worth compressing away the information to verify the merkle roo=
t?<br></div>
<div><br></div>
<div>Regards,<br></div>
<div>Tomas van der Wansem<br></div>
<div>bitcrust<br></div>
<div><br></div>
</div>

_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--001a114925f0ee095305517edfeb--