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
|
Return-Path: <tomas@tomasvdw.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A3E2088A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Jun 2017 09:50:10 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
[66.111.4.25])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9CFA412A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Jun 2017 09:50:09 +0000 (UTC)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
by mailout.nyi.internal (Postfix) with ESMTP id DB99E20AD6
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 8 Jun 2017 05:50:08 -0400 (EDT)
Received: from web3 ([10.202.2.213])
by compute2.internal (MEProxy); Thu, 08 Jun 2017 05:50:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=KH81OJ
IZ9R90xMfaakBc6/OJuhcU4xjAc/9FSFVlP1U=; b=ql+Y//QII64XFlZWWjyIZ8
Q62Ho+iGuKGQs2kLKhBhmb0F/X5WCBBp4hMpVbbRhoFmPg6KxOdcNpKcXcxqIbyo
eMSFzAP59L9Lk8vrdLYbNTaqQa56zDhs8Ta2NeU45c7jorQe2rpkZ1NCsrSG9dp5
lY+u9jVi/7zxtdU8xqL3QmtCfxbRpDQuWFmCzI9lZsNtcxEuxZs9Lo7Aowg4OVDn
MDO2uCHewOWkpGmXOYCkcqtpUfWCuHR5LvuCWE9HPUZ7/KWg+FYZrYWFPPMM0ty7
q6Mu9DzuUAaRf5RHZlXm64/Fuea+cKJy2bcIxI0UHI4Nbunczbt+M6qekPcZ19Og
==
X-ME-Sender: <xms:0B05WXRMX8IJjAoNlpswBasPCa4EeaoOeWg-YFMgY19BvQgW8wtQ5A>
Received: by mailuser.nyi.internal (Postfix, from userid 99)
id B76029ED8F; Thu, 8 Jun 2017 05:50:08 -0400 (EDT)
Message-Id: <1496915408.1583369.1002689000.641E8EAB@webmail.messagingengine.com>
From: Tomas <tomas@tomasvdw.nl>
To: bitcoin-dev@lists.linuxfoundation.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_149691540815833692"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-72fcb609
In-Reply-To: <CAO3Pvs8ccTkgrecJG6KFbBW+9moHF-FTU+4qNfayeE3hM9uRrg@mail.gmail.com>
References: <CAO3Pvs8ccTkgrecJG6KFbBW+9moHF-FTU+4qNfayeE3hM9uRrg@mail.gmail.com>
Date: Thu, 08 Jun 2017 11:50:08 +0200
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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, 08 Jun 2017 13:31:41 +0000
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: Thu, 08 Jun 2017 09:50:10 -0000
This is a multi-part message in MIME format.
--_----------=_149691540815833692
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
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
--_----------=_149691540815833692
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="utf-8"
<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Thu, Jun 1, 2017, at 21:01, Olaoluwa Osuntokun via bitcoin-dev wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div>Hi y'all, <br></div>
<div><br></div>
<div>Alex Akselrod and I would like to propose a new light client BIP for<br></div>
<div>consideration: <br></div>
<div> * <a href="https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki">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>Very interesting. <br></div>
<div><br></div>
<div>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, <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 block as your proposal, but comes with rather different security characteristics, 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 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.<br></div>
<div><br></div>
<div>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"?<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 root?<br></div>
<div><br></div>
<div>Regards,<br></div>
<div>Tomas van der Wansem<br></div>
<div>bitcrust<br></div>
<div><br></div>
</body>
</html>
--_----------=_149691540815833692--
|
