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
230
231
232
233
234
235
236
237
238
239
240
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <melvincarvalho@gmail.com>) id 1UO3eF-0005e7-Pc
for bitcoin-development@lists.sourceforge.net;
Fri, 05 Apr 2013 10:13:31 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.215.49 as permitted sender)
client-ip=209.85.215.49; envelope-from=melvincarvalho@gmail.com;
helo=mail-la0-f49.google.com;
Received: from mail-la0-f49.google.com ([209.85.215.49])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UO3eE-0001aC-21
for bitcoin-development@lists.sourceforge.net;
Fri, 05 Apr 2013 10:13:31 +0000
Received: by mail-la0-f49.google.com with SMTP id fs13so3319690lab.36
for <bitcoin-development@lists.sourceforge.net>;
Fri, 05 Apr 2013 03:13:23 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.146.199 with SMTP id te7mr5625799lab.23.1365156803238;
Fri, 05 Apr 2013 03:13:23 -0700 (PDT)
Received: by 10.112.143.38 with HTTP; Fri, 5 Apr 2013 03:13:23 -0700 (PDT)
In-Reply-To: <CANEZrP3S7b+uh2LW4vH=53opopLJRmmJ-_Uad6yEQxZ3kHW47A@mail.gmail.com>
References: <CAKaEYhLqnzrhdJNTSBccDA68Mb-hUnaZaCa9Gn43FuVpa410sg@mail.gmail.com>
<CANEZrP3S7b+uh2LW4vH=53opopLJRmmJ-_Uad6yEQxZ3kHW47A@mail.gmail.com>
Date: Fri, 5 Apr 2013 12:13:23 +0200
Message-ID: <CAKaEYhJ9-ksVXFhnzNvWHR2QoPc72uzesvsxn7ryebvt6+zxJg@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=e89a8f22c55551e2b704d99a569c
X-Spam-Score: -0.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
(melvincarvalho[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: 1UO3eE-0001aC-21
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 10:13:31 -0000
--e89a8f22c55551e2b704d99a569c
Content-Type: text/plain; charset=ISO-8859-1
On 5 April 2013 11:48, Mike Hearn <mike@plan99.net> wrote:
> 51% isn't a magic number - it's possible to do double spends against
> confirmed transactions before that. If Michael wanted to do so, with the
> current setup he could, and that's obviously rather different to how
> Satoshi envisioned mining working.
>
Thanks for pointing this out. I guess 51% is mainly of psychological
significance.
>
> However, you're somewhat right in the sense that it's a self-defeating
> attack. If the pool owner went bad, he could pull it off once, but the act
> of doing so would leave a permanent record and many of the people mining on
> his pool would leave. As he doesn't own the actual mining hardware, he then
> wouldn't be able to do it again.
>
Totally see the logic of this, and it makes sense. But I dont think the
only risk is in terms of double spend, but rather
1) vandalize the block chain which may be difficult to unwind?
2) use an attack to manipulate the price downwards, then rebuy lower
As bitcoin's market cap grows, incentives to move the market will grow
>
> There are also other mining protocols that allow people to pool together,
> without p2pool and without the pool operator being able to centrally pick
> which transactions go into the block. However I'm not sure they're widely
> deployed at the moment. It'd be better if people didn't cluster around big
> mining pools, but I think p2pool still has a lot of problems dealing with
> FPGA/ASIC hardware and it hasn't been growing for a long time.
>
I guess the market will decide which algorithm is used, but as a community
we can perhaps review the different mining protocols and order them in
terms of risk ...
>
>
> On Fri, Apr 5, 2013 at 11:30 AM, Melvin Carvalho <melvincarvalho@gmail.com
> > wrote:
>
>> There was some chat on IRC about a mining pool reaching 46%
>>
>> http://blockchain.info/pools
>>
>> What's the risk of a 51% attack.
>>
>> I suggested that the pool itself is decentralized so you could not launch
>> one
>>
>> On IRC people were saying that the pool owner gets to choose what goes in
>> the block
>>
>> Surely with random non colliding nonces, it would be almost impossible to
>> coordinate a 51% even by the owner
>>
>> Someone came back and said that creating random numbers on a GPU is
>> hard. But what about just creating ONE random number and incrementing from
>> there ...
>>
>> It would be great to know if this is a threat or a non issue
>>
>>
>> ------------------------------------------------------------------------------
>> Minimize network downtime and maximize team effectiveness.
>> Reduce network management and security costs.Learn how to hire
>> the most talented Cisco Certified professionals. Visit the
>> Employer Resources Portal
>> http://www.cisco.com/web/learning/employer_resources/index.html
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
--e89a8f22c55551e2b704d99a569c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 5 April 2013 11:48, Mike Hearn <span dir=3D"ltr"><<a href=3D"=
mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">51% isn't a magic number - it's possible to do dou=
ble spends against confirmed transactions before that. If Michael wanted to=
do so, with the current setup he could, and that's obviously rather di=
fferent to how Satoshi envisioned mining working.</div>
</blockquote><div><br></div><div>Thanks for pointing this out.=A0 I guess 5=
1% is mainly of psychological significance.=A0 <br></div><div>=A0</div><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>
<br></div><div>However, you're somewhat right in the sense that it'=
s a self-defeating attack. If the pool owner went bad, he could pull it off=
once, but the act of doing so would leave a permanent record and many of t=
he people mining on his pool would leave. As he doesn't own the actual =
mining hardware, he then wouldn't be able to do it again.</div>
</div></blockquote><div><br></div><div>Totally see the logic of this, and i=
t makes sense.=A0 But I dont think the only risk is in terms of double spen=
d, but rather<br><br></div><div>1) vandalize the block chain which may be d=
ifficult to unwind?<br>
</div><div>2) use an attack to manipulate the price downwards, then rebuy l=
ower<br><br></div><div>As bitcoin's market cap grows, incentives to mov=
e the market will grow<br></div><div>=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<div dir=3D"ltr">
<div><br></div><div>There are also other mining protocols that allow people=
to pool together, without p2pool and without the pool operator being able =
to centrally pick which transactions go into the block. However I'm not=
sure they're widely deployed at the moment. It'd be better if peop=
le didn't cluster around big mining pools, but I think p2pool still has=
a lot of problems dealing with FPGA/ASIC hardware and it hasn't been g=
rowing for a long time.</div>
</div></blockquote><div><br></div><div>I guess the market will decide which=
algorithm is used, but as a community we can perhaps review the different =
mining protocols and order them in terms of risk ...<br></div><div>=A0</div=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><d=
iv class=3D"h5">On Fri, Apr 5, 2013 at 11:30 AM, Melvin Carvalho <span dir=
=3D"ltr"><<a href=3D"mailto:melvincarvalho@gmail.com" target=3D"_blank">=
melvincarvalho@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=
=3D"ltr"><div><div><div><div><div>There was some chat on IRC about a mining=
pool reaching 46%<br>
<br><a href=3D"http://blockchain.info/pools" target=3D"_blank">http://block=
chain.info/pools</a><br>
<br></div>What's the risk of a 51% attack.<br>
<br></div>I suggested that the pool itself is decentralized so you could no=
t launch one<br><br>On IRC people were saying that the pool owner gets to c=
hoose what goes in the block<br><br></div>Surely with random non colliding =
nonces, it would be almost impossible to coordinate a 51% even by the owner=
<br>
<br></div>Someone came back and said that creating random numbers on a GPU =
is hard.=A0 But what about just creating ONE random number and incrementing=
from there ...<br><br></div><div>It would be great to know if this is a th=
reat or a non issue<br>
</div></div>
<br></div></div>-----------------------------------------------------------=
-------------------<br>
Minimize network downtime and maximize team effectiveness.<br>
Reduce network management and security costs.Learn how to hire<br>
the most talented Cisco Certified professionals. Visit the<br>
Employer Resources Portal<br>
<a href=3D"http://www.cisco.com/web/learning/employer_resources/index.html"=
target=3D"_blank">http://www.cisco.com/web/learning/employer_resources/ind=
ex.html</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div>
--e89a8f22c55551e2b704d99a569c--
|
