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
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
|
Return-Path: <el33th4x0r@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7FD98360
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Mar 2017 16:27:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f50.google.com (mail-it0-f50.google.com
[209.85.214.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 40AE719B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Mar 2017 16:27:49 +0000 (UTC)
Received: by mail-it0-f50.google.com with SMTP id 190so5840919itm.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Mar 2017 09:27:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=MEMIdqBQwA58R8GT5mO/STdql6fxsZplIvnOjTjIdpM=;
b=mlGG19VPPk3o8YZcxISdWjB4Su/cq/o9y3EhwwPSv63XUtu6WIrItiO2/P5H6Y1pc0
/ENAtQWdHoQsv/Kb8iCtI1X4/RnF+ARqDlXaMXFhHdFehEojXE/I7zePcELBUngk2NGh
+Njk2qDumyhttsVpmA7s8TMmKQVY8J6FmHBa3NfB0zr6Breop5PYSXWazHGf155qqve0
4F4MGH7oY9vlZli9xjHjjF3wdoPKn+XoX1C9rAqFSHM/er3Yys6bvU2LKcLtbQYFeuSR
iacWhfdnrpb34xb8d3imaOpgu3EbehjE1Y2G4VZYH8FVW+2QFx82IVqfVUm3ilwbNJjj
eufQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=MEMIdqBQwA58R8GT5mO/STdql6fxsZplIvnOjTjIdpM=;
b=jsAsg2kx5eOqALD9Hg1nunGLSNEdiHHZv88Iez4CWBL8j+PX9nX8iDT94ULx2NFWAj
6ecgtwSgxkiDrWrISBo6vmL8l00jhMpI1BVcQ3Xjm8Z7XuAulRc4fTZvEN/mBCGBYXWa
zjIH7/m7+d79mP3K/dAds3J4a/A5Ie14Z7DtLdW5aD3u8+G276O22GO+6cNDxY9eGdOh
gMZEY3K86quMf2IXYJssbsJA+Bzfvfi2hLrvzligHDP3cvMqKZAF4PiOCWiK++mxNqtH
dx6LsqJhCoMK+ys9Jnila5eTz9+nwutdqZ+jq5e8k+Oyuo9tGVuHSNwLIQahI9kC/0NZ
q4jA==
X-Gm-Message-State: AFeK/H2lQB/ga1wdUz0IrRn2jGwGjnjcEciUu4pYWxuTN0e4ogtZ5VqzMZgQRxQH9bYtdUExQ9kj/RpCffQ4CQ==
X-Received: by 10.36.40.4 with SMTP id h4mr3813305ith.62.1490372868212; Fri,
24 Mar 2017 09:27:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.162.7 with HTTP; Fri, 24 Mar 2017 09:27:47 -0700 (PDT)
Received: by 10.79.162.7 with HTTP; Fri, 24 Mar 2017 09:27:47 -0700 (PDT)
In-Reply-To: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info>
References: <5b9ba6c4-6d8f-9c0b-2420-2be6c30f87b5@cannon-ciota.info>
From: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= <el33th4x0r@gmail.com>
Date: Fri, 24 Mar 2017 09:27:47 -0700
Message-ID: <CAPkFh0s-ZyLN06h+EpU2rfgs5TkTEPG+3FZyWSXusp-Z9XHasQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
CANNON <cannon@cannon-ciota.info>
Content-Type: multipart/alternative; boundary=001a1143d9fe649fb0054b7c79b2
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
HTML_OBFUSCATE_05_10,
RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 25 Mar 2017 04:46:32 +0000
Subject: Re: [bitcoin-dev] Defending against empty or near empty blocks from
malicious miner takeover?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Mar 2017 16:27:50 -0000
--001a1143d9fe649fb0054b7c79b2
Content-Type: text/plain; charset=UTF-8
Because there's no consensus on the contents of the mempool, this approach
is unsafe and will lead to forks. It also opens a new attack vector where
people can time the flood of new transactions with the discovery of a block
by a competitor, to orphan the block and to fork the chain.
The technical defense against an attacking majority of miners is to change
the PoW, effectively moving the community off into a new altcoin where the
attackers, hopefully, don't have majority hash power.
- egs
Sent from my phone, please compensate for autocorrect errors.
On Mar 24, 2017 9:06 AM, "CANNON via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> When the original white paper was written the idea was that nodes
> would be miners at same time. That the distribution of mining power
> being mostly on par with the distribution of nodes if I understand
> correctly. The problem we face now I fear, is the mining power
> becoming centralized. Even if every bitcoin node invested a $1000
> into mining power and mined at a loss, it still would not even
> make a dent in hash distribution. Currently there are around 6000
> known nodes. If each node invested $1000 for say 10 ths of hashing
> power. At current hashrate of around 3,674,473,142 GH/s this would
> only make up %16 of hash power. This is out of balance as while
> nodes are distributed mining power is becoming very centralized
> due to the creation of monopolization of ASICs. The problem we
> are facing is a small group of a couple people whom control a
> large amount and growing of hash power. At time of this writing
> it has quickly risen to 39% and at current rate will soon become
> 50% of hashing power that is controlled by a small group of a few
> people. Their intentions are too hijack the bitcoin network to a
> cryptocurrency that suits their dangerous agenda. Dangerous because
> their plan would centralize power of consensus as I understand it,
> to themselves the miners. Dangerous also because the code base of
> the attempting subverters is buggy, insecure, and reckless from a
> technological standpoint. Even though they only have very minute
> amount of nodes compared to legitimate bitcion nodes, the danger
> is that they are very quickly taking over in mining power. While
> it is true that nodes will not accept invalid blocks that would be
> attempted to be pushed by the conspirators, they are threatening to
> attack the valid (or in their words, "minority chain") by dedicating
> some mining power soley to attacking the valid chain by mining empty
> blocks and orphaning the valid chain. So even though the majority
> of nodes would be enforcing what blocks are valid and as a result
> block the non-compliant longer chain, the conspiring miner can simply
> (as they are currently threatening to) make the valid chain unuseable
> by mining empty blocks.
>
> If a malicious miner with half or majority control passes invalid
> blocks, the worst case scenario is a hardfork coin split in which
> the non-compliant chain becomes an alt. However the problem is that
> this malicious miner is very recently threatening to not just simply
> fork, but to kill the valid chain to force economic activity to the
> adversary controlled chain. If we can simply defend against attacks
> to the valid chain, we can prevent the valid chain from dying.
>
> While empty or near empty blocks would generally be protected by
> the incentive of miners to make money. The threat is there if the
> malicious miner with majority control is willing to lose out on
> these transaction fees and block reward if their intention is to
> suppress it to force the majority onto their chain.
>
> Proposal for potential solution Update nodes to ignore empty blocks,
> so this way mined empty blocks cannot be used to DOS attack the
> blockchain. But what about defense from say, blocks that are
> not empty but intentionally only have a couple transactions
> in it? Possible to have nodes not only ignore empty blocks,
> but also blocks that are abnormally small compared to number of
> valid transactions in mempool?
>
> For example would be something like this:
> If block = (empty OR <%75 of mempool) THEN discard
> This threshold just an example.
>
> What would be any potentials risks
> and attacks resulting from both having such new rulesets and not
> doing anything?
>
> Lets assume that the first problem of blocking empty or near empty
> blocks has been mitigated with the above proposed solution. How
> likely and possible would it be for a malicious miner with lots of
> mining power to orphan the chain after so many blocks even with
> non empty blocks? Is there a need to mitigate this?
> If so is it possible?
>
> Time is running short I fear. There needs to be discussion on various
> attacks and how they can be guarded against along with various
> other contingency plans.
>
> - --
> Cannon
> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
> Email: cannon@cannon-ciota.info
>
> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
> If this matters to you, use PGP.
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJY1UH/AAoJEAYDai9lH2mw2QYQALDLBxjdO5WTG7VXfuAE476p
> D3o1MMGw23tb+DFUO5WV6aFqfy3VSxbVXz6UuWbj6kHgp3ys6qxg5TX0Dy8tKSZM
> V28kovuS/pfen4gTxw1FCNff7YVW1R8QX+cSYxSD5EoEaTbpIPgi8zMusDxUVZk2
> WG3ItoyvkLvoNIYGDcU3gR3UkjDS5lOPiHu5BKSj1dEiibOXhr8JEBCznfUSyxCG
> TjVRJaUPlwCU06nad8jAZiDrsW3l866iNkBKaMzMavYuMLvCGIdRkbf54B2ZlIT/
> S/owusxqeIdQpydi/3ydnrqyeWo3znMnn+oOvdvfYEHKLts6gar3Zv8cZ40yYSIE
> z7C7GQFIo5TYDUNOk+2VE7NNtdX39Wj3gJql/305miaIt0qMsf1D30ODjePwyxUQ
> LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/tFm3kx0PunptJaZT8d9EgMeHREjCF4di04A
> 6Dp3Qeug41X/zdIc2AM387QnPwmGB1TpfrY9qgvcrIe26T6An2V5LHwVmslCX3ui
> DYAl0o5ODQqnnakF1FIrr1blMVqm7FqDPQc1I5TfzQuxX2+x+5zdrciPC2HUMCMQ
> jMujge5IdGL3kjEwjt+M6kqLu0/T0fhdUetb2DWrRJUcEVoIaiUL7qLJC+4KMR3d
> Gu3oWoE1ld+BC6At28AD
> =SSuj
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a1143d9fe649fb0054b7c79b2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Because there's no consensus on the contents of the m=
empool, this approach is unsafe and will lead to forks. It also opens a new=
attack vector where people can time the flood of new transactions with the=
discovery of a block by a competitor, to orphan the block and to fork the =
chain.<div dir=3D"auto"><br></div><div dir=3D"auto">The technical defense a=
gainst an attacking majority of miners is to change the PoW, effectively mo=
ving the community off into a new altcoin where the attackers, hopefully, d=
on't have majority hash power.</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">- egs</div><div dir=3D"auto"><br><div data-smartmail=3D"gmail_si=
gnature" dir=3D"auto">Sent from my phone, please compensate for autocorrect=
errors. </div></div></div><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On Mar 24, 2017 9:06 AM, "CANNON via bitcoin-dev" <<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.l=
inuxfoundation.org</a>> wrote:<br type=3D"attribution"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
When the original white paper was written the idea was that nodes<br>
would be miners at same time. That the distribution of mining power<br>
being mostly on par with the distribution of nodes if I understand<br>
correctly. The problem we face now I fear, is the mining power<br>
becoming centralized. Even if every bitcoin node invested a $1000<br>
into mining power and mined at a loss, it still would not even<br>
make a dent in hash distribution. Currently there are around 6000<br>
known nodes. If each node invested $1000 for say 10 ths of hashing<br>
power. At current hashrate of around 3,674,473,142 GH/s this would<br>
only make up %16 of hash power. This is out of balance as while<br>
nodes are distributed mining power is becoming very centralized<br>
due to the creation of monopolization of ASICs. The problem we<br>
are facing is a small group of a couple people whom control a<br>
large amount and growing of hash power. At time of this writing<br>
it has quickly risen to 39% and at current rate will soon become<br>
50% of hashing power that is controlled by a small group of a few<br>
people. Their intentions are too hijack the bitcoin network to a<br>
cryptocurrency that suits their dangerous agenda. Dangerous because<br>
their plan would centralize power of consensus as I understand it,<br>
to themselves the miners. Dangerous also because the code base of<br>
the attempting subverters is buggy, insecure, and reckless from a<br>
technological standpoint. Even though they only have very minute<br>
amount of nodes compared to legitimate bitcion nodes, the danger<br>
is that they are very quickly taking over in mining power. While<br>
it is true that nodes will not accept invalid blocks that would be<br>
attempted to be pushed by the conspirators, they are threatening to<br>
attack the valid (or in their words, "minority chain") by dedicat=
ing<br>
some mining power soley to attacking the valid chain by mining empty<br>
blocks and orphaning the valid chain. So even though the majority<br>
of nodes would be enforcing what blocks are valid and as a result<br>
block the non-compliant longer chain, the conspiring miner can simply<br>
(as they are currently threatening to) make the valid chain unuseable<br>
by mining empty blocks.<br>
<br>
If a malicious miner with half or majority control passes invalid<br>
blocks, the worst case scenario is a hardfork coin split in which<br>
the non-compliant chain becomes an alt. However the problem is that<br>
this malicious miner is very recently threatening to not just simply<br>
fork, but to kill the valid chain to force economic activity to the<br>
adversary controlled chain. If we can simply defend against attacks<br>
to the valid chain, we can prevent the valid chain from dying.<br>
<br>
While empty or near empty blocks would generally be protected by<br>
the incentive of miners to make money. The threat is there if the<br>
malicious miner with majority control is willing to lose out on<br>
these transaction fees and block reward if their intention is to<br>
suppress it to force the majority onto their chain.<br>
<br>
Proposal for potential solution Update nodes to ignore empty blocks,<br>
so this way mined empty blocks cannot be used to DOS attack the<br>
blockchain. But what about defense from say, blocks that are<br>
not empty but intentionally only have a couple transactions<br>
in it? Possible to have nodes not only ignore empty blocks,<br>
but also blocks that are abnormally small compared to number of<br>
valid transactions in mempool?<br>
<br>
For example would be something like this:<br>
If block =3D (empty OR=C2=A0 <%75 of mempool) THEN discard<br>
This threshold just an example.<br>
<br>
What would be any potentials risks<br>
and attacks resulting from both having such new rulesets and not<br>
doing anything?<br>
<br>
Lets assume that the first problem of blocking empty or near empty<br>
blocks has been mitigated with the above proposed solution. How<br>
likely and possible would it be for a malicious miner with lots of<br>
mining power to orphan the chain after so many blocks even with<br>
non empty blocks? Is there a need to mitigate this?<br>
If so is it possible?<br>
<br>
Time is running short I fear. There needs to be discussion on various<br>
attacks and how they can be guarded against along with various<br>
other contingency plans.<br>
<br>
- --<br>
Cannon<br>
PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832<br>
Email: <a href=3D"mailto:cannon@cannon-ciota.info">cannon@cannon-ciota.info=
</a><br>
<br>
NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD<br>
BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.<br>
If this matters to you, use PGP.<br>
-----BEGIN PGP SIGNATURE-----<br>
<br>
iQIcBAEBCgAGBQJY1UH/<wbr>AAoJEAYDai9lH2mw2QYQALDLBxjdO5<wbr>WTG7VXfuAE476p<=
br>
D3o1MMGw23tb+<wbr>DFUO5WV6aFqfy3VSxbVXz6UuWbj6kH<wbr>gp3ys6qxg5TX0Dy8tKSZM<=
br>
V28kovuS/<wbr>pfen4gTxw1FCNff7YVW1R8QX+<wbr>cSYxSD5EoEaTbpIPgi8zMusDxUVZk2<=
br>
WG3ItoyvkLvoNIYGDcU3gR3UkjDS5l<wbr>OPiHu5BKSj1dEiibOXhr8JEBCznfUS<wbr>yxCG<=
br>
TjVRJaUPlwCU06nad8jAZiDrsW3l86<wbr>6iNkBKaMzMavYuMLvCGIdRkbf54B2Z<wbr>lIT/<=
br>
S/owusxqeIdQpydi/<wbr>3ydnrqyeWo3znMnn+<wbr>oOvdvfYEHKLts6gar3Zv8cZ40yYSIE<=
br>
z7C7GQFIo5TYDUNOk+<wbr>2VE7NNtdX39Wj3gJql/<wbr>305miaIt0qMsf1D30ODjePwyxUQ<=
br>
LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/<wbr>tFm3kx0PunptJaZT8d9EgMeHREjCF4<wbr>di04A<=
br>
6Dp3Qeug41X/<wbr>zdIc2AM387QnPwmGB1TpfrY9qgvcrI<wbr>e26T6An2V5LHwVmslCX3ui<=
br>
DYAl0o5ODQqnnakF1FIrr1blMVqm7F<wbr>qDPQc1I5TfzQuxX2+x+<wbr>5zdrciPC2HUMCMQ<=
br>
jMujge5IdGL3kjEwjt+M6kqLu0/<wbr>T0fhdUetb2DWrRJUcEVoIaiUL7qLJC<wbr>+4KMR3d<=
br>
Gu3oWoE1ld+BC6At28AD<br>
=3DSSuj<br>
-----END PGP SIGNATURE-----<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div></div>
--001a1143d9fe649fb0054b7c79b2--
|