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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <btcdrak@gmail.com>) id 1YLx5V-00054f-Sw
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 16:58:01 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.176 as permitted sender)
client-ip=209.85.223.176; envelope-from=btcdrak@gmail.com;
helo=mail-ie0-f176.google.com;
Received: from mail-ie0-f176.google.com ([209.85.223.176])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YLx5U-0001kQ-Ql
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 16:58:01 +0000
Received: by iecar1 with SMTP id ar1so13347258iec.0
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Feb 2015 08:57:55 -0800 (PST)
X-Received: by 10.50.30.202 with SMTP id u10mr4955712igh.35.1423760275481;
Thu, 12 Feb 2015 08:57:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.36.32.77 with HTTP; Thu, 12 Feb 2015 08:57:35 -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>
From: Btc Drak <btcdrak@gmail.com>
Date: Thu, 12 Feb 2015 16:57:35 +0000
Message-ID: <CADJgMztrzMh8=Y6SD-JV1hpTTbGB8Y2u=59bQhGtF6h3+Ei_Ew@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=047d7b874b2c772955050ee705b6
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 HK_RANDOM_FROM From username looks random
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.6 HK_RANDOM_ENVFROM Envelope sender username looks random
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(btcdrak[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 HTML_OBFUSCATE_05_10 BODY: Message is 5% to 10% HTML obfuscation
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: 1YLx5U-0001kQ-Ql
Cc: Bitcoin Dev <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 16:58:02 -0000
--047d7b874b2c772955050ee705b6
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 12, 2015 at 3:15 PM, Mike Hearn <mike@plan99.net> wrote:
> Peter argues that this is stable and makes unconfirmed transactions safe
>> because a fraudster can buy something, walk out of the shop, and broadcast
>> a double spend with a higher fee. But then the merchant can re-spend the
>> original payment back to themselves with an *even* higher fee than that.
>> Then the fraudster can re-spend their double spend with an *even* higher
>> fee than that, and so on back and forth, until *all* the money has been
>> spent to miner fees. Thus the merchant loses their goods but the fraudster
>> has still "paid" in some sense because they don't get the money either.
>>
>
> This argument makes no sense for two reasons.
>
> 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.
>
I think that is a misdirection on your part. The point of replace-by-fee is
to make 0-confirms reliably unreliable. Currently people can "get away"
with 0-confirms but it's only because most people arent actively double
spending, and when they do it is for higher value targets. Double spend
attacks *are* happening a lot more frequently than is being admitted here,
according to Peter from work with various clients.
Like single address reuse, people have gotten used to something which is
bad. Generally accepting 0-conf is also a bad idea(tm) and instant
confirmation solutions should be sought elsewhere. There are already
interesting solutions and concepts: greenaddress for example, and
CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than
supporting and promoting risky 0-confirms, we need to spend time on better
alternative solutions that will work for everyone and not during the
honeymoon phase where attackers are fewer.
--047d7b874b2c772955050ee705b6
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">On T=
hu, Feb 12, 2015 at 3:15 PM, Mike Hearn <span dir=3D"ltr"><<a href=3D"ma=
ilto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote=
"><div>Peter argues that this is stable and makes unconfirmed transactions =
safe because a fraudster can buy something, walk out of the shop, and broad=
cast a double spend with a higher fee. But then the merchant can re-spend t=
he original payment back to themselves with an <i>even</i>=C2=A0higher fee =
than that. Then the fraudster can re-spend their double spend with an <i>ev=
en</i>=C2=A0higher fee than that, and so on back and forth, until <i>all</i=
>=C2=A0the money has been spent to miner fees. Thus the merchant loses thei=
r goods but the fraudster has still "paid" in some sense because =
they don't get the money either.<br></div></div></div></div></blockquot=
e></span><div><br></div><div>This argument makes no sense for two reasons.<=
/div><div><br></div><div>The first is that this setup means miners can stea=
l arbitrary payments if they work together with the sender of the money. Th=
e model assumes this collaboration won't happen, but it will. Because n=
o existing wallet has a "double spend this" button, to make the s=
cheme work the dishonest miners must create and distribute such a wallet th=
at implements the whole scorched-earth protocol. At that point it's eas=
y 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 d=
o this. The situation isn't stable at all.</div><div><br></div><div>The=
second is that it incentivises competitors to engage in payment fraud agai=
nst each other. A big rich coffee shop chain that is facing competition fro=
m a small, scrappy newcomer can simply walk into the new shop and buy thing=
s, then trigger the "scorched earth". Even with no miner collabor=
ation, this means the big company is down the cost of the product <i>but</i=
>=C2=A0so is the little company who lost everything. Whoever can outspend t=
he other wins.</div></div></div></div></blockquote><div><br></div><div>I th=
ink that is a misdirection on your part. The point of replace-by-fee is to =
make 0-confirms reliably unreliable. Currently people can "get away&qu=
ot; with 0-confirms but it's only because most people arent actively do=
uble spending, and when they do it is for higher value targets. Double spen=
d attacks <i>are</i> happening a lot more frequently than is being admitted=
here, according to Peter from work with various clients.=C2=A0</div><div><=
br></div><div>Like single address reuse, people have gotten used to somethi=
ng which is bad. Generally accepting 0-conf is also a bad idea(tm) and inst=
ant confirmation solutions should be sought elsewhere. There are already in=
teresting solutions and concepts: greenaddress for example, and CHECKLOCKTI=
MEVERIFY micropayment channels for example. Rather than supporting and prom=
oting risky 0-confirms, we need to spend time on better alternative solutio=
ns that will work for everyone and not during the honeymoon phase where att=
ackers are fewer.</div><div><br></div></div></div></div>
--047d7b874b2c772955050ee705b6--
|
