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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WdIYh-0002UK-Pd
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 12:15:19 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.171 as permitted sender)
client-ip=209.85.214.171; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f171.google.com;
Received: from mail-ob0-f171.google.com ([209.85.214.171])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WdIYg-0003Be-RQ
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 12:15:19 +0000
Received: by mail-ob0-f171.google.com with SMTP id uy5so2553654obc.30
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Apr 2014 05:15:13 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.229.228 with SMTP id st4mr1277052oec.16.1398341713530;
Thu, 24 Apr 2014 05:15:13 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Thu, 24 Apr 2014 05:15:13 -0700 (PDT)
In-Reply-To: <CAB+qUq7=o05GgCNdTtH=cuW56qbjg5v0ZpxvCYmCPj1AvFui+g@mail.gmail.com>
References: <CAC1+kJM3pSq8YfwbX167rQ0=0Y_hozRQ3pggDN524=LUfOdTqg@mail.gmail.com>
<CANEZrP1f9WV-Mp9SGm4q88h82xxBnwqg8M7JJhnqGOHCWf65xg@mail.gmail.com>
<CAB+qUq7=o05GgCNdTtH=cuW56qbjg5v0ZpxvCYmCPj1AvFui+g@mail.gmail.com>
Date: Thu, 24 Apr 2014 14:15:13 +0200
X-Google-Sender-Auth: MveP_9yKzZh6_R4taXUBa_3YUgM
Message-ID: <CANEZrP0fjzuUKh0Jmk9c99ne81hdxZdTnhw6sq47Na7AC4n04A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Chris Pacia <ctpacia@gmail.com>
Content-Type: multipart/alternative; boundary=001a11362fb01c159504f7c8cd81
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
(mh.in.england[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: 1WdIYg-0003Be-RQ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee
and game theory
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: Thu, 24 Apr 2014 12:15:20 -0000
--001a11362fb01c159504f7c8cd81
Content-Type: text/plain; charset=UTF-8
>
> This scheme would discourage people from attempting a Finney attack
> because they would end up worse off if they did.
>
Phrased another way, it simply makes every block a Finney attack that
charges the maximum double spending fee possible. This doesn't solve the
problem.
Beyond needing to double balances, what if the shop is selling me a phone
on contract? So the actual cost of the phone is lower than the real price
on the assumption of future revenue. Alice double spends (aka steals) the
phone, paying double the artifically lower cost but still making a good
saving. Bob does not end up with "nothing", he ends up in the red.
But there's a much simpler way to dispose with this idea. Jorge, go down to
your local bars and cafes, and ask them if they'd be willing to accept a
form of payment that allows anyone to steal from them by simply paying
double the purchase price to some other random guy. They *will* look at you
as if you're crazy. Why would they ever do that?
--001a11362fb01c159504f7c8cd81
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><p dir=3D"ltr">This scheme would discourage peop=
le from attempting a Finney attack because they would end up worse off if t=
hey did.</p>
</blockquote><div>Phrased another way, it simply makes every block a Finney=
attack that charges the maximum double spending fee possible. This doesn&#=
39;t solve the problem.</div><div><br></div><div>Beyond needing to double b=
alances, what if the shop is selling me a phone on contract? So the actual =
cost of the phone is lower than the real price on the assumption of future =
revenue. Alice double spends (aka steals) the phone, paying double the arti=
fically lower cost but still making a good saving. Bob does not end up with=
"nothing", he ends up in the red.</div>
<div><br></div><div>But there's a much simpler way to dispose with this=
idea. Jorge, go down to your local bars and cafes, and ask them if they=
9;d be willing to accept a form of payment that allows anyone to steal from=
them by simply paying double the purchase price to some other random guy. =
They <u>will</u>=C2=A0look at you as if you're crazy. Why would they ev=
er do that?</div>
</div></div></div>
--001a11362fb01c159504f7c8cd81--
|
