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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YLvTw-0008EK-LT
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 15:15:08 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.177 as permitted sender)
client-ip=209.85.212.177; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f177.google.com;
Received: from mail-wi0-f177.google.com ([209.85.212.177])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YLvTv-0003Bt-3k
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Feb 2015 15:15:08 +0000
Received: by mail-wi0-f177.google.com with SMTP id bs8so5121406wib.4
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Feb 2015 07:15:01 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.108.178 with SMTP id hl18mr6890641wib.92.1423754101066;
Thu, 12 Feb 2015 07:15:01 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.11 with HTTP; Thu, 12 Feb 2015 07:15:00 -0800 (PST)
In-Reply-To: <CAE28kURa8g3YTPi-GHKAt4v0csxXe=QhGhV3aQcDZGSr=Lb7RQ@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>
Date: Thu, 12 Feb 2015 16:15:00 +0100
X-Google-Sender-Auth: Zf1GArs_GTNAhst5phpYP4LSE-U
Message-ID: <CANEZrP2hAUsRfeXUo-DLiiRmG5uJcwFuP4=o1S6Fb7ts5Ud=bw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Alex Mizrahi <alex.mizrahi@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8f3ba0fd711275050ee5954a
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
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_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
-0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YLvTv-0003Bt-3k
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 15:15:08 -0000
--e89a8f3ba0fd711275050ee5954a
Content-Type: text/plain; charset=UTF-8
>
> So anyway, in my opinion, it is actually great that Bitcoin is still
> relatively small: we have an opportunity to analyze and improve things.
> But you seem to be hostile to people who do that (and who do not share
> your opinion), which is kinda uncool.
>
To clarify once more, I'm all for people researching and building ways to
make Bitcoin better and safer. And debating that here is cool too.
The "replace by fee" patches don't do this; as you said yourself the whole
scorched earth thing makes no sense. It's not a solution to anything and
it's important people realise that.
Perhaps it will help if I spell out why this whole approach won't work (but
can easily damage bitcoin a lot along the way).
Normal Bitcoin nodes pick which transaction to put into a block by simply
selecting whichever they saw arrive first, as determined by the arrival
order of network packets. This rule is simple and has multiple advantages
for people using Bitcoin to buy and sell things.
Replace-by-fee changes this so nodes select whichever chain of unconfirmed
transactions pays the highest miner fees. Up until the point that a
transaction appears in a block, anyone can broadcast a double spend (or a
spend of an unconfirmed transaction) which pays higher fees than before,
causing that tx chain to become the candidate for chain inclusion.
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.
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".
--e89a8f3ba0fd711275050ee5954a
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"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
class=3D"gmail_quote"><div>So anyway, in my opinion, it is actually great =
that Bitcoin is still relatively small: we have an opportunity to analyze a=
nd improve things.</div><div>But you seem to be hostile to people who do th=
at (and who do not share your opinion), which is kinda uncool.</div></div><=
/div></div></blockquote><div><br></div><div>To clarify once more, I'm a=
ll for people researching and building ways to make Bitcoin better and safe=
r. And debating that here is cool too.</div><div><br></div><div>The "r=
eplace by fee" patches don't do this; as you said yourself the who=
le scorched earth thing makes no sense. It's not a solution to anything=
and it's important people realise that.</div><div><br></div><div>Perha=
ps it will help if I spell out why this whole approach won't work (but =
can easily damage bitcoin a lot along the way).</div><div><br></div><div>No=
rmal Bitcoin nodes pick which transaction to put into a block by simply sel=
ecting whichever they saw arrive first, as determined by the arrival order =
of network packets. This rule is simple and has multiple advantages for peo=
ple using Bitcoin to buy and sell things.</div><div><br></div><div>Replace-=
by-fee changes this so nodes select whichever chain of unconfirmed transact=
ions pays the highest miner fees. Up until the point that a transaction app=
ears in a block, anyone can broadcast a double spend (or a spend of an unco=
nfirmed transaction) which pays higher fees than before, causing that tx ch=
ain to become the candidate for chain inclusion.</div><div><br></div><div>P=
eter argues that this is stable and makes unconfirmed transactions safe bec=
ause a fraudster can buy something, walk out of the shop, and broadcast a d=
ouble spend with a higher fee. But then the merchant can re-spend the origi=
nal payment back to themselves with an <i>even</i>=C2=A0higher fee than tha=
t. Then the fraudster can re-spend their double spend with an <i>even</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 their go=
ods but the fraudster has still "paid" in some sense because they=
don't get the money either.</div><div><br></div><div>This argument mak=
es no sense for two reasons.</div><div><br></div><div>The first is that thi=
s setup means miners can steal arbitrary payments if they work together wit=
h the sender of the money. The model assumes this collaboration won't h=
appen, but it will. Because no existing wallet has a "double spend thi=
s" button, to make the scheme work the dishonest miners must create an=
d distribute such a wallet that implements the whole scorched-earth protoco=
l. At that point it's easy for miners to reward the payment fraudster w=
ith 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.=
</div><div><br></div><div>The second is that it incentivises competitors to=
engage in payment fraud against each other. A big rich coffee shop chain t=
hat is facing competition from a small, scrappy newcomer can simply walk in=
to 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 <i>but</i>=C2=A0so is the little company who lost every=
thing. Whoever can outspend the other wins.</div><div><br></div><div><br></=
div><div>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. The=
y would think you were crazy. Bitcoin is already a hard enough concept to u=
nderstand without throwing into the mix "anyone can burn the money the=
y gave you after walking out of the shop".</div></div></div></div>
--e89a8f3ba0fd711275050ee5954a--
|
