path: root/c1/ef7b726973d28b17c63840543536e1b8af4c9e

Return-Path: <andrew.johnson83@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3545BB2F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Mar 2017 16:10:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com
	[209.85.220.174])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E14A31C9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Mar 2017 16:10:43 +0000 (UTC)
Received: by mail-qk0-f174.google.com with SMTP id y76so114078768qkb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Mar 2017 09:10:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=HIBVQEYM0E7OPMuv69DmDS3sZg5pjwlJg4bIJK3fC0s=;
	b=McVCHy9wKP1TC5uy6M+ek+s0HECadl4QHQ8UrsEw6MhYtrVvN6w1M3wFiuzKfOTGhJ
	W6P40BSbc51sYd1T0Tcid0GBchVxprYPL33iQLx7srbCmBXWAL518cLOdWVyYVK1jVoV
	w1rHQEMm26wBkVn0/vqKMjpxCZoRKzfRZfXAEh1JWReAU+K5CAiluEPhq4AKVRezlRYe
	m7IOUetrF6JJnlTTK/vWEFH191QOPkVrKmm2au9CWxTMhQo2qnXgUxig+qdmbo85CaVW
	sLeLir8yJ12eS52eFT/5wVLCg59Il32Yz6nZKGgKY9I6D9l8P2cgkKsFIGkoyz6/uOkZ
	Zgcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=HIBVQEYM0E7OPMuv69DmDS3sZg5pjwlJg4bIJK3fC0s=;
	b=bvtokfThJz1ZRKEw2LM5am1p/PMUfC24J4eKuBPPurJoqtTTDAf1AV+yGRb6TMYcNO
	NxXd/zXg2ys+nTW/J5+Ut8bUNS/hx4VLD64nu+/jk8m+GoMZF6adpg0lNsk8zk0mVFyG
	Mpp7lxmrWe3l8uEKvQ4Dy5dl9XYX4E6jcjoti9BSbMoKBRb6P+qT69nuhJFKAj5QVYUf
	qdkW4D6eNP9JbQE2uOLfvVDZQTGQIeP/HOVJIeDbWci9jV/Fw+YRy4zebZs4ULKEFNor
	fv6Sr6p7uc2D2UOhIREFxieQjEUxzXlJdQp/w5MC1AYQgiIjSGhx082gY9bq7vgpWIyY
	DSzQ==
X-Gm-Message-State: AFeK/H1aT1kP8uv5F47lkhKhSn6E95JnDuhPayHI30ZWUGPq9IRpJyMfZabQdW+qvvKDPL1JhtdpuSAoIkypkA==
X-Received: by 10.55.11.141 with SMTP id 135mr24589180qkl.260.1490026242796;
	Mon, 20 Mar 2017 09:10:42 -0700 (PDT)
MIME-Version: 1.0
References: <BL2PR03MB435F510935FC7E230118AD3EE380@BL2PR03MB435.namprd03.prod.outlook.com>
	<CAAy62_K5ePDuvVn8=DtwJX6ek00Z_r4u9LyA0W11vgZmQ=zzDg@mail.gmail.com>
	<BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0@BL2PR03MB435.namprd03.prod.outlook.com>
In-Reply-To: <BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0@BL2PR03MB435.namprd03.prod.outlook.com>
From: Andrew Johnson <andrew.johnson83@gmail.com>
Date: Mon, 20 Mar 2017 16:10:32 +0000
Message-ID: <CAAy62_+6s_zxkyYuPKX5E9dEBfNntLYtNc5CYkU=VuacQCL2cw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	John Hardy <john@seebitcoin.com>
Content-Type: multipart/alternative; boundary=001a114c9358e87658054b2bc441
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM 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: Wed, 22 Mar 2017 19:51:49 +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 16:10:45 -0000

--001a114c9358e87658054b2bc441
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 20, 2017 at 10:47 AM John Hardy <john@seebitcoin.com> wrote:

> 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?


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.


This seems a lot more disruptive to the network than a simple hard fork to
increase the block size.  Compromise is the answer here, not taking our
ball and going home, in my humble opinion.

