summaryrefslogtreecommitdiff
path: root/ed/fd648bb197de82aa6ccf12cbd94db970e284ec
blob: a7c8e9237068f1ff3adc88980041ecfe540adcf7 (plain)
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
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mark@friedenbach.org>) id 1YPH5E-0007rA-Av
	for bitcoin-development@lists.sourceforge.net;
	Sat, 21 Feb 2015 20:55:28 +0000
X-ACL-Warn: 
Received: from mail-ig0-f177.google.com ([209.85.213.177])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YPH59-0003et-1z
	for bitcoin-development@lists.sourceforge.net;
	Sat, 21 Feb 2015 20:55:28 +0000
Received: by mail-ig0-f177.google.com with SMTP id z20so10518426igj.4
	for <bitcoin-development@lists.sourceforge.net>;
	Sat, 21 Feb 2015 12:55:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=GvKNnvrMOtblNc/pHXRf1PpWuGkQ+LbadezcVE1Q6p4=;
	b=lxgl2CowuaajPXwXVPKkenmIV7anM9gVbBkQhZ4BsDCmtIADBwLxnsYHVa1RxGqGAQ
	Um+7mwzaqvNUx6vqn4QSbSGmPbaS1XEMmxobp45hDyifkNbIjvgSuc4+WOuXSke8Y3Hf
	N0LcqECvqjv3gVYfKNxws1OBS/3w4FaUzOH9OnWEP6ilTXr+ANSnOgnAEzvqASBBQtxa
	WsUiStOOoewKw+tKIrSyxf9e8cCDLb5dVjs/0BPYbnVtPtd4FEXSQL6ioh++BZCAWFv0
	yltQiW4JDW5oclFtRckOE8xkxXCiOalS/1QBv75V+xy9GXKmkU2Vy2ArPJwAAan3s2e/
	t3Iw==
X-Gm-Message-State: ALoCoQkbj7WmbERc9FP0h8YAP0m1iKblVvxltbUOQTsaO0DO6zmgfFKCuJo74evdEIAolXv7TWC4
MIME-Version: 1.0
X-Received: by 10.107.27.143 with SMTP id b137mr5060613iob.76.1424550612054;
	Sat, 21 Feb 2015 12:30:12 -0800 (PST)
Received: by 10.107.5.69 with HTTP; Sat, 21 Feb 2015 12:30:11 -0800 (PST)
X-Originating-IP: [50.0.37.37]
Received: by 10.107.5.69 with HTTP; Sat, 21 Feb 2015 12:30:11 -0800 (PST)
In-Reply-To: <CABm2gDorEFNzzHH2bxpo6miv1H0RUhL9uAYX6gg2aW0wB1QDbw@mail.gmail.com>
References: <20150212064719.GA6563@savin.petertodd.org>
	<CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>
	<CAJHLa0PkzG44JpuQoHVLUU8SR55LaJf5AwG=a7AjK2u7TAveOQ@mail.gmail.com>
	<20150215212512.GR14804@nl.grid.coop> <54E11248.6090401@gmail.com>
	<20150219085604.GT14804@nl.grid.coop>
	<CABm2gDorEFNzzHH2bxpo6miv1H0RUhL9uAYX6gg2aW0wB1QDbw@mail.gmail.com>
Date: Sat, 21 Feb 2015 12:30:11 -0800
Message-ID: <CAOG=w-uJFobZtkd8OoPnOJC3uqCOwjsqyfNWJTg3j3sJQn+wXQ@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a1140a87c3276b3050f9f0931
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1YPH59-0003et-1z
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
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: Sat, 21 Feb 2015 20:55:28 -0000

--001a1140a87c3276b3050f9f0931
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thank you Jorge for the contribution of the Stag Hunt terminology. It is
much better than a politically charged "scorched earth".
On Feb 21, 2015 11:10 AM, "Jorge Tim=C3=B3n" <jtimon@jtimon.cc> wrote:

