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
|
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 <gmaxwell@gmail.com>) id 1Wd2M1-0001Jx-I4
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 18:57:09 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.181 as permitted sender)
client-ip=209.85.217.181; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f181.google.com;
Received: from mail-lb0-f181.google.com ([209.85.217.181])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wd2M0-0004We-EB
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 18:57:09 +0000
Received: by mail-lb0-f181.google.com with SMTP id c11so1125554lbj.26
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 11:57:01 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.87.71 with SMTP id v7mr37104218laz.10.1398279421697;
Wed, 23 Apr 2014 11:57:01 -0700 (PDT)
Received: by 10.112.89.68 with HTTP; Wed, 23 Apr 2014 11:57:01 -0700 (PDT)
In-Reply-To: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
Date: Wed, 23 Apr 2014 11:57:01 -0700
Message-ID: <CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1Wd2M0-0004We-EB
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [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 18:57:09 -0000
On Wed, Apr 23, 2014 at 12:55 AM, Mike Hearn <mike@plan99.net> wrote:
> Lately someone launched Finney attacks as a service (BitUndo). As a remin=
der
> for newcomers, Finney attacks are where a miner secretly works on a block
> containing a double spend.
Hm? I didn't think this is at all what they did. What they claim to
do is to prioritize transactions in their mempool from people who pay
them, potentially over and above other transactions which they may or
may not have received first.
This may still be bad news for someone taking an irreversible action
in response to an unconfirmed payment and it may or may not be really
ill advised in general, but I think it's less sinister than it sounds
in your posts. Is there some reason to believe it isn't what it
claims to be?
I think we have very clear evidence that the Bitcoin community doesn't
care if miners reorder transactions in their mempool to profitable
ends: In https://bitcointalk.org/index.php?topic=3D327767.0 it's
demonstrated that GHash.IO, currently the largest publicly identified
pool was used to rip off Betcoin dice via double-spends.
> first started using Bitcoin, nowadays most of my purchases with it are fo=
r
> food and drink. If Bitcoin could not support such purchases, I would use =
it
> much less.
Accepting zero-conf inherently has some risk (well, so does all
business, but there is substantially more in a zero-conf payment).
Even in a spherical-cow Bitcoin absent anything like Bitundo someone
can just give a double spend to a large miner and currently give the
whole rest of the network the one paying the merchant. They will,
with high success rate be successful. Worse, it may _appear_ to the
network that the miner was a "bitundo" but they really were not. The
blockchain exists to establish consensus ordering, prior to the
blockchain there is no order, and so it is not easy to really say
which transaction came first in any meaningful sense.
But in business we balance risks and the risk that sometimes a
transaction will be reversed exists in every electronic payment system
available today, in most of them the risk persists for _months_ rather
than minutes. Businesses can still operate in the face of these
risks.
More importantly, it's possible to deploy technological approaches to
make zero-conf very secure against reversal: Things like performing
multi-sig with a anti-double-spending system, or using an external
federated payment network... but this stuff requires substantial
development work=E2=80=94 though it's not work thats likely to happen if
people are still confused about the level of security that zero-conf
has.
> Miners can vote to reallocate the coinbase value of bad blocks before the=
y
> mature.
I think miners 'voting' to reallocate coins, even if they're
thoroughly convinced that the owner of the coins is a nasty party, is
a much greater violation of the Bitcoin social contract than some
twiddling with the unspecified unconfirmed transaction ordering.
Doubly so because a 'nasty' party with non-trivial hash-power can
doublespend their own transactions with a pretty good success rate (as
was the case for the GHash.io betcoin spends) including not-just
zero-conf (though with obviously reduced effectiveness), and all of
your reliable detection depends on it being a public service.
A much better defense is having the control of hash power very well
distributed and so there isn't any central point that excerts enough
influence to change the risk statistics much. Giving miners the
ability to steal each others payments is, if anything, a force away
from that decentralization.
|
