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
|
Return-Path: <blueadept@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A0324BF4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Jun 2017 03:35:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com
[209.85.216.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 152AD252
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Jun 2017 03:35:31 +0000 (UTC)
Received: by mail-qt0-f179.google.com with SMTP id w1so23979922qtg.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 01 Jun 2017 20:35:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to; bh=8WTDX28dh0IJ/IOzVnkR9VLSujK10vXT1218fHRJVpc=;
b=QsKmXEXBBftX7vH8hnoeIAl7g9IYObqcayZdfaukFDIlUdz2zs6whqlb3Jo06Laizw
Jm25Z3Vvah3sGolG4RfbwePKq8aLTOZd3Z3r+3QXE53otOCNQHDNOKVdsYcRtN63dBRx
Zll6ZEw0F8/QLMtiuiHx9IVUuQgk9Lcpt735TpB752tu365i6M/Ee40+pLHciO9nzFdc
3f/7yZXUt4gJVtynNHVF6/zkTI/70F32v2vYrxcynFPf6Nms/3O+1JN4J+H22O5ybrnn
i8y+YQaiiCOKNXHeGTeIQatEW8ljjDqmDiCvDTo3zW0/vIuWBQDW58WkfmeuvklDGg5R
FUZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to;
bh=8WTDX28dh0IJ/IOzVnkR9VLSujK10vXT1218fHRJVpc=;
b=d7qxtEfIuxiAm6vMGLv47212X7eN24cvDet1TUZhnw5cLQjDWfF1c3XtoTLHEGOqY2
lujrfTGRoQDGTNwH5AuTNPLuIzOxzazr8oMV+w0H44qltXGx5WyLDHdQcrmzwkOHY4zW
u9csXbdvYRpa36z6d8FuoO9/h1Txv3hyBZypWk2KH5MPS48qo8Dgr/WqxIzdkPkbVijI
gNX/IR/bMU4WJk35GWffhA463FLknuLDRKMoQAvdUkWcVzvmKlNDhXC4SqieWwXxvnXc
qgkrmhF1m06lVCwP7QEZydrOCF14moa44CZhr7onoLGTmlhP/54AMoBXeEY9USBfQ6TB
Byuw==
X-Gm-Message-State: AODbwcCLt7pSworQYtgG/Y7lx9uxmQUC/3pu+u2qRmK7I1/IqG7tLill
i6KkpnfHEhp/iKzbBtVZLN7+yNrk7zDe
X-Received: by 10.237.35.132 with SMTP id j4mr6139381qtc.215.1496374530027;
Thu, 01 Jun 2017 20:35:30 -0700 (PDT)
MIME-Version: 1.0
Sender: blueadept@gmail.com
Received: by 10.12.144.139 with HTTP; Thu, 1 Jun 2017 20:35:29 -0700 (PDT)
In-Reply-To: <CAAS2fgQv14qPV5d1xFjjxpoo4gj4pG1fBKLZs95vJFYa42zC9g@mail.gmail.com>
References: <CAO3Pvs8ccTkgrecJG6KFbBW+9moHF-FTU+4qNfayeE3hM9uRrg@mail.gmail.com>
<B445007A-9FA3-4B1D-8CD0-F0371602DC5F@mattcorallo.com>
<CAO3Pvs-q89HDb9a9xtYMBm8RNtaQH1d+5B6S1YPk3C0JWM+vzA@mail.gmail.com>
<73a6d59a-7e79-5d48-40cd-5c6f59abc122@gmail.com>
<CAAS2fgQv14qPV5d1xFjjxpoo4gj4pG1fBKLZs95vJFYa42zC9g@mail.gmail.com>
From: Alex Akselrod <alex@akselrod.org>
Date: Thu, 1 Jun 2017 23:35:29 -0400
X-Google-Sender-Auth: a8iGzX83N4PEUqAzU2m1n2MPMhs
Message-ID: <CAE0pnxKD5+rE4aW86C-azrppnk5SaoEXBnwoJjh0mqQPzFSspQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113c1adc5034950550f1d8ca"
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM 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: Fri, 02 Jun 2017 03:46:02 +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: Fri, 02 Jun 2017 03:35:31 -0000
--001a113c1adc5034950550f1d8ca
Content-Type: text/plain; charset="UTF-8"
I agree with Greg and Laolu; BIP-37 filtering for transactions is no better
than for blocks and completely destroys privacy.
A constant stream of transactions is OK, but even cheaper for light clients
would be Laolu's proposal of streaming more tx data than existing inv
messages but less than existing tx messages.
We could make a bit field of things to include in every inv-with-metadata
message, such as:
- witness data
- scriptSig data pushes
- scriptPubKey
- hash of scriptPubKey (unnecessary if full scriptPubKey is sent)
- scriptPubKey data pushes
- etc.
This way a full node might be able to tell what application (or type of
application) a light client is running, but not the client's addresses or
outputs, except maybe when the client originates transactions.
On Thu, Jun 1, 2017 at 10:28 PM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Fri, Jun 2, 2017 at 2:15 AM, Chris via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > On 06/01/2017 06:10 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:
> >
> >> One aspect which isn't in this BIP draft is direct support for
> unconfirmed
> >> transactions. I consider such a feature an important UX feature for
> mobile
> >> phones, and something which I've personally seen as an important
> >> UX-experience when on-boarding new users to Bitcoin.
> >
> > Totally agree. My first thought is maybe you could keep bip37 filtering
> > as optional for unconfirmed transactions. Since you're only interested
>
> Really bad for privacy. Data for transactions at the tip is only
> 14kb/s-- potentially less if segwit is in use and you're not getting
> witnesses. Is that really that burdensome?
>
> FWIW, leaving a mobile browser just running while pointed at some
> websites seems to use more traffic than that just loading advertising.
> :)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113c1adc5034950550f1d8ca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I agree with Greg and Laolu; BIP-37 filtering for tra=
nsactions is no better than for blocks and completely destroys privacy.<br>=
<br>A constant stream of transactions is OK, but even cheaper for light cli=
ents would be Laolu's proposal of streaming more tx data than existing =
inv messages but less than existing tx messages.<br><br>We could make a bit=
field of things to include in every inv-with-metadata message, such as:<br=
>- witness data<br>- scriptSig data pushes<br>- scriptPubKey<br>- hash of s=
criptPubKey (unnecessary if full scriptPubKey is sent)<br>- scriptPubKey da=
ta pushes<br></div><div><div>- etc.<br><br>This way a full node might be ab=
le to tell what application (or type of application) a light client is runn=
ing, but not the client's addresses or outputs, except maybe when the c=
lient originates transactions.<br></div></div></div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote">On Thu, Jun 1, 2017 at 10:28 PM, Gregory=
Maxwell via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfound=
ation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"">On Fri, Jun 2, 2017 at 2:15 AM, Chris via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>> wrote:<br>
> On 06/01/2017 06:10 PM, Olaoluwa Osuntokun via bitcoin-dev wrote:<br>
><br>
>> One aspect which isn't in this BIP draft is direct support for=
unconfirmed<br>
>> transactions. I consider such a feature an important UX feature fo=
r mobile<br>
>> phones, and something which I've personally seen as an importa=
nt<br>
>> UX-experience when on-boarding new users to Bitcoin.<br>
><br>
> Totally agree. My first thought is maybe you could keep bip37 filterin=
g<br>
> as optional for unconfirmed transactions. Since you're only intere=
sted<br>
<br>
</span>Really bad for privacy. Data for transactions at the tip is only<br>
14kb/s-- potentially less if segwit is in use and you're not getting<br=
>
witnesses. Is that really that burdensome?<br>
<br>
FWIW, leaving a mobile browser just running while pointed at some<br>
websites seems to use more traffic than that just loading advertising.<br>
:)<br>
<div class=3D"HOEnZb"><div class=3D"h5">______________________________<wbr>=
_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>
--001a113c1adc5034950550f1d8ca--
|