> I agree "scorched hearth" is a really bad name for the 0 conf protocol
> based on game theory. I would have preferred "stag hunt" since that's
> basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt)
> but I like the protocol and I think it would be interesting to
> integrate it in the  payment protocol.
> Even if that protocol didn't existed or didn't worked, replace-by-fee
> is purely part of a node's policy, not part of consensus.
> >From the whitepaper, 0 conf transactions being secure by the good will
> of miners was never an assumption, and it is clear to me that the
> system cannot provide those guaranties based on such a weak scheme. I
> believe thinking otherwise is naive.
> As to consider non-standard policies "an attack to bitcoin" because
> "that's not how bitcoin used to work", then I guess minimum relay fee
> policies can also be considered "an attack to bitcoin" on the same
> grounds.
> Lastly, "first-seen-wins" was just a simple policy to bootstrap the
> system, but I expect that most nodes will eventually move to policies
> that are economically rational for miners such as replace-by-fee.
> Not only I disagree this will be "the end of bitcoin" or "will push
> the price of the btc miners are mining down", I believe it will be
> something good for bitcoin.
> Since this is apparently controversial I don't want to push for
> replace-by-fee to become the new standard policy (something that would
> make sense to me). But once the policy code is sufficiently modular as
> to support several policies I would like bitcoin core to have a
> CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no
> policy checks at all).
> One step at a time I guess...
>
>
> On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes <hozer@hozed.org> wrote=
:
> > On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote:
> >>
> >>
> >> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote:
> >> >
> >> > Most money/payment systems include some method to reverse or undo
> >> > payments made in error. In these systems, the longer settlement
> >> > times you mention below are a feature, not a bug, and give more
> >> > time for a human to react to errors and system failures.
> >> >
> >>
> >> Settlement has to be final somewhere. That is the whole point of it.
> >> Transfer costs in current electronic payment systems are a direct
> >> consequence of their non-finality. That's the point Satoshi was making
> >> in the introduction to the whitepaper: "With the possibility of
> >> reversal, the need for trust spreads".
> >
> > The problem with that statement is I trust a merchant that I went into
> > a store and made a payment with personally more than I trust the firmwa=
re
> > on my hard drive [1].
> >
> > The attack surface of devices in your computer is huge. A motivated
> attacker
> > just needs to get an intern into a company that makes some kind of
> component
> > or system that's in your computer, cloud server, hardware wallet, or wh=
at
> > have you that has firmware capable of reading your private keys.
> >
> > With the possibility of mass trojaned hardware, if we are going to trus=
t
> > the system, it must somehow allow reversal through a human-in-the-loop.
> >
> >> There is nothing wrong with having reversible mechanisms built on top
> >> of Bitcoin, and indeed it makes sense for most activity to happen at
> >> those higher layers. It's easy to build things that way, but
> >> impossible to build them the other way: you can't build a
> >> non-reversible layer on top of a reversible layer.
> >
> > We built 'reliable' TCP on top of unreliable ethernet networks. My
> experience
> > with networking was if you tried to guarantee message delivery at the
> lowest
> > level, the system got exceedingly complicated, expensive, and brittle.
> >
> > Most applications, in particular paying someone you already trust, are
> quite
> > happy running on reversible systems, and in some cases more reliable an=
d
> > lower risk. (carrying non-reversible cash is generally considered risky=
)
> >
> > The problem is that if the base currency is assumed to be non-reversibl=
e,
> > then it's brittle and becomes 'too big to fail'.
> >
> > Where the blockchain improves on everything else is in transparency. If
> you
> > reverse transactions a lot, it will be obvious from an analysis. I woul=
d
> much
> > rather deal with a known, predictable, and relatively continous
> transaction
> > reversal rate (percentage) than have to deal with sudden failures where
> > some anonymous bad actor makes off with a fortune.
> >
> > We already have zero-conf double-spend transaction reversal, why not
> explicitly
> > extend that a little in a way that senders and receivers have a choice =
to
> > use it, or not?
> >
> >
> > [1]
> http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1Q=
V20150216
> >
> >
> -------------------------------------------------------------------------=
-----
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboard=
s
> > with Interactivity, Sharing, Native Excel Exports, App Integration & mo=
re
> > Get technology previously reserved for billion-dollar corporations, FRE=
E
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/ostg=
.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> -------------------------------------------------------------------------=
-----
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/ostg=
.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--001a1140a87c3276b3050f9f0931
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Thank you Jorge for the contribution of the Stag Hunt termin=
ology. It is much better than a politically charged &quot;scorched earth&qu=
ot;.</p>
<div class=3D"gmail_quote">On Feb 21, 2015 11:10 AM, &quot;Jorge Tim=C3=B3n=
&quot; &lt;jtimon@jtimon.cc&gt; wrote:<br type=3D"attribution"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">I agree &quot;scorched hearth&quot; is a really bad name=
 for the 0 conf protocol<br>
