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
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
|
Return-Path: <outlook_32F81FD1D1BD8CA0@outlook.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id DA1239FA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Mar 2017 15:46:32 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from COL004-OMC3S11.hotmail.com (col004-omc3s11.hotmail.com
[65.55.34.149])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 84AD91F5
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Mar 2017 15:46:31 +0000 (UTC)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com ([65.55.34.136])
by COL004-OMC3S11.hotmail.com over TLS secured channel with
Microsoft SMTPSVC(7.5.7601.23008); Mon, 20 Mar 2017 08:46:30 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com;
s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
bh=dIRxyx/PJogZvZpxhqkQKtXSMXXp0Q6OrpVQeNwiM/Q=;
b=nifXbpdXErs4iNd4z1T18KsVwYV9MuEG9QS7gej0ruTssxvbXs1q7/3x2wT7U0v9NbuR8cCaFDtkcOcNzA+uxA5zX+SUT4+xTmRpuRjqaQDSFpKl5wuzxzoPfuXIEjZMLMyMhOhq81Ub2gk8E3Cn7Kus3bKaseS24jNY9kLAY3+oPqO4kfuWkBzSTBFpYx8UOoDezrsJho1H1E9S9K1u9wwQLUTxCSWxnxTs/rjUpKLf5U0qqgVDgccQOEN3nMtAomWtvR6aY7AZpF+0nkSDj9LKOJnAeMQuxreaT9Ptkg1ztL1Tm3ak1StAIoZDNztEgKQKUOknBBmyme7ihqRx0g==
Received: from SN1NAM02FT027.eop-nam02.prod.protection.outlook.com
(10.152.72.54) by SN1NAM02HT061.eop-nam02.prod.protection.outlook.com
(10.152.73.70) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.7;
Mon, 20 Mar 2017 15:46:29 +0000
Received: from BL2PR03MB435.namprd03.prod.outlook.com (10.152.72.56) by
SN1NAM02FT027.mail.protection.outlook.com (10.152.72.99) with Microsoft
SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
15.1.977.7 via Frontend Transport; Mon, 20 Mar 2017 15:46:29 +0000
Received: from BL2PR03MB435.namprd03.prod.outlook.com ([10.141.92.24]) by
BL2PR03MB435.namprd03.prod.outlook.com ([10.141.92.24]) with mapi id
15.01.0977.013; Mon, 20 Mar 2017 15:46:29 +0000
From: John Hardy <john@seebitcoin.com>
To: Andrew Johnson <andrew.johnson83@gmail.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA):
Protecting Bitcoin from malicious miners
Thread-Index: AQHSoADHJYPXh2ezvUyqDSZwzGpL4qGd3+iAgAABHP0=
Sender: John Hardy <outlook_32F81FD1D1BD8CA0@outlook.com>
Date: Mon, 20 Mar 2017 15:46:28 +0000
Message-ID: <BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0@BL2PR03MB435.namprd03.prod.outlook.com>
References: <BL2PR03MB435F510935FC7E230118AD3EE380@BL2PR03MB435.namprd03.prod.outlook.com>,
<CAAy62_K5ePDuvVn8=DtwJX6ek00Z_r4u9LyA0W11vgZmQ=zzDg@mail.gmail.com>
In-Reply-To: <CAAy62_K5ePDuvVn8=DtwJX6ek00Z_r4u9LyA0W11vgZmQ=zzDg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed)
header.d=none; gmail.com;
dmarc=none action=none header.from=seebitcoin.com;
x-incomingtopheadermarker: OriginalChecksum:F568E8D36405075B6B6CC999AEDA234E529A1BC67BDB4784CCB141C1539C7E9C;
UpperCasedChecksum:8BDC370FED98A409B0688F5FAE4B607F807A2F82D7AED86F0255B1AF76A67E2A;
SizeAsReceived:8440; Count:43
x-ms-exchange-messagesentrepresentingtype: 2
x-tmn: [VWx0S/VZLXpdtmHLa52WRDstlkDBiNih]
x-microsoft-exchange-diagnostics: 1; SN1NAM02HT061;
5:JJcfw1L9EzCLrOLfUljKdZTPfHzF5aZvbbWKNyXGZxhd75SYELiJfheBetB1X/IvmEhYOsS+iWXuI+xe7PNeTWKKCtA+/t64DQf+JWuuY3Q4BZ4RsthN4F8xv24Gr8g/gLUSuVGpwcdzW0ROT5Kj6Q==;
24:WFIes8aFGM3q3JEbj9tuF4eSZDTfbjtKBrKJt8drwN9k/wjtheb+w22jMzs/6aODYeiH6KGP4rgG9guyyZyFvCTzNve5WOOPhhOiUF0C4YU=;
7:g0ZVnWjGCMNfR0rUrUiIE+Yz/LZro0yabtXoKdFsOiZKg1uYVMELa1grb2VBN4g/mJs1/HmAQpVLPBiXs7ol0Q3ZxHWG41zHeiHE9IhjSfS6bbFf8D7sOKgQcZYiPaAYxE1ZYOipw1mLsrbdQlNUjgkutI3c82nWD9rr7zvO5VuDpvCH9csxhuXsjyZng6ILKmy0114SRUE2jZzLZbbu/I2LNI/N38ZsurSOxYut+j8etXJ7fwdq9RWoBWJJbNiz2QW2x5r75PD+R8zfupJ+NfuPIWqwC7C5vqiBFP1q1AOCjwqDhEQF8tfPE8+oDpkH
x-incomingheadercount: 43
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900017);
DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM02HT061;
H:BL2PR03MB435.namprd03.prod.outlook.com; FPR:; SPF:None;
LANG:en;
x-ms-office365-filtering-correlation-id: b111a303-166e-407b-37c2-08d46fa8466a
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(1603101448)(1601125254)(1701031045);
SRVR:SN1NAM02HT061;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
RULEID:(432015281)(444000031); SRVR:SN1NAM02HT061; BCL:0; PCL:0;
RULEID:; SRVR:SN1NAM02HT061;
x-forefront-prvs: 02524402D6
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
boundary="_000_BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0BL2PR03MB435namprd_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 15:46:28.9515 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT061
X-OriginalArrivalTime: 20 Mar 2017 15:46:30.0953 (UTC)
FILETIME=[24F4F990:01D2A191]
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 20 Mar 2017 15:50:02 +0000
Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR
POWA): Protecting Bitcoin from malicious miners
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: Mon, 20 Mar 2017 15:46:33 -0000
--_000_BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0BL2PR03MB435namprd_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
> By doing this you're significantly changing the economic incentives behin=
d bitcoin mining. How can you reliably invest in hardware if you have no id=
ea when or if your profitability is going to be cut by 50-75% based on a wh=
im?
Of course, that's why this is a last resort, successfully activated only in=
response to a contentious hard fork. If it succeeds just once it should he=
lp prevent the same situation occurring in the future.
> You may also inadvertently create an entirely new attack vector if 50-75%=
of the SHA256 hardware is taken offline and purchased by an entity who int=
ends to do harm to the network.
How so? If you have four proof of work methods, that 50-75% of SHA256 hashp=
ower would equate to 13-18% of total hashpower. If you can harm the network=
with this much hashpower bitcoin was DOA.
________________________________
From: Andrew Johnson <andrew.johnson83@gmail.com>
Sent: Monday, March 20, 2017 3:38:01 PM
To: Bitcoin Protocol Discussion; John Hardy
Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA=
): Protecting Bitcoin from malicious miners
By doing this you're significantly changing the economic incentives behind =
bitcoin mining. How can you reliably invest in hardware if you have no idea=
when or if your profitability is going to be cut by 50-75% based on a whim=
?
You may also inadvertently create an entirely new attack vector if 50-75% o=
f the SHA256 hardware is taken offline and purchased by an entity who inten=
ds to do harm to the network.
Bitcoin only works if most miners are honest, this has been known since the=
beginning.
On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev <bitcoin-dev@lis=
ts.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote=
:
I=92m very worried about the state of miner centralisation in Bitcoin.
I always felt the centralising effects of ASIC manufacturing would resolve =
themselves once the first mover advantage had been exhausted and the indust=
ry had the opportunity to mature.
I had always assumed initial centralisation would be harmless since miners =
have no incentive to harm the network. This does not consider the risk of a=
single entity with sufficient power and either poor, malicious or coerced =
decision making. I now believe that such centralisation poses a huge risk t=
o the security of Bitcoin and preemptive action needs to be taken to protec=
t the network from malicious actions by any party able to exert influence o=
ver a substantial portion of SHA256 hardware.
Inspired by UASF, I believe we should implement a Malicious miner Reactive =
Proof of Work Additions (MR POWA).
This would be a hard fork activated in response to a malicious attempt by a=
hashpower majority to introduce a contentious hard fork.
The activation would occur once a fork was detected violating protocol (lik=
ely oversize blocks) with a majority of hashpower. The threshold and durati=
on for activation would need to be carefully considered.
I don=92t think we should eliminate SHA256 as a hashing method and change P=
OW entirely. That would be throwing the baby out with the bathwater and hur=
t the non-malicious miners who have invested in hardware, making it harder =
to gain their support.
Instead I believe we should introduce multiple new proofs of work that are =
already established and proven within existing altcoin implementations. As =
an example we could add Scrypt, Ethash and Equihash. Much of the code and m=
ining infrastructure already exists. Diversification of hardware (a mix of =
CPU and memory intensive methods) would also be positive for decentralisati=
on. Initial difficulty could simply be an estimated portion of existing inf=
rastructure.
This example would mean 4 proofs of work with 40 minute block target diffic=
ulty for each. There could also be a rule that two different proofs of work=
must find a block before a method can start hashing again. This means ther=
e would only be 50% of hardware hashing at a time, and a sudden gain or dro=
p in hashpower from a particular method does not dramatically impact the fu=
nctioning of the network between difficulty adjustments. This also adds pro=
tection from attacks by the malicious SHA256 hashpower which could even be =
required to wait until all other methods have found a block before being al=
lowed to hash again.
50% hashing time would mean that the cost of electricity in relation to har=
dware would fall by 50%, reducing some of the centralising impact of subsid=
ised or inexpensive electricity in some regions over others.
Such a hard fork could also, counter-intuitively, introduce a block size in=
crease since while we=92re hard forking it makes sense to minimise the numb=
er of future hard forks where possible. It could also activate SegWit if it=
hasn=92t already.
The beauty of this method is that it creates a huge risk to any malicious a=
ctor trying to abuse their position. Ideally, MR POWA would just serve as a=
deterrent and never activate.
If consensus were to form around a hard fork in the future nodes would be a=
ble to upgrade and MR POWA, while automatically activating on non-upgraded =
nodes, would be of no economic significance: a vestigial chain immediately =
abandoned with no miner incentive.
I think this would be a great way to help prevent malicious use of hashpowe=
r to harm the network. This is the beauty of Bitcoin: for any road block th=
at emerges the economic majority can always find a way around.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Andrew Johnson
--_000_BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0BL2PR03MB435namprd_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body>
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Arial,Helvetica,sans-serif;" dir=3D"ltr">
<p>> <span style=3D"color: rgb(33, 33, 33); font-size: 15px;">By do=
ing this you're significantly changing the economic incentives behind bitco=
in mining. How can you reliably invest in hardware if you have no idea when=
or if your profitability is going to be cut
by 50-75% based on a whim?</span></p>
<p><span style=3D"color: rgb(33, 33, 33); font-size: 15px;"><br>
</span></p>
<p><span style=3D"color: rgb(33, 33, 33); font-size: 15px;">Of course, that=
's why this is a last resort, successfully activated only in response to a =
contentious hard fork. If it succeeds just once it should help prevent the =
same situation occurring in the future.</span></p>
<p><span style=3D"color: rgb(33, 33, 33); font-size: 15px;"><br>
</span></p>
<p><span style=3D"color: rgb(33, 33, 33); font-size: 15px;">> <span=
style=3D"color: rgb(33, 33, 33); font-size: 15px;">You may also inadverten=
tly create an entirely new attack vector if 50-75% of the SHA256 hardware i=
s taken offline and purchased by an entity who
intends to do harm to the network. <br>
<br>
How so? If you have four proof of work methods, that 50-75% of SHA256 hashp=
ower would equate to 13-18% of total hashpower. If you can harm the network=
with this much hashpower bitcoin was DOA.</span></span></p>
</div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> Andrew Johnson <an=
drew.johnson83@gmail.com><br>
<b>Sent:</b> Monday, March 20, 2017 3:38:01 PM<br>
<b>To:</b> Bitcoin Protocol Discussion; John Hardy<br>
<b>Subject:</b> Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (=
MR POWA): Protecting Bitcoin from malicious miners</font>
<div> </div>
</div>
<div>
<div>By doing this you're significantly changing the economic incentives be=
hind bitcoin mining. How can you reliably invest in hardware if you have no=
idea when or if your profitability is going to be cut by 50-75% based on a=
whim?</div>
<div><br>
</div>
<div>You may also inadvertently create an entirely new attack vector if 50-=
75% of the SHA256 hardware is taken offline and purchased by an entity who =
intends to do harm to the network. </div>
<div><br>
</div>
<div>Bitcoin only works if most miners are honest, this has been known sinc=
e the beginning. </div>
<div><br>
</div>
<div>
<div class=3D"gmail_quote">
<div>On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>> wrote:<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div class=3D"gmail_msg">
<div id=3D"m_6451335042833672793divtagdefaultwrapper" style=3D"font-size:12=
pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" class=3D"g=
mail_msg">
<p class=3D"gmail_msg"></p>
<div class=3D"gmail_msg">I=92m very worried about the state of miner centra=
lisation in Bitcoin.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">I always felt the centralising effects of ASIC man=
ufacturing would resolve themselves once the first mover advantage had been=
exhausted and the industry had the opportunity to mature.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">I had always assumed initial centralisation would =
be harmless since miners have no incentive to harm the network. This does n=
ot consider the risk of a single entity with sufficient power and either po=
or, malicious or coerced decision
making. I now believe that such centralisation poses a huge risk to the se=
curity of Bitcoin and preemptive action needs to be taken to protect the ne=
twork from malicious actions by any party able to exert influence over a su=
bstantial portion of SHA256 hardware.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">Inspired by UASF, I believe we should implement a =
Malicious miner Reactive Proof of Work Additions (MR POWA).</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">This would be a hard fork activated in response to=
a malicious attempt by a hashpower majority to introduce a contentious har=
d fork.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">The activation would occur once a fork was detecte=
d violating protocol (likely oversize blocks) with a majority of hashpower.=
The threshold and duration for activation would need to be carefully consi=
dered.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">I don=92t think we should eliminate SHA256 as a ha=
shing method and change POW entirely. That would be throwing the baby out w=
ith the bathwater and hurt the non-malicious miners who have invested in ha=
rdware, making it harder to gain their
support.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">Instead I believe we should introduce multiple new=
proofs of work that are already established and proven within existing alt=
coin implementations. As an example we could add Scrypt, Ethash and Equihas=
h. Much of the code and mining infrastructure
already exists. Diversification of hardware (a mix of CPU and memory inten=
sive methods) would also be positive for decentralisation. Initial difficul=
ty could simply be an estimated portion of existing infrastructure.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">This example would mean 4 proofs of work with 40 m=
inute block target difficulty for each. There could also be a rule that two=
different proofs of work must find a block before a method can start hashi=
ng again. This means there would only
be 50% of hardware hashing at a time, and a sudden gain or drop in hashpow=
er from a particular method does not dramatically impact the functioning of=
the network between difficulty adjustments. This also adds protection from=
attacks by the malicious SHA256
hashpower which could even be required to wait until all other methods hav=
e found a block before being allowed to hash again.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">50% hashing time would mean that the cost of elect=
ricity in relation to hardware would fall by 50%, reducing some of the cent=
ralising impact of subsidised or inexpensive electricity in some regions ov=
er others.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">Such a hard fork could also, counter-intuitively, =
introduce a block size increase since while we=92re hard forking it makes s=
ense to minimise the number of future hard forks where possible. It could a=
lso activate SegWit if it hasn=92t already.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">The beauty of this method is that it creates a hug=
e risk to any malicious actor trying to abuse their position. Ideally, MR P=
OWA would just serve as a deterrent and never activate.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">If consensus were to form around a hard fork in th=
e future nodes would be able to upgrade and MR POWA, while automatically ac=
tivating on non-upgraded nodes, would be of no economic significance: a ves=
tigial chain immediately abandoned
with no miner incentive.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">I think this would be a great way to help prevent =
malicious use of hashpower to harm the network. This is the beauty of Bitco=
in: for any road block that emerges the economic majority can always find a=
way around.</div>
<p class=3D"gmail_msg"></p>
</div>
</div>
_______________________________________________<br class=3D"gmail_msg">
bitcoin-dev mailing list<br class=3D"gmail_msg">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"g=
mail_msg">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev</a><br class=3D"gmail_msg">
</blockquote>
</div>
</div>
<div dir=3D"ltr">-- <br>
</div>
<div data-smartmail=3D"gmail_signature">Andrew Johnson<br>
<div><br>
</div>
</div>
</div>
</body>
</html>
--_000_BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0BL2PR03MB435namprd_--
|