> 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.

How so? If you have four proof of work methods, that 50-75% of SHA256
hashpower would equate to 13-18% of total hashpower. If you can harm the
network with this much hashpower bitcoin was DOA.


I'm assuming the difficulty on the SHA256 PoW would drop by 50-75% as
well.  So not nearly as bad as it would be with a single PoW and that much
hardware were available to an adversary, you're correct.

How would you handle starting difficulty on the other 3 PoWs?  Seems like
it would be a race to start with, which strikes me as another potential
attack vector until the amount of hardware and price of production balances
with the price of the coin(which is likely to be volatile during this
turbulent period).  Unless you start the difficulty at a higher value, then
you're just doing centralized economic planning and hoping you got the
numbers right so that you get the right balance of security vs incentive to
do malicious things like double spends.

All the solutions that people keep positing(such as Luke's complete PoW
change) seem like they'd be a whole lot more disruptive to the network than
an EC fork would be.

Isn't the main reason that everyone is up in arms because a contentious
hard fork is dangerous?  I just don't understand how any of these solutions
are safer.

At that point we've lost our claim to fame, that changes to the protocol
are hard and you can trust that your value is safe.  What you're advocating
seems like it would result in a huge drop in hashing security.

------------------------------
*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%
of the SHA256 hardware is taken offline and purchased by an entity who
intends 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@lists.linuxfoundation.org> wrote:

I=E2=80=99m 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
industry 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
to the security of Bitcoin and preemptive action needs to be taken to
protect the network from malicious actions by any party able to exert
influence over 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
(likely oversize blocks) with a majority of hashpower. The threshold and
duration for activation would need to be carefully considered.

I don=E2=80=99t think we should eliminate SHA256 as a hashing method and ch=
ange POW
entirely. That would be throwing the baby out with the bathwater and hurt
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
mining infrastructure already exists. Diversification of hardware (a mix of
CPU and memory intensive methods) would also be positive for
decentralisation. Initial difficulty could simply be an estimated portion
of existing infrastructure.

This example would mean 4 proofs of work with 40 minute 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 hashing again. This
means there would only be 50% of hardware hashing at a time, and a sudden
gain or drop in hashpower 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 have found a block
before being allowed to hash again.

50% hashing time would mean that the cost of electricity in relation to
hardware would fall by 50%, reducing some of the centralising impact of
subsidised or inexpensive electricity in some regions over others.

Such a hard fork could also, counter-intuitively, introduce a block size
increase since while we=E2=80=99re hard forking it makes sense to minimise =
the
number of future hard forks where possible. It could also activate SegWit
if it hasn=E2=80=99t already.

The beauty of this method is that it creates a huge risk to any malicious
actor 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
able 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
hashpower to harm the network. This is the beauty of Bitcoin: for any road
block that emerges the economic majority can always find a way around.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--=20
Andrew Johnson

--=20
Andrew Johnson

