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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
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 1Wcs1x-0002wc-RA
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 07:55:45 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.170 as permitted sender)
client-ip=209.85.214.170; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f170.google.com;
Received: from mail-ob0-f170.google.com ([209.85.214.170])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wcs1w-0004kj-9s
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 07:55:45 +0000
Received: by mail-ob0-f170.google.com with SMTP id vb8so643843obc.15
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 00:55:30 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.51.4 with SMTP id g4mr6294573oeo.52.1398239730410; Wed,
23 Apr 2014 00:55:30 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Wed, 23 Apr 2014 00:55:30 -0700 (PDT)
Date: Wed, 23 Apr 2014 09:55:30 +0200
X-Google-Sender-Auth: vR2MXQoRuA3tf3LvLqngzWUETJU
Message-ID: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c304a4712e0204f7b10e62
X-Spam-Score: 2.1 (++)
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
2.6 RISK_FREE No risk!
X-Headers-End: 1Wcs1w-0004kj-9s
Subject: [Bitcoin-development] Coinbase reallocation to discourage Finney
attacks
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: Wed, 23 Apr 2014 07:55:46 -0000
--001a11c304a4712e0204f7b10e62
Content-Type: text/plain; charset=UTF-8
Lately someone launched Finney attacks as a service (BitUndo). As a
reminder for newcomers, Finney attacks are where a miner secretly works on
a block containing a double spend. When they eventually find a block, they
run to the merchant and pay, then broadcast the block. In a simpler variant
of this attack you make purchases as normal with a modified wallet that
always submits a double spend to the service, and then N% of the time where
N is the percentage of overall hash power the dishonest miners have, you
get your money back minus their fee.
N does not need to be very high to render Bitcoin much less useful. Real
time transactions are very important. Although I never expected it when I
first started using Bitcoin, nowadays most of my purchases with it are for
food and drink. If Bitcoin could not support such purchases, I would use it
much less.
Even with their woeful security many merchants see <1-2% credit card
chargeback rates, and chargebacks can be disputed. In fact merchants win
about 40% of chargeback disputes. So if N was only, say, 5%, and there was
a large enough population of users who were systematically trying to
defraud merchants, we'd already be having worse security than magstripe
credit cards. EMV transactions have loss rates in the noise, so for
merchants who take those Bitcoin would be dramatically less secure.
The idea of discouraging blocks that perform Finney attacks by having
honest miners refuse to build on them has been proposed. But it has a
couple of problems:
1. It's hard to automatically detect Finney attacks. Looking for blocks
that contain unseen transactions that override the mempool doesn't work -
the dishonest users could broadcast all their double spends once a Finney
block was found and then broadcast the block immediately afterwards, thus
making the block look like any other would in the presence of double spends.
2. If they could be automatically identified, it possibly could be
converted into a DoS on the network by broadcasting double spends in such a
way that the system races, and every miner produces a block that looks like
a Finney attack to some of the others. The chain would stop advancing.
3. Miners who want to vote "no" on a block take a big risk, they could
be on the losing side of the fork and end up wasting their work.
We can resolve these problems with a couple of tweaks:
1. Dishonest blocks can be identified out of band, by having honest
miners submit double spends against themselves to the service anonymously
using a separate tool. When their own double spend appears they know the
block is bad.
2. Miners can vote to reallocate the coinbase value of bad blocks before
they mature. If a majority of blocks leading up to maturity vote for
reallocation, the value goes into a pot that subsequent blocks are allowed
to claim for themselves. Thus there is no risk to voting "no" on a block,
the work done by the Finney attacker is not wasted, and users do not have
to suffer through huge reorgs.
This may seem a radical suggestion, but I think it's much less radical than
some of the others being thrown around.
The above approach works as long as the majority of hashpower is honest,
defined to mean, working to stop double spending. This is the same security
property as described in the white paper, thus this introduces no new
security assumptions. Note that assuming *all* miners are dishonest and are
willing to double spend automatically resolves the Bitcoin experiment as a
failure, because that would invalidate the entire theory upon which the
system is built. That doesn't mean the assumption is wrong! It may be that
an entirely unregulated market for double spending prevention cannot work
and the participants eventually all end up trashing the commons - but the
hope is that smart incentives can replace the traditional reliance on law
and regulation to avoid this.
The voting mechanism would only apply to coinbases, not arbitrary
transactions, thus it cannot be used to steal arbitrary users bitcoins. A
majority of miners can already reallocate coinbases by forking them out,
but this wastes energy and work presenting a significant discouragement to
vote unless you already know via some out of band mechanism that you have a
solid majority. Placing votes into the coinbase scriptSig as is done with
other things avoids that problem.
The identification of Finney blocks relies on miners to take explicit
action, like downloading and running a tool that submits votes via RPC. It
can be expected that double spending services would try to identify and
block the sentinel transactions, which is why it's better to have the code
that fights this arms race be out of process and developed externally to
Bitcoin Core itself, which should ultimately just enforce the new (forking)
rule change.
--001a11c304a4712e0204f7b10e62
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Lately someone launched Finney attacks as a service (BitUn=
do). As a reminder for newcomers, Finney attacks are where a miner secretly=
works on a block containing a double spend. When they eventually find a bl=
ock, they run to the merchant and pay, then broadcast the block. In a simpl=
er variant of this attack you make purchases as normal with a modified wall=
et that always submits a double spend to the service, and then N% of the ti=
me where N is the percentage of overall hash power the dishonest miners hav=
e, you get your money back minus their fee.=C2=A0<div>
<br></div><div>N does not need to be very high to render Bitcoin much less =
useful. Real time transactions are very important. Although I never expecte=
d it when I first started using Bitcoin, nowadays most of my purchases with=
it are for food and drink. If Bitcoin could not support such purchases, I =
would use it much less.</div>
<div>Even with their woeful security many merchants see <1-2% credit car=
d chargeback rates, and chargebacks can be disputed. In fact merchants win =
about 40% of chargeback disputes. So if N was only, say, 5%, and there was =
a large enough population of users who were systematically trying to defrau=
d merchants, we'd already be having worse security than magstripe credi=
t cards. EMV transactions have loss rates in the noise, so for merchants wh=
o take those Bitcoin would be dramatically less secure.=C2=A0</div>
<div><br></div><div>The idea of discouraging blocks that perform Finney att=
acks by having honest miners refuse to build on them has been proposed. But=
it has a couple of problems:</div><div><ol><li>It's hard to automatica=
lly detect Finney attacks. Looking for blocks that contain unseen transacti=
ons that override the mempool doesn't work - the dishonest users could =
broadcast all their double spends once a Finney block was found and then br=
oadcast the block immediately afterwards, thus making the block look like a=
ny other would in the presence of double spends.<br>
<br></li><li>If they could be automatically identified, it possibly could b=
e converted into a DoS on the network by broadcasting double spends in such=
a way that the system races, and every miner produces a block that looks l=
ike a Finney attack to some of the others. The chain would stop advancing.<=
br>
<br></li><li>Miners who want to vote "no" on a block take a big r=
isk, they could be on the losing side of the fork and end up wasting their =
work.</li></ol><div>We can resolve these problems with a couple of tweaks:<=
/div>
</div><div><ol><li>Dishonest blocks can be identified out of band, by havin=
g honest miners submit double spends against themselves to the service anon=
ymously using a separate tool. When their own double spend appears they kno=
w the block is bad.<br>
<br></li><li>Miners can vote to reallocate the coinbase value of bad blocks=
before they mature. If a majority of blocks leading up to maturity vote fo=
r reallocation, the value goes into a pot that subsequent blocks are allowe=
d to claim for themselves. Thus there is no risk to voting "no" o=
n a block, the work done by the Finney attacker is not wasted, and users do=
not have to suffer through huge reorgs.</li>
</ol><div>This may seem a radical suggestion, but I think it's much les=
s radical than some of the others being thrown around.</div></div><div><br>=
</div><div>The above approach works as long as the majority of hashpower is=
honest, defined to mean, working to stop double spending. This is the same=
security property as described in the white paper, thus this introduces no=
new security assumptions. Note that assuming <i>all</i>=C2=A0miners are di=
shonest and are willing to double spend automatically resolves the Bitcoin =
experiment as a failure, because that would invalidate the entire theory up=
on which the system is built. That doesn't mean the assumption is wrong=
! It may be that an entirely unregulated market for double spending prevent=
ion cannot work and the participants eventually all end up trashing the com=
mons - but the hope is that smart incentives can replace the traditional re=
liance on law and regulation to avoid this.</div>
<div><br></div><div>The voting mechanism would only apply to coinbases, not=
arbitrary transactions, thus it cannot be used to steal arbitrary users bi=
tcoins. A majority of miners can already reallocate coinbases by forking th=
em out, but this wastes energy and work presenting a significant discourage=
ment to vote unless you already know via some out of band mechanism that yo=
u have a solid majority. Placing votes into the coinbase scriptSig as is do=
ne with other things avoids that problem.</div>
<div><br></div><div>The identification of Finney blocks relies on miners to=
take explicit action, like downloading and running a tool that submits vot=
es via RPC. It can be expected that double spending services would try to i=
dentify and block the sentinel transactions, which is why it's better t=
o have the code that fights this arms race be out of process and developed =
externally to Bitcoin Core itself, which should ultimately just enforce the=
new (forking) rule change.</div>
<div><br></div><div><br></div></div>
--001a11c304a4712e0204f7b10e62--
|
