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
|
Return-Path: <voisine@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 247D76C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Jan 2017 22:18:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com
[209.85.220.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 618531B4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Jan 2017 22:18:33 +0000 (UTC)
Received: by mail-qk0-f172.google.com with SMTP id h201so250188943qke.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 03 Jan 2017 14:18:33 -0800 (PST)
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=RxxFojpz+iwPZ7LZ+lzktXY59eBkRdkzapFJ+XEdQQ0=;
b=F1vHn+QLrWN/CJtWNmGpZUx1Jqb8aX+b4IwdUfaTD9C2u3k/XesSid2whte4B0a8/Z
FxvS/60/0l9g5EvUsZpYDrU1tGUtzXY4et4yLygNIydTFNmFWpxJqZkZiap+nHl7xvab
wRDi/80pAxTe27amkKmJANuhw19mPDRr60rybGYMSId7qtCVqHlnsPAWWmNdzE2tmqXm
7qK4yZbhGbE55EOqmDzAprorh5rq6hq/NmazGZZMsRWDu8ECdgmrRpH9z41sNbOcGESz
iRSkC2txq6L0YlJQcLrP5qrgBTrcFBENmKMxLzG+KvVB8qnjNCaQYYMXidZz9jzgGMvJ
JjAg==
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=RxxFojpz+iwPZ7LZ+lzktXY59eBkRdkzapFJ+XEdQQ0=;
b=rVjOt7NaXslAW87sJs6nSc+uXWdq408kFWsYWwyxOLKNCGxga8tPg39SQ6+cXNqLs3
QVuoUhHxRatKOiV/SOgAr3x3eJ6tYRADJuef2xBjilHA+gVrRIHJsVgzI7sXA4H6d5/2
moG6EFTiabISRLen9nL3LlzEQCD8rJ7jE7sVuT4j8VYFXroXEHGxwTr3dnrnjP8ya/kT
r2pRFTRhH43OI2LArzOAi313SPtFsJQvRoUXQzXcgmR3fqKiOAEi7gGI5twHeZblz6ER
CKQoHDqr0gXEu14mGMzQfr6aiULnVD212eIu1mYij2vMuGq8heuCdyovrGiTrxUM+A+g
740g==
X-Gm-Message-State: AIkVDXL4HDzS4eFaeCKVGySlpp/XjtRdHDdOxFtMqcMIQ3vlhqvRaQKbx7EImshYSZ+YmyAY1/FpE3AavZcS8A==
X-Received: by 10.55.44.193 with SMTP id s184mr68561262qkh.278.1483481912511;
Tue, 03 Jan 2017 14:18:32 -0800 (PST)
MIME-Version: 1.0
References: <71d822e413ac457a530e1c367811cc24@cock.lu>
<77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch>
<74aeb4760316b59a3db56c0d16d11f28@cock.lu>
In-Reply-To: <74aeb4760316b59a3db56c0d16d11f28@cock.lu>
From: Aaron Voisine <voisine@gmail.com>
Date: Tue, 03 Jan 2017 22:18:21 +0000
Message-ID: <CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Jonas Schnelli <dev@jonasschnelli.ch>, bfd@cock.lu
Content-Type: multipart/alternative; boundary=001a114f4d9a6d128e0545380ccb
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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
Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet
performance and SPV security
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: Tue, 03 Jan 2017 22:18:34 -0000
--001a114f4d9a6d128e0545380ccb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Unconfirmed transactions are incredibly important for real world use.
Merchants for instance are willing to accept credit card payments of
thousands of dollars and ship the goods despite the fact that the
transaction can be reversed up to 60 days later. There is a very large cost
to losing the ability to have instant transactions in many or even most
situations. This cost is typically well above the fraud risk.
It's important to recognize that bitcoin serves a wide variety of use cases
with different profiles for time sensitivity and fraud risk.
Aaron
On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> The concept combined with the weak blocks system where miners commit
>
> to potential transaction inclusion with fractional difficulty blocks
>
> is possible. I'm not personally convinced that unconfirmed transaction
>
> display in a wallet is worth the privacy trade-off. The user has very
>
> little to gain from this knowledge until the txn is in a block.
>
>
>
>
>
> On 2017-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote:
>
> > Hi
>
> >> We introduce several concepts that rework the lightweight Bitcoin
>
> >> client model in a manner which is secure, efficient and privacy
>
> >> compatible.
>
> >>
>
> >> The BFD can be used verbatim in replacement of BIP37, where the filter
>
> >> can be cached between clients without needing to be recomputed. It can
>
> >> also be used by normal pruned nodes to do re-scans locally of their
>
> >> wallet without needing to have the block data available to scan, or
>
> >> without reading the entire block chain from disk.
>
> > I started exploring the potential of BFD after this specification.
>
> >
>
> > What would be the preferred/recommended way to handle 0-conf/mempool
>
> > filtering =E2=80=93 if & once BDF would have been deployed (any type,
>
> > semi-trusted oracles or protocol-level/softfork)?
>
> >
>
> > From the user-experience perspective, this is probably pretty important
>
> > (otherwise the experience will be that incoming funds can take serval
>
> > minutes to hours until they appear).
>
> > Using BIP37 bloom filters just for mempool filtering would obviously
>
> > result in the same unwanted privacy-setup.
>
> >
>
> > </jonas>
>
> >
>
> >
>
> > _______________________________________________
>
> > bitcoin-dev mailing list
>
> > bitcoin-dev@lists.linuxfoundation.org
>
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
>
> bitcoin-dev mailing list
>
> bitcoin-dev@lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a114f4d9a6d128e0545380ccb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div>Unconfirmed transactions are incredibly important for real world use. =
Merchants for instance are willing to accept credit card payments of thousa=
nds of dollars and ship the goods despite the fact that the transaction can=
be reversed up to 60 days later. There is a very large cost to losing the =
ability to have instant transactions in many or even most situations. This =
cost is typically well above the fraud risk.=C2=A0</div><div><br></div><div=
>It's important to recognize that bitcoin serves a wide variety of use =
cases with different profiles for time sensitivity and fraud risk.</div><di=
v><br></div><div>Aaron</div><div><br><div class=3D"gmail_quote"><div>On Tue=
, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev <<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a=
>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The concept combined w=
ith the weak blocks system where miners commit<br class=3D"gmail_msg"><br>t=
o potential transaction inclusion with fractional difficulty blocks<br clas=
s=3D"gmail_msg"><br>is possible. I'm not personally convinced that unco=
nfirmed transaction<br class=3D"gmail_msg"><br>display in a wallet is worth=
the privacy trade-off. The user has very<br class=3D"gmail_msg"><br>little=
to gain from this knowledge until the txn is in a block.<br class=3D"gmail=
_msg"><br><br class=3D"gmail_msg"><br><br class=3D"gmail_msg"><br>On 2017-0=
1-01 13:01, Jonas Schnelli via bitcoin-dev wrote:<br class=3D"gmail_msg"><b=
r>> Hi<br class=3D"gmail_msg"><br>>> We introduce several concepts=
that rework the lightweight Bitcoin<br class=3D"gmail_msg"><br>>> cl=
ient model in a manner which is secure, efficient and privacy<br class=3D"g=
mail_msg"><br>>> compatible.<br class=3D"gmail_msg"><br>>><br c=
lass=3D"gmail_msg"><br>>> The BFD can be used verbatim in replacement=
of BIP37, where the filter<br class=3D"gmail_msg"><br>>> can be cach=
ed between clients without needing to be recomputed. It can<br class=3D"gma=
il_msg"><br>>> also be used by normal pruned nodes to do re-scans loc=
ally of their<br class=3D"gmail_msg"><br>>> wallet without needing to=
have the block data available to scan, or<br class=3D"gmail_msg"><br>>&=
gt; without reading the entire block chain from disk.<br class=3D"gmail_msg=
"><br>> I started exploring the potential of BFD after this specificatio=
n.<br class=3D"gmail_msg"><br>><br class=3D"gmail_msg"><br>> What wou=
ld be the preferred/recommended way to handle 0-conf/mempool<br class=3D"gm=
ail_msg"><br>> filtering =E2=80=93 if & once BDF would have been dep=
loyed (any type,<br class=3D"gmail_msg"><br>> semi-trusted oracles or pr=
otocol-level/softfork)?<br class=3D"gmail_msg"><br>><br class=3D"gmail_m=
sg"><br>> From the user-experience perspective, this is probably pretty =
important<br class=3D"gmail_msg"><br>> (otherwise the experience will be=
that incoming funds can take serval<br class=3D"gmail_msg"><br>> minute=
s to hours until they appear).<br class=3D"gmail_msg"><br>> Using BIP37 =
bloom filters just for mempool filtering would obviously<br class=3D"gmail_=
msg"><br>> result in the same unwanted privacy-setup.<br class=3D"gmail_=
msg"><br>><br class=3D"gmail_msg"><br>> </jonas><br class=3D"gm=
ail_msg"><br>><br class=3D"gmail_msg"><br>><br class=3D"gmail_msg"><b=
r>> _______________________________________________<br class=3D"gmail_ms=
g"><br>> bitcoin-dev mailing list<br class=3D"gmail_msg"><br>> <a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"gmail_m=
sg"><br>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/=
bitcoin-dev" rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https=
://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br class=3D"g=
mail_msg"><br>_______________________________________________<br class=3D"g=
mail_msg"><br>bitcoin-dev mailing list<br class=3D"gmail_msg"><br><a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"gmail_ms=
g"><br><a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoi=
n-dev" rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://lis=
ts.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br class=3D"gmail_m=
sg"><br></blockquote></div></div>
--001a114f4d9a6d128e0545380ccb--
|