--001a114c9358e87658054b2bc441
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div><div class=3D"gmail_msg"><div class=3D"gmail_quote gmail_msg"><div cla=
ss=3D"gmail_msg">On Mon, Mar 20, 2017 at 10:47 AM John Hardy &lt;<a href=3D=
"mailto:john@seebitcoin.com" class=3D"gmail_msg" target=3D"_blank">john@see=
bitcoin.com</a>&gt; wrote:<br class=3D"gmail_msg"></div><blockquote class=
=3D"gmail_quote gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div class=3D"gmail_msg"><div id=3D"m_7214346933284=
56769m_-3790314875128113150divtagdefaultwrapper" style=3D"font-size:12pt;co=
lor:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" class=3D"gmail_=
msg">
<p class=3D"gmail_msg">&gt;=C2=A0<span style=3D"color:rgb(33,33,33);font-si=
ze:15px" class=3D"gmail_msg">By doing this you&#39;re significantly changin=
g the economic incentives behind bitcoin mining. How can you reliably inves=
t 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 class=3D"gmail_msg"><span style=3D"color:rgb(33,33,33);font-size:15px" c=
lass=3D"gmail_msg"><br class=3D"gmail_msg">
</span></p>
</div></div><div class=3D"gmail_msg"><div id=3D"m_721434693328456769m_-3790=
314875128113150divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;=
font-family:Calibri,Arial,Helvetica,sans-serif" class=3D"gmail_msg"><p clas=
s=3D"gmail_msg"><span style=3D"color:rgb(33,33,33);font-size:15px" class=3D=
"gmail_msg">Of course, that&#39;s why this is a last resort, successfully a=
ctivated only in response to a contentious hard fork. If it succeeds just o=
nce it should help prevent the same situation occurring in the future.</spa=
n></p></div></div></blockquote><div class=3D"gmail_msg"><br class=3D"gmail_=
msg"></div></div></div></div><div><div class=3D"gmail_msg"><div class=3D"gm=
ail_quote gmail_msg"><div class=3D"gmail_msg">This seems a lot more disrupt=
ive to the network than a simple hard fork to increase the block size.=C2=
=A0 Compromise is the answer here, not taking our ball and going home, in m=
y humble opinion.=C2=A0</div></div></div></div><div><div class=3D"gmail_msg=
"><div class=3D"gmail_quote gmail_msg"><blockquote class=3D"gmail_quote gma=
il_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div class=3D"gmail_msg"><div id=3D"m_721434693328456769m_-37903148751=
28113150divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font-fa=
mily:Calibri,Arial,Helvetica,sans-serif" class=3D"gmail_msg"><p class=3D"gm=
ail_msg"><span style=3D"color:rgb(33,33,33);font-size:15px" class=3D"gmail_=
msg"></span></p></div></div></blockquote><blockquote class=3D"gmail_quote g=
mail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div class=3D"gmail_msg"><div id=3D"m_721434693328456769m_-379031487=
5128113150divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font-=
family:Calibri,Arial,Helvetica,sans-serif" class=3D"gmail_msg">
<p class=3D"gmail_msg"><span style=3D"color:rgb(33,33,33);font-size:15px" c=
lass=3D"gmail_msg">&gt;=C2=A0<span style=3D"color:rgb(33,33,33);font-size:1=
5px" class=3D"gmail_msg">You may also inadvertently create an entirely new =
attack vector if 50-75% of the SHA256 hardware is taken offline and purchas=
ed by an entity who
 intends to do harm to the network.=C2=A0<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
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></div></b=
lockquote><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div></div></di=
v></div><div><div class=3D"gmail_msg"><div class=3D"gmail_quote gmail_msg">=
<div class=3D"gmail_msg">I&#39;m assuming the difficulty on the SHA256 PoW =
would drop by 50-75% as well.=C2=A0 So not nearly as bad as it would be wit=
h a single PoW and that much hardware were available to an adversary, you&#=
39;re correct.</div><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div>=
<div class=3D"gmail_msg">How would you handle starting difficulty on the ot=
her 3 PoWs?=C2=A0 Seems like it would be a race to start with, which strike=
s me as another potential attack vector until the amount of hardware and pr=
ice of production balances with the price of the coin(which is likely to be=
 volatile during this turbulent period).=C2=A0 Unless you start the difficu=
lty at a higher value, then you&#39;re just doing centralized economic plan=
ning and hoping you got the numbers right so that you get the right balance=
 of security vs incentive to do malicious things like double spends.</div><=
div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><div class=3D"gmail_m=
sg">All the solutions that people keep positing(such as Luke&#39;s complete=
 PoW change) seem like they&#39;d be a whole lot more disruptive to the net=
work than an EC fork would be.</div><div class=3D"gmail_msg"><br class=3D"g=
mail_msg"></div><div class=3D"gmail_msg">Isn&#39;t the main reason that eve=
ryone is up in arms because a contentious hard fork is dangerous?=C2=A0 I j=
ust don&#39;t understand how any of these solutions are safer.</div><div cl=
ass=3D"gmail_msg"><br class=3D"gmail_msg"></div><div class=3D"gmail_msg">At=
 that point we&#39;ve lost our claim to fame, that changes to the protocol =
