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
|
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 <gmaxwell@gmail.com>) id 1UO3Jr-00084g-2H
for bitcoin-development@lists.sourceforge.net;
Fri, 05 Apr 2013 09:52:27 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.172 as permitted sender)
client-ip=209.85.217.172; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f172.google.com;
Received: from mail-lb0-f172.google.com ([209.85.217.172])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UO3Jl-0008SZ-5m
for bitcoin-development@lists.sourceforge.net;
Fri, 05 Apr 2013 09:52:27 +0000
Received: by mail-lb0-f172.google.com with SMTP id u10so3587351lbi.31
for <bitcoin-development@lists.sourceforge.net>;
Fri, 05 Apr 2013 02:52:14 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.155.233 with SMTP id vz9mr5430831lbb.63.1365155534209;
Fri, 05 Apr 2013 02:52:14 -0700 (PDT)
Received: by 10.112.134.164 with HTTP; Fri, 5 Apr 2013 02:52:14 -0700 (PDT)
In-Reply-To: <CAKaEYhLqnzrhdJNTSBccDA68Mb-hUnaZaCa9Gn43FuVpa410sg@mail.gmail.com>
References: <CAKaEYhLqnzrhdJNTSBccDA68Mb-hUnaZaCa9Gn43FuVpa410sg@mail.gmail.com>
Date: Fri, 5 Apr 2013 02:52:14 -0700
Message-ID: <CAAS2fgRXzHBXy=Ozant7j1xifUgGnDiNSv=dzrHssWzt8v8e-A@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
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: 1UO3Jl-0008SZ-5m
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] A mining pool at 46%
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: Fri, 05 Apr 2013 09:52:27 -0000
On Fri, Apr 5, 2013 at 2:30 AM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
> There was some chat on IRC about a mining pool reaching 46%
> http://blockchain.info/pools
The estimates on there may be a bit lossy.
> What's the risk of a 51% attack.
The whole fixation on "51" as a magic number is a bit confused=E2=80=94 I'l=
l
say more below.
> I suggested that the pool itself is decentralized so you could not launch
> one
None of the pools listed there are meaningfully decentralized=E2=80=94 bef=
ore
Luke whines, in theory the ones supporting GBT could be if used in a
way that no one actually uses them. P2Pool is decentralized based on
the same technology as Bitcoin itself, but it's certainly not as point
and click easy as a centralized pool.
> On IRC people were saying that the pool owner gets to choose what goes in
> the block
That is correct.
Though I'd point out=E2=80=94 the major pool ops all seem to be great folks
who care about the future of Bitcoin=E2=80=94 and the continued success of
their very profitable businesses: a 50% mining pool with a 3% fee
rakes in 54 BTC per _day_.
The more likely threat isn't that pool owners do something bad: It's
that their stuff gets hacked (again) or that they're subjected to
coercion. ... and the attacker either wants to watch the (Bitcoin)
world burn, or after raiding the pool wallet can't exploit it further
except via blockchain attacks.
> Surely with random non colliding nonces, it would be almost impossible to
> coordinate a 51% even by the owner
That makes no sense. A centralized pool is the miner, the remote
workers are just doing whatever computation it tells them to do.
Certainly these remote workers might switch to another pool if they
knew something bad was happening... but evidence suggests that this
takes days even when the pool is overtly losing money. Miners have
freely dumped all their hashpower on questionable parties (like the
infamous pirate40) with nary a question as to what it would be used
for when they were paid a premium for doing so. It seems even those
with large hardware investments are not aware of or thinking carefully
about the risks.
> It would be great to know if this is a threat or a non issue
It's important to know exactly what kind of threat you're talking
about=E2=80=94 someone with a large amount of hash-power can replace
confirmed blocks with an alternative chain that contains different
transactions. This allows them to effectively reverse and respend
their own transactions=E2=80=94 clawing back funds that perhaps had already
triggered irreversible actions.
This doesn't require some magic "51%"=E2=80=94 its just that when a miner h=
as
>50% the attack would always be successful if they kept it up long
enough (long enough might be years if you're talking really close to
50% and he gets unlucky). Likewise, someone with a sustained
supermajority could deny all other blocks=E2=80=94 but that attack's damage
stops when they lose the supermajority or go away.
More interesting is this: An attacker with only 40% of the hashpower
can reverse six confirmations with a success rate of ~50%. There is
source for computing this at the end of the Bitcoin paper. I did a
quick and really lame conversion of his code JS so you can play with
it in a browser:
https://people.xiph.org/~greg/attack_success.html
|
