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
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E4E2540D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 4 Jan 2017 10:13:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com
[209.85.213.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D1DFDD5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 4 Jan 2017 10:13:04 +0000 (UTC)
Received: by mail-vk0-f45.google.com with SMTP id p9so284955157vkd.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 04 Jan 2017 02:13:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=Bfo+TzN5JWJaA4/S9OB5oJ6r/hDb05c/SPdhJ5OqTws=;
b=oQbPk9VFKtCq9wA8eZGmY3HFYJSofgteRwuJKcSscwi3b5ZQpuU4E64DQL8SJzoYmH
ru5aZNC5KFQVFgvD3rbkhStrLxTvEjNHNb1BU2t2m62REsjaekXRT/WK6cL8IgU6n3Yz
ehzvldVfB9KGmFNW9mmiBqmWE649E76r1alfVFaijWjFCUSeWBebUoE1gEnQe9ekGQLE
R1rR6m7XHWJg0WubEZmtwarNRh2E409nxMoQtUiB1DSIZxkmfzGMd7ZNn2GAMqcwBALE
HMf8eNG358xckQt816bNqHlZ2cXJofVH9m0H2awEeLnpe4vSWHBIFt0GafozAIhUQrbP
WDjQ==
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=Bfo+TzN5JWJaA4/S9OB5oJ6r/hDb05c/SPdhJ5OqTws=;
b=GRs7FeeM7dUh7TJZiLAaNUH7ZnU9e2fqJojQfwq/yXPhQ4guFO59ZHsA3qXM4PRu2V
3MfOQBAB3qGnKNdowW2bYrHkrCalZpsJ2ijm6ErKtNNC9IuWs4/buPfmX668+z1Ibyfc
/9aW5lIYICZ0P3Rmv8jGjzVqUYwyDHswVCLDw55Blr6Z+3hJsZJDgSmdqrfSqMX93nE2
B+alFOELZ8iU2kBVgHCGE5wHdNq7LxPfUuUcfmrhl7z6aJ4xbxMm17O9jAEkQ2akWJDz
QOsZ4DMwqASc6alh7iGS0R1oBx4TC/FwbzqfFei/KMSwKf2pIfMWIReJ5fE00mVCtCZP
ECcA==
X-Gm-Message-State: AIkVDXLJWcQ8OKMfEIsiXQmeKAT3GzlGDJ04TvRa9oIO1em+KodZ/Xb0hkJ+06XnHk4ffOdVJqfewsMR10vczQ==
X-Received: by 10.31.139.12 with SMTP id n12mr18967703vkd.100.1483524783923;
Wed, 04 Jan 2017 02:13:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.216.130 with HTTP; Wed, 4 Jan 2017 02:13:02 -0800 (PST)
Received: by 10.31.216.130 with HTTP; Wed, 4 Jan 2017 02:13:02 -0800 (PST)
In-Reply-To: <CACq0ZD7xdYVaBGs-xCjN2RFKcF5q_RNA1nRmjgU-k2x9VotY_Q@mail.gmail.com>
References: <71d822e413ac457a530e1c367811cc24@cock.lu>
<77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch>
<74aeb4760316b59a3db56c0d16d11f28@cock.lu>
<CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com>
<f335731c-3928-6694-5ed8-aa1999b401f1@jonasschnelli.ch>
<CACq0ZD7xdYVaBGs-xCjN2RFKcF5q_RNA1nRmjgU-k2x9VotY_Q@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Wed, 4 Jan 2017 11:13:02 +0100
Message-ID: <CABm2gDoT72nioQf9d+XFRAaJydWQqtWZ+WSQO99Dpn7HcTkfpw@mail.gmail.com>
To: Aaron Voisine <voisine@gmail.com>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11437e56c2f61405454207bb
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM 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] 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: Wed, 04 Jan 2017 10:13:06 -0000
--001a11437e56c2f61405454207bb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
There were talks about implementing spv mode for bitcoin core without using
bloom filters. Less efficient because it downloads full blocks, but better
for privacy. Perhaps other spv implementations should consider doing the
same instead of committing the filters in the block?
Now I feel I was missing something. I guess you can download the whole
block you're interested in instead of only your txs and that gives you
privacy.
But how do you get to know which blocks are you interested in?
If the questions are too basic or offtopic for the thread, I'm happy
getting answers privately (but then maybe I get them more than once).
On 4 Jan 2017 09:57, "Aaron Voisine via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
It's easy enough to mark a transaction as "pending". People with bank
accounts are familiar with the concept.
Although the risk of accepting gossip information from multiple random
peers, in the case where the sender does not control the receivers network
is still minimal. Random node operators have no incentive to send fake
transactions, and would need to control all the nodes a client connects to,
and find a non-false-positive address belonging to the victims wallet.
It's not impossible, but it's non trivial, would only temporarily show a
pending transaction, and provide no benefit to the node operator. There are
much juicier targets for an attacker with the ability to sybil attack the
entire bitcoin p2p network.
Aaron
On Tue, Jan 3, 2017 at 11:47 PM Jonas Schnelli <dev@jonasschnelli.ch> wrote=
:
> Hi
>
>
>
> > 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.
>
> >
>
> I agree that unconfirmed transactions are incredibly important, but not
>
> over SPV against random peers.
>
>
>
> If you offer users/merchants a feature (SPV 0-conf against random
>
> peers), that is fundamentally insecure, it will =E2=80=93 sooner or later=
=E2=80=93 lead
>
> to some large scale fiasco, hurting Bitcoins reputation and trust from
>
> merchants.
>
>
>
> Merchants using and trusting 0-conf SPV transactions (retrieved from
>
> random peers) is something we should **really eliminate** through
>
> education and by offering different solution.
>
>
>
> There are plenty, more sane options. If you can't run your own full-node
>
> as a merchant (trivial), maybe co-use a wallet-service with centralized
>
> verification (maybe use two of them), I guess Copay would be one of
>
> those wallets (as an example). Use them in watch-only mode.
>
>
>
> For end-users SPV software, I think it would be recommended to...
>
> ... disable unconfirmed transactions during SPV against random peers
>
> ... enable unconfirmed transactions when using SPV against a trusted
>
> peer with preshared keys after BIP150
>
> ... if unconfirmed transactions are disabled, show how it can be enabled
>
> (how to run a full-node [in a box, etc.])
>
> ... educate, inform users that a transaction with no confirmation can be
>
> "stopped" or "redirected" any time, also inform about the risks during
>
> low-conf phase (1-5).
>
>
>
> I though see the point that it's nice to make use of the "incoming
>
> funds..." feature in SPV wallets. But =E2=80=93 for the sake of stability=
and
>
> (risk-)scaling =E2=80=93 we may want to recommend to scarify this feature=
and =E2=80=93
>
> in the same turn =E2=80=93 to use privacy-preserving BFD's.
>
>
>
> </jonas>
>
>
>
>
>
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--001a11437e56c2f61405454207bb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div>There were talks about implementing spv mode for bit=
coin core without using bloom filters. Less efficient because it downloads =
full blocks, but better for privacy. Perhaps other spv implementations shou=
ld consider doing the same instead of committing the filters in the block?<=
div dir=3D"auto"><br></div><div dir=3D"auto">Now I feel I was missing somet=
hing. I guess you can download the whole block you're interested in ins=
tead of only your txs and that gives you privacy.</div><div dir=3D"auto">Bu=
t how do you get to know which blocks are you interested in?</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">If the questions are too basic or off=
topic for the thread, I'm happy getting answers privately =C2=A0(but th=
en maybe I get them more than once).</div><br><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">On 4 Jan 2017 09:57, "Aaron Voisine via b=
itcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attribut=
ion"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex"><div>It's easy enough to mark a transacti=
on as "pending". People with bank accounts are familiar with the =
concept.</div><div><br></div><div>Although the risk of accepting gossip inf=
ormation from multiple random peers, in the case where the sender does not =
control the receivers network is still minimal. Random node operators have =
no incentive to send fake transactions, and would need to control all the n=
odes a client connects to, and find a non-false-positive address belonging =
to the victims wallet.=C2=A0</div><div><br></div><div>It's not impossib=
le, but it's non trivial, would only temporarily show a pending transac=
tion, and provide no benefit to the node operator. There are much juicier t=
argets for an attacker with the ability to sybil attack the entire bitcoin =
p2p network.</div><div><br></div><div>Aaron</div><div class=3D"elided-text"=
><div><br><div class=3D"gmail_quote"><div>On Tue, Jan 3, 2017 at 11:47 PM J=
onas Schnelli <<a href=3D"mailto:dev@jonasschnelli.ch" target=3D"_blank"=
>dev@jonasschnelli.ch</a>> wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">Hi<br class=3D"m_-3928766434464138131gmail_msg"><br><br class=3D"m_-39287=
66434464138131gmail_msg"><br>> Unconfirmed transactions are incredibly i=
mportant for real world use.<br class=3D"m_-3928766434464138131gmail_msg"><=
br>> Merchants for instance are willing to accept credit card payments o=
f<br class=3D"m_-3928766434464138131gmail_msg"><br>> thousands of dollar=
s and ship the goods despite the fact that the<br class=3D"m_-3928766434464=
138131gmail_msg"><br>> transaction can be reversed up to 60 days later. =
There is a very large<br class=3D"m_-3928766434464138131gmail_msg"><br>>=
cost to losing the ability to have instant transactions in many or<br clas=
s=3D"m_-3928766434464138131gmail_msg"><br>> even most situations. This c=
ost is typically well above the fraud risk.<br class=3D"m_-3928766434464138=
131gmail_msg"><br>><br class=3D"m_-3928766434464138131gmail_msg"><br>>=
; It's important to recognize that bitcoin serves a wide variety of use=
<br class=3D"m_-3928766434464138131gmail_msg"><br>> cases with different=
profiles for time sensitivity and fraud risk.<br class=3D"m_-3928766434464=
138131gmail_msg"><br>><br class=3D"m_-3928766434464138131gmail_msg"><br>=
I agree that unconfirmed transactions are incredibly important, but not<br =
class=3D"m_-3928766434464138131gmail_msg"><br>over SPV against random peers=
.<br class=3D"m_-3928766434464138131gmail_msg"><br><br class=3D"m_-39287664=
34464138131gmail_msg"><br>If you offer users/merchants a feature (SPV 0-con=
f against random<br class=3D"m_-3928766434464138131gmail_msg"><br>peers), t=
hat is fundamentally insecure, it will =E2=80=93 sooner or later =E2=80=93 =
lead<br class=3D"m_-3928766434464138131gmail_msg"><br>to some large scale f=
iasco, hurting Bitcoins reputation and trust from<br class=3D"m_-3928766434=
464138131gmail_msg"><br>merchants.<br class=3D"m_-3928766434464138131gmail_=
msg"><br><br class=3D"m_-3928766434464138131gmail_msg"><br>Merchants using =
and trusting 0-conf SPV transactions (retrieved from<br class=3D"m_-3928766=
434464138131gmail_msg"><br>random peers) is something we should **really el=
iminate** through<br class=3D"m_-3928766434464138131gmail_msg"><br>educatio=
n and by offering different solution.<br class=3D"m_-3928766434464138131gma=
il_msg"><br><br class=3D"m_-3928766434464138131gmail_msg"><br>There are ple=
nty, more sane options. If you can't run your own full-node<br class=3D=
"m_-3928766434464138131gmail_msg"><br>as a merchant (trivial), maybe co-use=
a wallet-service with centralized<br class=3D"m_-3928766434464138131gmail_=
msg"><br>verification (maybe use two of them), I guess Copay would be one o=
f<br class=3D"m_-3928766434464138131gmail_msg"><br>those wallets (as an exa=
mple). Use them in watch-only mode.<br class=3D"m_-3928766434464138131gmail=
_msg"><br><br class=3D"m_-3928766434464138131gmail_msg"><br>For end-users S=
PV software, I think it would be recommended to...<br class=3D"m_-392876643=
4464138131gmail_msg"><br>... disable unconfirmed transactions during SPV ag=
ainst random peers<br class=3D"m_-3928766434464138131gmail_msg"><br>... ena=
ble unconfirmed transactions when using SPV against a trusted<br class=3D"m=
_-3928766434464138131gmail_msg"><br>peer with preshared keys after BIP150<b=
r class=3D"m_-3928766434464138131gmail_msg"><br>... if unconfirmed transact=
ions are disabled, show how it can be enabled<br class=3D"m_-39287664344641=
38131gmail_msg"><br>(how to run a full-node [in a box, etc.])<br class=3D"m=
_-3928766434464138131gmail_msg"><br>... educate, inform users that a transa=
ction with no confirmation can be<br class=3D"m_-3928766434464138131gmail_m=
sg"><br>"stopped" or "redirected" any time, also inform=
about the risks during<br class=3D"m_-3928766434464138131gmail_msg"><br>lo=
w-conf phase (1-5).<br class=3D"m_-3928766434464138131gmail_msg"><br><br cl=
ass=3D"m_-3928766434464138131gmail_msg"><br>I though see the point that it&=
#39;s nice to make use of the "incoming<br class=3D"m_-392876643446413=
8131gmail_msg"><br>funds..." feature in SPV wallets. But =E2=80=93 for=
the sake of stability and<br class=3D"m_-3928766434464138131gmail_msg"><br=
>(risk-)scaling =E2=80=93 we may want to recommend to scarify this feature =
and =E2=80=93<br class=3D"m_-3928766434464138131gmail_msg"><br>in the same =
turn =E2=80=93 to use privacy-preserving BFD's.<br class=3D"m_-39287664=
34464138131gmail_msg"><br><br class=3D"m_-3928766434464138131gmail_msg"><br=
></jonas><br class=3D"m_-3928766434464138131gmail_msg"><br><br class=
=3D"m_-3928766434464138131gmail_msg"><br><br class=3D"m_-392876643446413813=
1gmail_msg"><br></blockquote></div></div>
</div><br>______________________________<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>
<br></blockquote></div><br></div></div></div>
--001a11437e56c2f61405454207bb--
|
