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
327
328
329
330
331
332
333
334
335
336
337
338
339
340
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5E3CDCD6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Jan 2017 21:50:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com
[209.85.192.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4E7DC128
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Jan 2017 21:50:50 +0000 (UTC)
Received: by mail-pf0-f178.google.com with SMTP id d2so96341101pfd.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 06 Jan 2017 13:50:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=from:content-transfer-encoding:mime-version:date:subject:message-id
:references:in-reply-to:to;
bh=UE0U6eVZoBo5MCDkG8RBU1K/q7seqyPBemJwlWncgnI=;
b=tOeOOOI2GCZEh66liQM/1PH/8bGR24jeFInsOmVNcB0vZ7ErBvoNEU0uKD0bt+TxKn
kHVeSMUdIJj2QiCrRSZtOkEmcqju7Egwk4fStpknLbmXsAhXSAxXxxhgReOvB/YXnb4r
Sytn8laf32Zyd3EPs7cZdkjIgyDoFC5ClnFHSC9nrtSiRykJlEeyvlNDtqlIEGrMVVko
zp7dGMp7E40+0BaNhOphXO3tHNWckJXlfQZWEnRGBFN7mpHw0aQjZV7DzmbkC8YBfCaV
qkmihyx84Z/dh7I23zl7G+gUlSUUHmTdOYqLO6W4bKvfU6wwhwmwQ9XZgcksl9KGAqGd
EVgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:content-transfer-encoding:mime-version:date
:subject:message-id:references:in-reply-to:to;
bh=UE0U6eVZoBo5MCDkG8RBU1K/q7seqyPBemJwlWncgnI=;
b=UCLpPy2H0kZGUFedH9fiU2KyaZrg4LILiU07ZjQrrt13jodYwAzY5k76Wgyzb0dECw
KTt9dVzxNCUJsXHEh6MUNzG+O7nGMI4684XlfnSb8tCQSze0CC+YlQq+jKy86HJSWh2C
RN2z31jHDazdm23YJXcBI9goUkf9fqHrStJJiIVFsVd481RRf7Ycn4d1H9e9DU6hNQF4
TL/7WlrbA1GKa3KybZW9fjpEj7aeAjPBCCQe5Snzbl0maGXgQ4wJO7FPPPybzCjvRR7B
ta72F625qDCjoOK//g9W/Te0mxdK79QvmLjYWFFJ1A07tR3H2chs1OoW85/0C1PLLIwc
XCaA==
X-Gm-Message-State: AIkVDXLMVxLi+v+OvFQ/+CdoFDqZpNWMk24i6ia1SY5PQ4BVyknKadwvqKbwrI0hXvRKUQ==
X-Received: by 10.84.139.67 with SMTP id 61mr168351901plq.65.1483739449762;
Fri, 06 Jan 2017 13:50:49 -0800 (PST)
Received: from [10.137.30.220] (mobile-166-176-185-107.mycingular.net.
[166.176.185.107]) by smtp.gmail.com with ESMTPSA id
p1sm163549617pgc.29.2017.01.06.13.50.48
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 06 Jan 2017 13:50:49 -0800 (PST)
From: Eric Voskuil <eric@voskuil.org>
Content-Type: multipart/alternative;
boundary=Apple-Mail-910A3C60-751C-4686-BADD-E1F66026B893
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Fri, 6 Jan 2017 13:50:47 -0800
Message-Id: <7DCE5EE8-0489-4563-A4B9-8C72773FA801@voskuil.org>
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>
<CAAcC9ysdaK1DqBBRvBM=7uHFnM7WW23R61v68xrAMj3rWJfqdg@mail.gmail.com>
<347a0909-affd-da0c-f7f8-09fa76bcb279@voskuil.org>
<CAAcC9ysioO0wZMWxQF1wAzjB7qUyx_6MSbmd-4sh3UtfieVb4Q@mail.gmail.com>
<CAH+Axy7-Vox0F9EsotiXqCAhs7NGNsHPvnjEEvcx+6Ft+GBHKg@mail.gmail.com>
In-Reply-To: <CAH+Axy7-Vox0F9EsotiXqCAhs7NGNsHPvnjEEvcx+6Ft+GBHKg@mail.gmail.com>
To: James MacWhyte <macwhyte@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPhone Mail (14C92)
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, MIME_QP_LONG_LINE,
RCVD_IN_DNSWL_NONE 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, 06 Jan 2017 21:53:12 +0000
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: Fri, 06 Jan 2017 21:50:52 -0000
--Apple-Mail-910A3C60-751C-4686-BADD-E1F66026B893
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
It is a useful aspect of discussion at this level as it helps higher lever d=
evelopers understand the actual tradeoffs. Clearly some do not. The market w=
ill eventually sort them out, but the discussion both gives developers the n=
ecessary information.
It also helps core development prioritize resources. I personally would not p=
rioritize core work to facilitate zero conf. I would even spend time to disc=
ourage it, as others have done.
I think the cautions in this thread about doing privacy and system security d=
amaging things (like checking mining pools for zero conf transactions) will p=
revent some wasted time, which benefits everyone.
e
> On Jan 6, 2017, at 1:35 PM, James MacWhyte via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:
>=20
> It's my opinion that the purpose of this list and bitcoin protocol develop=
ment in general is to build the base functionality that other companies and i=
ndividuals require to provide usability to the end-user. The 0-conf debate i=
s a UX issue. If end users shouldn't rely on 0-conf, it is up to wallet deve=
lopers to hide 0-conf transactions or mark them appropriately. Instead of us=
ing this list to debate what wallet designers should or shouldn't do, we sho=
uld just provide the tools and "let the market sort it out". If wallet devel=
opers start getting inundated with complaints that 0-conf transactions are c=
ausing confusion and loss, they will find a solution. If the tools they requ=
ire for the solution don't exist, they will come to this list to request act=
ion.
>=20
> Am I wrong?
>=20
> On Fri, Jan 6, 2017 at 12:16 PM Chris Priest via bitcoin-dev <bitcoin-dev@=
lists.linuxfoundation.org> wrote:
>> Its a method for determining the probability that a valid tx will be
>> mined in a block before that tx actually gets mined, which is useful
>> when accepting payments in situations when you can't wait for the full
>> confirmation. No one is saying all tx validation should be performed
>> by querying miners mempools, that's ridiculous. Obviously once the tx
>> gets it's first confirmation, you go back to determining validity the
>> way you always have. There is no "security catastrophe".
>>=20
>> Even if you're running a full node, you can't know for certain that
>> any given tx will make it into a future block. You can't be certain
>> the future miner who finally does mine that tx will mine your TXID or
>> another TXID that spends the same inputs to another address (a double
>> spend). The only way to actually know for certain is to query every
>> single large hashpower mempool.
>>=20
>> On 1/4/17, Eric Voskuil <eric@voskuil.org> wrote:
>> > On 01/04/2017 11:06 PM, Chris Priest via bitcoin-dev wrote:
>> >> On 1/3/17, Jonas Schnelli via bitcoin-dev
>> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>>
>> >>> There are plenty, more sane options. If you can't run your own full-n=
ode
>> >>> as a merchant (trivial), maybe co-use a wallet-service with centraliz=
ed
>> >>> verification (maybe use two of them), I guess Copay would be one of
>> >>> those wallets (as an example). Use them in watch-only mode.
>> >>
>> >> The best way is to connect to the mempool of each miner and check to
>> >> see if they have your txid in their mempool.
>> >>
>> >> https://www.antpool.com/api/is_in_mempool?txid=3D334847bb...
>> >> https://www.f2pool.com/api/is_in_mempool?txid=3D334847bb...
>> >> https://bw.com/api/is_in_mempool?txid=3D334847bb...
>> >> https://bitfury.com/api/is_in_mempool?txid=3D334847bb...
>> >> https://btcc.com/api/is_in_mempool?txid=3D334847bb...
>> >>
>> >> If each of these services return "True", and you know those services
>> >> so not engage in RBF, then you can assume with great confidence that
>> >> your transaction will be in the next block, or in a block very soon.
>> >> If any one of those services return "False", then you must assume that=
>> >> it is possible that there is a double spend floating around, and that
>> >> you should wait to see if that tx gets confirmed. The problem is that
>> >> not every pool runs such a service to check the contents of their
>> >> mempool...
>> >>
>> >> This is an example of mining centralization increasing the security of=
>> >> zero confirm.
>> >
>> > A world connected up to a few web services to determine payment validit=
y
>> > is an example of a bitcoin security catastrophe.
>> >
>> > e
>> >
>> >
>> _______________________________________________
>> 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
--Apple-Mail-910A3C60-751C-4686-BADD-E1F66026B893
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div></div><div>It is a useful aspect of di=
scussion at this level as it helps higher lever developers understand the ac=
tual tradeoffs. Clearly some do not. The market will eventually sort them ou=
t, but the discussion both gives developers the necessary information.</div>=
<div><br></div><div>It also helps core development prioritize resources. I p=
ersonally would not prioritize core work to facilitate zero conf. I would ev=
en spend time to discourage it, as others have done.</div><div><br></div><di=
v>I think the cautions in this thread about doing privacy and system securit=
y damaging things (like checking mining pools for zero conf transactions) wi=
ll prevent some wasted time, which benefits everyone.</div><div><br></div><d=
iv>e</div><div><br>On Jan 6, 2017, at 1:35 PM, James MacWhyte via bitcoin-de=
v <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a>> wrote:<br><br></div><blockquote type=3D"cit=
e"><div><div dir=3D"ltr">It's my opinion that the purpose of this list and b=
itcoin protocol development in general is to build the base functionality th=
at other companies and individuals require to provide usability to the end-u=
ser. The 0-conf debate is a UX issue. If end users shouldn't rely on 0-conf,=
it is up to wallet developers to hide 0-conf transactions or mark them appr=
opriately. Instead of using this list to debate what wallet designers should=
or shouldn't do, we should just provide the tools and "let the market sort i=
t out". If wallet developers start getting inundated with complaints that 0-=
conf transactions are causing confusion and loss, they will find a solution.=
If the tools they require for the solution don't exist, they will come to t=
his list to request action.<div><br></div><div>Am I wrong?</div><div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Jan 6, 2017 at 12:16 PM Chr=
is Priest via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">Its a method for determining the probability that=
a valid tx will be<br class=3D"gmail_msg">
mined in a block before that tx actually gets mined, which is useful<br clas=
s=3D"gmail_msg">
when accepting payments in situations when you can't wait for the full<br cl=
ass=3D"gmail_msg">
confirmation. No one is saying all tx validation should be performed<br clas=
s=3D"gmail_msg">
by querying miners mempools, that's ridiculous. Obviously once the tx<br cla=
ss=3D"gmail_msg">
gets it's first confirmation, you go back to determining validity the<br cla=
ss=3D"gmail_msg">
way you always have. There is no "security catastrophe".<br class=3D"gmail_m=
sg">
<br class=3D"gmail_msg">
Even if you're running a full node, you can't know for certain that<br class=
=3D"gmail_msg">
any given tx will make it into a future block. You can't be certain<br class=
=3D"gmail_msg">
the future miner who finally does mine that tx will mine your TXID or<br cla=
ss=3D"gmail_msg">
another TXID that spends the same inputs to another address (a double<br cla=
ss=3D"gmail_msg">
spend). The only way to actually know for certain is to query every<br class=
=3D"gmail_msg">
single large hashpower mempool.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
On 1/4/17, Eric Voskuil <<a href=3D"mailto:eric@voskuil.org" class=3D"gma=
il_msg" target=3D"_blank">eric@voskuil.org</a>> wrote:<br class=3D"gmail_=
msg">
> On 01/04/2017 11:06 PM, Chris Priest via bitcoin-dev wrote:<br class=3D=
"gmail_msg">
>> On 1/3/17, Jonas Schnelli via bitcoin-dev<br class=3D"gmail_msg">
>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D=
"gmail_msg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> w=
rote:<br class=3D"gmail_msg">
>>><br class=3D"gmail_msg">
>>> There are plenty, more sane options. If you can't run your own f=
ull-node<br class=3D"gmail_msg">
>>> as a merchant (trivial), maybe co-use a wallet-service with cen=
tralized<br class=3D"gmail_msg">
>>> verification (maybe use two of them), I guess Copay would be on=
e of<br class=3D"gmail_msg">
>>> those wallets (as an example). Use them in watch-only mode.<br c=
lass=3D"gmail_msg">
>><br class=3D"gmail_msg">
>> The best way is to connect to the mempool of each miner and check t=
o<br class=3D"gmail_msg">
>> see if they have your txid in their mempool.<br class=3D"gmail_msg"=
>
>><br class=3D"gmail_msg">
>> <a href=3D"https://www.antpool.com/api/is_in_mempool?txid=3D334847b=
b." rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://www.ant=
pool.com/api/is_in_mempool?txid=3D334847bb.</a>..<br class=3D"gmail_msg">
>> <a href=3D"https://www.f2pool.com/api/is_in_mempool?txid=3D334847bb=
." rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://www.f2po=
ol.com/api/is_in_mempool?txid=3D334847bb.</a>..<br class=3D"gmail_msg">
>> <a href=3D"https://bw.com/api/is_in_mempool?txid=3D334847bb." rel=3D=
"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://bw.com/api/is_in_=
mempool?txid=3D334847bb.</a>..<br class=3D"gmail_msg">
>> <a href=3D"https://bitfury.com/api/is_in_mempool?txid=3D334847bb." r=
el=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://bitfury.com/=
api/is_in_mempool?txid=3D334847bb.</a>..<br class=3D"gmail_msg">
>> <a href=3D"https://btcc.com/api/is_in_mempool?txid=3D334847bb." rel=
=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://btcc.com/api/i=
s_in_mempool?txid=3D334847bb.</a>..<br class=3D"gmail_msg">
>><br class=3D"gmail_msg">
>> If each of these services return "True", and you know those service=
s<br class=3D"gmail_msg">
>> so not engage in RBF, then you can assume with great confidence tha=
t<br class=3D"gmail_msg">
>> your transaction will be in the next block, or in a block very soon=
.<br class=3D"gmail_msg">
>> If any one of those services return "False", then you must assume t=
hat<br class=3D"gmail_msg">
>> it is possible that there is a double spend floating around, and th=
at<br class=3D"gmail_msg">
>> you should wait to see if that tx gets confirmed. The problem is th=
at<br class=3D"gmail_msg">
>> not every pool runs such a service to check the contents of their<b=
r class=3D"gmail_msg">
>> mempool...<br class=3D"gmail_msg">
>><br class=3D"gmail_msg">
>> This is an example of mining centralization increasing the security=
of<br class=3D"gmail_msg">
>> zero confirm.<br class=3D"gmail_msg">
><br class=3D"gmail_msg">
> A world connected up to a few web services to determine payment validit=
y<br class=3D"gmail_msg">
> is an example of a bitcoin security catastrophe.<br class=3D"gmail_msg"=
>
><br class=3D"gmail_msg">
> e<br class=3D"gmail_msg">
><br class=3D"gmail_msg">
><br class=3D"gmail_msg">
_______________________________________________<br class=3D"gmail_msg">
bitcoin-dev mailing list<br class=3D"gmail_msg">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg"=
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"gma=
il_msg">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://lists.linuxf=
oundation.org/mailman/listinfo/bitcoin-dev</a><br class=3D"gmail_msg">
</blockquote></div></div></div>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></=
html>=
--Apple-Mail-910A3C60-751C-4686-BADD-E1F66026B893--
|