based on game theory. I would have preferred &quot;stag hunt&quot; since th=
at&#39;s<br>
basically what it&#39;s using (see <a href=3D"http://en.wikipedia.org/wiki/=
Stag_hunt" target=3D"_blank">http://en.wikipedia.org/wiki/Stag_hunt</a>)<br=
>
but I like the protocol and I think it would be interesting to<br>
integrate it in the=C2=A0 payment protocol.<br>
Even if that protocol didn&#39;t existed or didn&#39;t worked, replace-by-f=
ee<br>
is purely part of a node&#39;s policy, not part of consensus.<br>
&gt;From the whitepaper, 0 conf transactions being secure by the good will<=
br>
of miners was never an assumption, and it is clear to me that the<br>
system cannot provide those guaranties based on such a weak scheme. I<br>
believe thinking otherwise is naive.<br>
As to consider non-standard policies &quot;an attack to bitcoin&quot; becau=
se<br>
&quot;that&#39;s not how bitcoin used to work&quot;, then I guess minimum r=
elay fee<br>
policies can also be considered &quot;an attack to bitcoin&quot; on the sam=
e<br>
grounds.<br>
Lastly, &quot;first-seen-wins&quot; was just a simple policy to bootstrap t=
he<br>
system, but I expect that most nodes will eventually move to policies<br>
that are economically rational for miners such as replace-by-fee.<br>
Not only I disagree this will be &quot;the end of bitcoin&quot; or &quot;wi=
ll push<br>
the price of the btc miners are mining down&quot;, I believe it will be<br>
something good for bitcoin.<br>
Since this is apparently controversial I don&#39;t want to push for<br>
replace-by-fee to become the new standard policy (something that would<br>
make sense to me). But once the policy code is sufficiently modular as<br>
to support several policies I would like bitcoin core to have a<br>
CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no<br>
policy checks at all).<br>
One step at a time I guess...<br>
<br>
<br>
On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes &lt;<a href=3D"mailto:hoz=
er@hozed.org">hozer@hozed.org</a>&gt; wrote:<br>
&gt; On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 02/15/2015 11:25 PM, Troy Benjegerdes wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Most money/payment systems include some method to reverse or =
undo<br>
&gt;&gt; &gt; payments made in error. In these systems, the longer settleme=
nt<br>
&gt;&gt; &gt; times you mention below are a feature, not a bug, and give mo=
re<br>
&gt;&gt; &gt; time for a human to react to errors and system failures.<br>
&gt;&gt; &gt;<br>
&gt;&gt;<br>
&gt;&gt; Settlement has to be final somewhere. That is the whole point of i=
t.<br>
&gt;&gt; Transfer costs in current electronic payment systems are a direct<=
br>
&gt;&gt; consequence of their non-finality. That&#39;s the point Satoshi wa=
s making<br>
&gt;&gt; in the introduction to the whitepaper: &quot;With the possibility =
of<br>
&gt;&gt; reversal, the need for trust spreads&quot;.<br>
&gt;<br>
&gt; The problem with that statement is I trust a merchant that I went into=
<br>
&gt; a store and made a payment with personally more than I trust the firmw=
are<br>
&gt; on my hard drive [1].<br>
&gt;<br>
&gt; The attack surface of devices in your computer is huge. A motivated at=
tacker<br>
&gt; just needs to get an intern into a company that makes some kind of com=
ponent<br>
&gt; or system that&#39;s in your computer, cloud server, hardware wallet, =
or what<br>
&gt; have you that has firmware capable of reading your private keys.<br>
&gt;<br>
&gt; With the possibility of mass trojaned hardware, if we are going to tru=
st<br>
&gt; the system, it must somehow allow reversal through a human-in-the-loop=
.<br>
&gt;<br>
&gt;&gt; There is nothing wrong with having reversible mechanisms built on =
top<br>
&gt;&gt; of Bitcoin, and indeed it makes sense for most activity to happen =
at<br>
&gt;&gt; those higher layers. It&#39;s easy to build things that way, but<b=
r>
&gt;&gt; impossible to build them the other way: you can&#39;t build a<br>
&gt;&gt; non-reversible layer on top of a reversible layer.<br>
&gt;<br>
&gt; We built &#39;reliable&#39; TCP on top of unreliable ethernet networks=
. My experience<br>
&gt; with networking was if you tried to guarantee message delivery at the =
lowest<br>
&gt; level, the system got exceedingly complicated, expensive, and brittle.=
<br>
&gt;<br>
&gt; Most applications, in particular paying someone you already trust, are=
 quite<br>