are hard and you can trust that your value is safe.=C2=A0 What you&#39;re a=
dvocating seems like it would result in a huge drop in hashing security.</d=
iv></div></div></div><div><div class=3D"gmail_msg"><div class=3D"gmail_quot=
e gmail_msg"><div class=3D"gmail_msg"><br class=3D"gmail_msg"></div><blockq=
uote class=3D"gmail_quote gmail_msg" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_msg"><div id=3D"m_721=
434693328456769m_-3790314875128113150divtagdefaultwrapper" style=3D"font-si=
ze:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" class=
=3D"gmail_msg"><p class=3D"gmail_msg"><span style=3D"color:rgb(33,33,33);fo=
nt-size:15px" class=3D"gmail_msg"><span style=3D"color:rgb(33,33,33);font-s=
ize:15px" class=3D"gmail_msg"></span></span></p>
</div>
<hr style=3D"display:inline-block;width:98%" class=3D"gmail_msg">
<div id=3D"m_721434693328456769m_-3790314875128113150divRplyFwdMsg" class=
=3D"gmail_msg"><font face=3D"Calibri, sans-serif" style=3D"font-size:11pt" =
color=3D"#000000" class=3D"gmail_msg"><b class=3D"gmail_msg">From:</b> Andr=
ew Johnson &lt;<a href=3D"mailto:andrew.johnson83@gmail.com" class=3D"gmail=
_msg" target=3D"_blank">andrew.johnson83@gmail.com</a>&gt;<br class=3D"gmai=
l_msg">
<b class=3D"gmail_msg">Sent:</b> Monday, March 20, 2017 3:38:01 PM<br class=
=3D"gmail_msg">
<b class=3D"gmail_msg">To:</b> Bitcoin Protocol Discussion; John Hardy<br c=
lass=3D"gmail_msg">
<b class=3D"gmail_msg">Subject:</b> Re: [bitcoin-dev] Malice Reactive Proof=
 of Work Additions (MR POWA): Protecting Bitcoin from malicious miners</fon=
t>
<div class=3D"gmail_msg">=C2=A0</div>
</div></div><div class=3D"gmail_msg">
<div class=3D"gmail_msg">
<div class=3D"gmail_msg">By doing this you&#39;re significantly changing th=
e 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?</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">You may also inadvertently create an entirely new =
attack vector if 50-75% of the SHA256 hardware is taken offline and purchas=
ed by an entity who intends to do harm to the network.=C2=A0</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">Bitcoin only works if most miners are honest, this=
 has been known since the beginning.=C2=A0</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">
<div class=3D"gmail_quote gmail_msg">
<div class=3D"gmail_msg">On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=
=3D"gmail_msg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&=
gt; wrote:<br class=3D"gmail_msg">
</div>
<blockquote class=3D"gmail_quote gmail_msg" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
<div class=3D"gmail_msg">
<div id=3D"m_721434693328456769m_-3790314875128113150m_6451335042833672793d=
ivtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font-family:Cali=
bri,Arial,Helvetica,sans-serif" class=3D"gmail_msg">
<p class=3D"gmail_msg"></p>
<div class=3D"gmail_msg">I=E2=80=99m very worried about the state of miner =
centralisation 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=E2=80=99t think we should eliminate SHA256 a=
s a hashing method and change POW entirely. That would be throwing the baby=
 out with the bathwater and hurt the non-malicious miners who have invested=
 in hardware, 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=E2=80=99re hard forking it m=
akes sense to minimise the number of future hard forks where possible. It c=
ould also activate SegWit if it hasn=E2=80=99t 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 class=3D"gmail_msg">-- <br class=3D"gmail_msg">
</div>
<div data-smartmail=3D"gmail_signature" class=3D"gmail_msg">Andrew Johnson<=
br class=3D"gmail_msg">
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
</div>
</div>
</div></blockquote></div></div></div><div dir=3D"ltr">-- <br></div><div dat=
a-smartmail=3D"gmail_signature">Andrew Johnson<br><div><br></div></div>

--001a114c9358e87658054b2bc441--