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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1YLvky-0001JX-Q0
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 15:32:44 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.52 as permitted sender)
client-ip=74.125.82.52; envelope-from=natanael.l@gmail.com;
helo=mail-wg0-f52.google.com;
Received: from mail-wg0-f52.google.com ([74.125.82.52])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YLvkx-0003eo-OA
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 15:32:44 +0000
Received: by mail-wg0-f52.google.com with SMTP id x12so988565wgg.11
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Feb 2015 07:32:37 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.211.101 with SMTP id nb5mr6921334wic.37.1423755157678;
Thu, 12 Feb 2015 07:32:37 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Thu, 12 Feb 2015 07:32:37 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Thu, 12 Feb 2015 07:32:37 -0800 (PST)
In-Reply-To: <CANEZrP2hAUsRfeXUo-DLiiRmG5uJcwFuP4=o1S6Fb7ts5Ud=bw@mail.gmail.com>
References: <20150212064719.GA6563@savin.petertodd.org>
<CANEZrP2uVT_UqJbzyQcEbiS78T68Jj2cH7OGXv5QtYiCwArDdA@mail.gmail.com>
<CAE28kUQ87jWhq1p6RK1eKEuEP1ERxN_P2SS0=YsFEGAqRyMPLA@mail.gmail.com>
<CANEZrP2H2T2QFZceCc=YzwwiApJy7kY7FN0LoAZODGbW12SYsw@mail.gmail.com>
<CAE28kURa8g3YTPi-GHKAt4v0csxXe=QhGhV3aQcDZGSr=Lb7RQ@mail.gmail.com>
<CANEZrP2hAUsRfeXUo-DLiiRmG5uJcwFuP4=o1S6Fb7ts5Ud=bw@mail.gmail.com>
Date: Thu, 12 Feb 2015 16:32:37 +0100
Message-ID: <CAAt2M1-L+3KEvWV+4UUSZX7meXkdTMPdz8SsxqsRtGhxsjHKmg@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a11c37cc66bb22d050ee5d44a
X-Spam-Score: -0.6 (/)
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
(natanael.l[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1YLvkx-0003eo-OA
Cc: 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: Thu, 12 Feb 2015 15:32:44 -0000
--001a11c37cc66bb22d050ee5d44a
Content-Type: text/plain; charset=UTF-8
Den 12 feb 2015 16:15 skrev "Mike Hearn" <mike@plan99.net>:
>
> The first is that this setup means miners can steal arbitrary payments if
they work together with the sender of the money. The model assumes this
collaboration won't happen, but it will. Because no existing wallet has a
"double spend this" button, to make the scheme work the dishonest miners
must create and distribute such a wallet that implements the whole
scorched-earth protocol. At that point it's easy for miners to reward the
payment fraudster with some of the stolen money the merchant lost, meaning
it now makes sense for the fraudster to always do this. The situation isn't
stable at all.
>
> The second is that it incentivises competitors to engage in payment fraud
against each other. A big rich coffee shop chain that is facing competition
from a small, scrappy newcomer can simply walk into the new shop and buy
things, then trigger the "scorched earth". Even with no miner
collaboration, this means the big company is down the cost of the product
but so is the little company who lost everything. Whoever can outspend the
other wins.
>
> We don't really need game theory to tell us that this plan is a bad idea.
Just imagine trying to explain it to an actual shop keeper. They would
think you were crazy. Bitcoin is already a hard enough concept to
understand without throwing into the mix "anyone can burn the money they
gave you after walking out of the shop".
I see no fundamental difference in outcome from miner collusion in
scorched-fee (which isn't guaranteed to pay the "right" pool!) and miner
collusion in knowingly mining a doublespend transaction.
Both outcomes pay the miner and thief equally when successful. The merchant
loses in both.
Zero-conf needs something else for security. A guarantee it can not be
doublespent in the relevant time frame.
--001a11c37cc66bb22d050ee5d44a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br></p>
<p dir=3D"ltr">Den 12 feb 2015 16:15 skrev "Mike Hearn" <<a hr=
ef=3D"mailto:mike@plan99.net">mike@plan99.net</a>>:<br>
><br>
> The first is that this setup means miners can steal arbitrary payments=
if they work together with the sender of the money. The model assumes this=
collaboration won't happen, but it will. Because no existing wallet ha=
s a "double spend this" button, to make the scheme work the disho=
nest miners must create and distribute such a wallet that implements the wh=
ole scorched-earth protocol. At that point it's easy for miners to rewa=
rd the payment fraudster with some of the stolen money the merchant lost, m=
eaning it now makes sense for the fraudster to always do this. The situatio=
n isn't stable at all.<br>
><br>
> The second is that it incentivises competitors to engage in payment fr=
aud against each other. A big rich coffee shop chain that is facing competi=
tion from a small, scrappy newcomer can simply walk into the new shop and b=
uy things, then trigger the "scorched earth". Even with no miner =
collaboration, this means the big company is down the cost of the product b=
ut=C2=A0so is the little company who lost everything. Whoever can outspend =
the other wins.<br>
><br>
> We don't really need game theory to tell us that this plan is a ba=
d idea. Just imagine trying to explain it to an actual shop keeper. They wo=
uld think you were crazy. Bitcoin is already a hard enough concept to under=
stand without throwing into the mix "anyone can burn the money they ga=
ve you after walking out of the shop".</p>
<p dir=3D"ltr">I see no fundamental difference in outcome from miner collus=
ion in scorched-fee (which isn't guaranteed to pay the "right"=
; pool!) and miner collusion in knowingly mining a doublespend transaction.=
</p>
<p dir=3D"ltr">Both outcomes pay the miner and thief equally when successfu=
l. The merchant loses in both. </p>
<p dir=3D"ltr">Zero-conf needs something else for security. A guarantee it =
can not be doublespent in the relevant time frame. </p>
--001a11c37cc66bb22d050ee5d44a--
|