&gt; happy running on reversible systems, and in some cases more reliable a=
nd<br>
&gt; lower risk. (carrying non-reversible cash is generally considered risk=
y)<br>
&gt;<br>
&gt; The problem is that if the base currency is assumed to be non-reversib=
le,<br>
&gt; then it&#39;s brittle and becomes &#39;too big to fail&#39;.<br>
&gt;<br>
&gt; Where the blockchain improves on everything else is in transparency. I=
f you<br>
&gt; reverse transactions a lot, it will be obvious from an analysis. I wou=
ld much<br>
&gt; rather deal with a known, predictable, and relatively continous transa=
ction<br>
&gt; reversal rate (percentage) than have to deal with sudden failures wher=
e<br>
&gt; some anonymous bad actor makes off with a fortune.<br>
&gt;<br>
&gt; We already have zero-conf double-spend transaction reversal, why not e=
xplicitly<br>
&gt; extend that a little in a way that senders and receivers have a choice=
 to<br>
&gt; use it, or not?<br>
&gt;<br>
&gt;<br>
&gt; [1] <a href=3D"http://www.reuters.com/article/2015/02/16/us-usa-cybers=
pying-idUSKBN0LK1QV20150216" target=3D"_blank">http://www.reuters.com/artic=
le/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216</a><br>
&gt;<br>
&gt; ----------------------------------------------------------------------=
--------<br>
&gt; Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server<br>
&gt; from Actuate! Instantly Supercharge Your Business Reports and Dashboar=
ds<br>
&gt; with Interactivity, Sharing, Native Excel Exports, App Integration &am=
p; more<br>
&gt; Get technology previously reserved for billion-dollar corporations, FR=
EE<br>
&gt; <a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&a=
mp;iu=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.ne=
t/gampad/clk?id=3D190641631&amp;iu=3D/4140/ostg.clktrk</a><br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server<br>
from Actuate! Instantly Supercharge Your Business Reports and Dashboards<br=
>
with Interactivity, Sharing, Native Excel Exports, App Integration &amp; mo=
re<br>
Get technology previously reserved for billion-dollar corporations, FREE<br=
>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D190641631&amp;iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
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>
</blockquote></div>

--001a1140a87c3276b3050f9f0931--