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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <idigix@gmail.com>) id 1WwZ2n-0007bM-Vw
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 15:42:02 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.45 as permitted sender)
client-ip=209.85.213.45; envelope-from=idigix@gmail.com;
helo=mail-yh0-f45.google.com;
Received: from mail-yh0-f45.google.com ([209.85.213.45])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WwZ2m-0001XE-60
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jun 2014 15:42:01 +0000
Received: by mail-yh0-f45.google.com with SMTP id t59so4404573yho.18
for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Jun 2014 08:41:54 -0700 (PDT)
X-Received: by 10.236.185.105 with SMTP id t69mr34610713yhm.94.1402933314375;
Mon, 16 Jun 2014 08:41:54 -0700 (PDT)
MIME-Version: 1.0
Sender: idigix@gmail.com
Received: by 10.170.151.10 with HTTP; Mon, 16 Jun 2014 08:41:34 -0700 (PDT)
In-Reply-To: <CAFDyEXgKpbE4WGAqROJ4J1UST=tXWgfn7uKhRO_tngJfVK_Czw@mail.gmail.com>
References: <CAKrJrGOBSiY5V59eko6g796j3wh9V9ZLjPbyHeS5=zyX6j3Wdw@mail.gmail.com>
<CANEZrP0Euc1mPhRc9e41tU4zMDrWesvVyiBpAPq6M3m7K=aU=A@mail.gmail.com>
<CAFDyEXgKpbE4WGAqROJ4J1UST=tXWgfn7uKhRO_tngJfVK_Czw@mail.gmail.com>
From: Paul Goldstein <paul@realfoot.com>
Date: Mon, 16 Jun 2014 11:41:34 -0400
X-Google-Sender-Auth: V-X5i-im04J6iWGKWvQd6dr-tPM
Message-ID: <CADE3-jA8LizD8cjdqKm0pFc8OV7JqPBGhs4uvp6=VhEU2emV6w@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=20cf305e25a3d8d66b04fbf5dd6f
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(idigix[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WwZ2m-0001XE-60
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] instant confirmation via payment protocol
backwards compatible proto buffer extension
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 16 Jun 2014 15:42:02 -0000
--20cf305e25a3d8d66b04fbf5dd6f
Content-Type: text/plain; charset=UTF-8
Mike Hearn, why don't we just have all nodes report attempted double spends
through the node network. No need to involve the miners at all really, or
do your suggestion but also report the double spend attempt. By waiting
maybe 10-60 seconds (instead of 10 minutes for first conf), merchants can
be more sure that a double spend attack was not tried. Attacker would have
to hold back second tx by 10-60 seconds and hope that that second tx (with
higher fee) get's into a solved block before the first one. This forced
delay time ought to make the attack less successful (but not impossible).
Paul G.
On Mon, Jun 16, 2014 at 11:09 AM, Daniel Rice <drice@greenmangosystems.com>
wrote:
> If you're hoping the instant providers list won't need to scale then
> you're essentially saying that we need a solution to the double spend
> problem. That is a good point. Double spends are one of the biggest issues
> remaining in the protocol. I've seen so many people talk about bad
> experiences trying to spend Bitcoin at a restaurant and waiting an hour for
> confirmations. This entire BIP extension is a band aid for double spends.
> If double spends are not resolved, there will be a million instant
> providers in the long run and if double spends are resolved then this BIP
> extension is completely unnecessary. Is solving doublespends off the table?
>
> What if we solved doublespends like this: If a node receives 2
> transactions that use the same input, they can put both of them into the
> new block as a proof of double spend, but the bitcoins are not sent to the
> outputs of either transactions. They are instead treated like a fee and
> given to the block solver node. This gives miners the needed incentive and
> tools to end doublespends instead of being forced to favor one transaction
> over the other.
>
> I will write up a BIP if this seems like a practical approach.
>
>
> On Mon, Jun 16, 2014 at 5:19 AM, Mike Hearn <mike@plan99.net> wrote:
>
>> Looking good! I think this is much better than the original draft. Agree
>> with Andreas that supports_instant is simply equal to
>> (supported_instant_providers.size() > 1) which makes it redundant.
>>
>> Daniel is right that putting every possible provider in the Payment
>> message might not scale in a world where there are huge numbers of
>> instant-confirmation providers, but I'm hoping that we never have to scale
>> to that size, because if we did that'd rather imply that Bitcoin has become
>> useless for in-person payments without trusted third parties and avoiding
>> that is rather the whole point of the project :) So I'm OK with some
>> theoretical lack of scalability for now.
>>
>> A more scalable approach would be for the user to send the name and
>> signature of their "instant provider" every time and the merchant just
>> chooses whether to ignore it or not, but as Lawrence points out, this is
>> incompatible with the provider charging extra fees for "instantness". But
>> should we care? I'm trying to imagine what the purchasing experience is
>> like with optional paid-for third party anti-double-spend protection.
>> Ultimately it's the merchant who cares about this, not me, so why would I
>> ever pay? It makes no sense for me to pay for double spend protection for
>> the merchant: after all, I'm honest. This is why it doesn't make sense for
>> me to pay miners fees either, it's the *receiver* who cares about
>> confirmations, not the sender.
>>
>> So I wonder if a smarter design is that the user always submits the
>> details of their instantness provider and we just don't allow for optional
>> selection of instantness. I'm not sure that works, UX wise, so is having a
>> less scalable design to support it worthwhile?
>>
>>
>> ------------------------------------------------------------------------------
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--20cf305e25a3d8d66b04fbf5dd6f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Mike Hearn, why don't we just have all nodes report at=
tempted double spends through the node network. No need to involve the mine=
rs at all really, or do your suggestion but also report the double spend at=
tempt. By waiting maybe 10-60 seconds (instead of 10 minutes for first conf=
), merchants can be more sure that a double spend attack was not tried. Att=
acker would have to hold back second tx by 10-60 seconds and hope that that=
second tx (with higher fee) get's into a solved block before the first=
one. This forced delay time ought to make the attack less successful (but =
not impossible).<div>
<br></div><div>Paul G.<br><div><br></div><div><div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Mon, Jun 16, 2014 at 11:09 AM, Daniel =
Rice <span dir=3D"ltr"><<a href=3D"mailto:drice@greenmangosystems.com" t=
arget=3D"_blank">drice@greenmangosystems.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>If you're hoping t=
he instant providers list won't need to scale then you're essential=
ly saying that we need a solution to the double spend problem. That is a go=
od point. Double spends are one of the biggest issues remaining in the prot=
ocol. I've seen so many people talk about bad experiences trying to spe=
nd Bitcoin at a restaurant and waiting an hour for confirmations. This enti=
re BIP extension is a band aid for double spends. If double spends are not =
resolved, there will be a million instant providers in the long run and if =
double spends are resolved then this BIP extension is completely unnecessar=
y. Is solving doublespends off the table?</div>
<div><br></div><div>What if we solved doublespends like this: If a node rec=
eives 2 transactions that use the same input, they can put both of them int=
o the new block as a proof of double spend, but the bitcoins are not sent t=
o the outputs of either transactions. They are instead treated like a fee a=
nd given to the block solver node. This gives miners the needed incentive a=
nd tools to end doublespends instead of being forced to favor one transacti=
on over the other.</div>
<div><br></div><div>I will write up a BIP if this seems like a practical ap=
proach.</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_q=
uote">On Mon, Jun 16, 2014 at 5:19 AM, Mike Hearn <span dir=3D"ltr"><<a =
href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
Looking good! I think this is much better than the original draft. Agree wi=
th Andreas that supports_instant is simply equal to (supported_instant_prov=
iders.size() > 1) which makes it redundant.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Daniel is r=
ight that putting every possible provider in the Payment message might not =
scale in a world where there are huge numbers of instant-confirmation provi=
ders, but I'm hoping that we never have to scale to that size, because =
if we did that'd rather imply that Bitcoin has become useless for in-pe=
rson payments without trusted third parties and avoiding that is rather the=
whole point of the project :) So I'm OK with some theoretical lack of =
scalability for now. </div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">A more scal=
able approach would be for the user to send the name and signature of their=
"instant provider" every time and the merchant just chooses whet=
her to ignore it or not, but as Lawrence points out, this is incompatible w=
ith the provider charging extra fees for "instantness". But shoul=
d we care? I'm trying to imagine what the purchasing experience is like=
with optional paid-for third party anti-double-spend protection. Ultimatel=
y it's the merchant who cares about this, not me, so why would I ever p=
ay? It makes no sense for me to pay for double spend protection for the mer=
chant: after all, I'm honest. This is why it doesn't make sense for=
me to pay miners fees either, it's the <i>receiver</i>=C2=A0who cares =
about confirmations, not the sender.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">So I wonder=
if a smarter design is that the user always submits the details of their i=
nstantness provider and we just don't allow for optional selection of i=
nstantness. I'm not sure that works, UX wise, so is having a less scala=
ble design to support it worthwhile?</div>
</div>
<br>-----------------------------------------------------------------------=
-------<br>
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions<b=
r>
Find What Matters Most in Your Big Data with HPCC Systems<br>
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.<br>
Leverages Graph Analysis for Fast Processing & Easy Data Exploration<br=
>
<a href=3D"http://p.sf.net/sfu/hpccsystems" target=3D"_blank">http://p.sf.n=
et/sfu/hpccsystems</a><br>_______________________________________________<b=
r>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
<br>-----------------------------------------------------------------------=
-------<br>
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions<b=
r>
Find What Matters Most in Your Big Data with HPCC Systems<br>
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.<br>
Leverages Graph Analysis for Fast Processing & Easy Data Exploration<br=
>
<a href=3D"http://p.sf.net/sfu/hpccsystems" target=3D"_blank">http://p.sf.n=
et/sfu/hpccsystems</a><br>_______________________________________________<b=
r>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div></div></div></div>
--20cf305e25a3d8d66b04fbf5dd6f--
|
