path: root/70/f861bc73efa292d71fa052a104b833b14eec00

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 F3164BC4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Mar 2017 21:29:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from NAM01-SN1-obe.outbound.protection.outlook.com
	(mail-oln040092002035.outbound.protection.outlook.com [40.92.2.35])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B9CF11A5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Mar 2017 21:29:30 +0000 (UTC)
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=C8cHAE3qmyl3uC+EGZSrvNl54MADW3HjuMYPDcSYJf0=;
	b=eGWyWoEoeo/VSQEwiouYtQTyEExJmyoEDb8BbXrz8LLkhA4E/Jnu6+klkD31U5tIsMtcvJLQNYnGDzUSvkWAD7WOsNFpiVw1qrimFsExKfZJbS+ubSoa6sliUizoOv8tXEnIFeCdG/0ZD8DPxQyCm3wyPFg0flDVeW0/sK62aCSW5LGRhomody3P0yxLgQscO9pchCUWBt1IfObRApeTde7h2/giH8TVAUYU5Y6nB/OItZ7sGU9X25JqOuCHzsKrSuTENdVW5sBxADffE9yOb9ivzsmZuTRkiSAwxgN67WMCMHL90FAcpy+/8vQnGFlhtD20Niyior0mhfUKAuysGA==
Received: from BN3NAM01FT005.eop-nam01.prod.protection.outlook.com
	(10.152.66.58) by BN3NAM01HT137.eop-nam01.prod.protection.outlook.com
	(10.152.67.218) 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 21:29:29 +0000
Received: from BL2PR03MB435.namprd03.prod.outlook.com (10.152.66.58) by
	BN3NAM01FT005.mail.protection.outlook.com (10.152.66.163) 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 21:29: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 21:29:29 +0000
From: John Hardy <john@seebitcoin.com>
To: 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+iAgAAoeACAADlDQg==
Sender: John Hardy <outlook_32F81FD1D1BD8CA0@outlook.com>
Date: Mon, 20 Mar 2017 21:29:29 +0000
Message-ID: <BL2PR03MB4354CBF603056F44BD98C61EE3A0@BL2PR03MB435.namprd03.prod.outlook.com>
References: <BL2PR03MB435F510935FC7E230118AD3EE380@BL2PR03MB435.namprd03.prod.outlook.com>
	<CAAy62_K5ePDuvVn8=DtwJX6ek00Z_r4u9LyA0W11vgZmQ=zzDg@mail.gmail.com>,
	<CANN4kmdMcbQ9pYC44a02+wzzVzoMt8n5TAL=Z3bRaBkT_6Vnpg@mail.gmail.com>
In-Reply-To: <CANN4kmdMcbQ9pYC44a02+wzzVzoMt8n5TAL=Z3bRaBkT_6Vnpg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: lists.linuxfoundation.org; dkim=none (message not
	signed) header.d=none; lists.linuxfoundation.org; dmarc=none action=none
	header.from=seebitcoin.com;
x-incomingtopheadermarker: OriginalChecksum:8E13ACE3203764A0DA99A237CA5540A047A1B7E1A0B2A403EAF09AD08B20A02E;
	UpperCasedChecksum:A2947F6C1BB373B64EC71471E9726A567BB18861DF863B2D6B0414A83A45E181;
	SizeAsReceived:8459; Count:43
x-ms-exchange-messagesentrepresentingtype: 2
x-tmn: [qJI3JE7h4raBbOZqnjjR+UwrS5Axr50o]
x-microsoft-exchange-diagnostics: 1; BN3NAM01HT137;
	5:TcAoVSWnx2HWP32Y64OlZBmKd5cwe8UIvVSbqbbdEARJ0JT9QQvKRGaRLSUaLWXvoRKleUGEnCYPwG58agobeTW5QDRWdxPVEEQOiUxndB5ZU9iGyZ9Xm5g0/NXL5kjs3uItOQgXCb5oR7ThAhsaGw==;
	24:Uvr+kqhyTYCF3xnz6MYplQe1HBchV9UpVGZCZya6OIy/Dx9jStJVE08T2w5zveGlnN5OYQLe97MRjg/4OQE624XC6jwqRtrcd0jXVm/IPPU=;
	7:iCHuhpJLIsk1WNDrtriC2Fd1JHVlB4Yfte4byqR2UZFabXiCFUvzVPJcJSXYe4NDQGjFeNk/6fEsWVxcO1F2WI1pkrUwODogUj5EUdZGGqrWnoz76GZyIGfv2cif4fZeo7Q18p8+ZOw/yo9/Qlb/8ypMJtNtwAEFdO8JPKgUwzB7TeAaYE6XBevlKgTgMGPGKNkLt53ptUt3oY0Dh2K1Cu6gSOtJcS3PAX99JJAEhZiA0/5Z2iSG6bNwEvOn4syRWdPUuahFrbGN0AfDEsCbKRwzrzx534g9F/RVHn2WO0Q0qHgJayBh0hXJXL11vGZt
x-incomingheadercount: 43
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98900017);
	DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT137;
	H:BL2PR03MB435.namprd03.prod.outlook.com; FPR:; SPF:None;
	LANG:en; 
x-ms-office365-filtering-correlation-id: 20536890-ab92-4d5b-ec4b-08d46fd8312d
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(1603101448)(1601125254)(1701031045);
	SRVR:BN3NAM01HT137; 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031);
	SRVR:BN3NAM01HT137; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT137; 
x-forefront-prvs: 02524402D6
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BL2PR03MB4354CBF603056F44BD98C61EE3A0BL2PR03MB435namprd_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 21:29:29.1652 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT137
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,
	RP_MATCHES_RCVD 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 21:29:32 -0000

--_000_BL2PR03MB4354CBF603056F44BD98C61EE3A0BL2PR03MB435namprd_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

> Chain work currently means the expected number of sha256d evaluations nee=
ded to build a chain. Given that these hash functions are not equally hard,=
 what should the new definition of chain work be?

They're not equally hard, but they can be equally relative.

If you had 4 proofs of work you can weigh them each at 25% and compare the =
overall chain weight from there, shouldn't be difficult.

Initially, some hardware would have an advantage, but over time the market =
will always average itself out.


________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@li=
sts.linuxfoundation.org> on behalf of Nick ODell via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org>
Sent: Monday, March 20, 2017 6:02:52 PM
To: Andrew Johnson; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA=
): Protecting Bitcoin from malicious miners

Chain work currently means the expected number of sha256d evaluations neede=
d to build a chain. Given that these hash functions are not equally hard, w=
hat should the new definition of chain work be?

On Mon, Mar 20, 2017 at 9:38 AM, Andrew Johnson via bitcoin-dev <bitcoin-de=
v@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> =
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=
?

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


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev



--_000_BL2PR03MB4354CBF603056F44BD98C61EE3A0BL2PR03MB435namprd_
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">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Arial,Helvetica,sans-serif;" dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Arial,Helvetica,sans-serif;" dir=3D"ltr">
<p></p>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 16px; margin-top: 0px; margin-bottom: 0px;">
&gt;&nbsp;<font face=3D"Calibri,Arial,Helvetica,sans-serif" size=3D"2"><spa=
n style=3D"font-size: 16px;">Chain work currently means the expected number=
 of sha256d evaluations needed to build a chain. Given that these hash func=
tions are not equally hard, what should the new
 definition of chain work be?</span></font></div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 16px; margin-top: 0px; margin-bottom: 0px;">
<font face=3D"Calibri,Arial,Helvetica,sans-serif" size=3D"2"><span style=3D=
"font-size: 16px;"><br>
</span></font></div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 16px; margin-top: 0px; margin-bottom: 0px;">
<font face=3D"Calibri,Arial,Helvetica,sans-serif" size=3D"2"><span style=3D=
"font-size: 16px;">They're not equally hard, but they can be equally relati=
ve.</span></font></div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 16px; margin-top: 0px; margin-bottom: 0px;">
<font face=3D"Calibri,Arial,Helvetica,sans-serif" size=3D"2"><span style=3D=
"font-size: 16px;"><br>
</span></font></div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 16px; margin-top: 0px; margin-bottom: 0px;">
If you had 4 proofs of work you can weigh them each at 25% and compare the =
overall chain weight from there, shouldn't be difficult.</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 16px; margin-top: 0px; margin-bottom: 0px;">
<br>
</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 16px; margin-top: 0px; margin-bottom: 0px;">
Initially, some hardware would have an advantage, but over time the market =
will always average itself out.</div>
<br>
<p></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> bitcoin-dev-bounces@l=
ists.linuxfoundation.org &lt;bitcoin-dev-bounces@lists.linuxfoundation.org&=
gt; on behalf of Nick ODell via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoun=
dation.org&gt;<br>
<b>Sent:</b> Monday, March 20, 2017 6:02:52 PM<br>
<b>To:</b> Andrew Johnson; Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (=
MR POWA): Protecting Bitcoin from malicious miners</font>
<div>&nbsp;</div>
</div>
<div>
<div dir=3D"ltr">
<div>Chain work currently means the expected number of sha256d evaluations =
needed to build a chain. Given that these hash functions are not equally ha=
rd, what should the new definition of chain work be?</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Mon, Mar 20, 2017 at 9:38 AM, Andrew Johnson =
via bitcoin-dev
<span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<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.&nbsp;</div>
<div><br>
</div>
<div>Bitcoin only works if most miners are honest, this has been known sinc=
e the beginning.&nbsp;</div>
<div><br>
</div>
<div>
<div class=3D"gmail_quote">
<div>
<div class=3D"h5">
<div>On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
</div>
</div>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div>
<div class=3D"h5">
<div class=3D"m_-9016794004783773829gmail_msg">
<div id=3D"m_-9016794004783773829m_6451335042833672793divtagdefaultwrapper"=
 style=3D"font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,=
sans-serif" class=3D"m_-9016794004783773829gmail_msg">
<p class=3D"m_-9016794004783773829gmail_msg"></p>
<div class=3D"m_-9016794004783773829gmail_msg">I=92m very worried about the=
 state of miner centralisation in Bitcoin.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">I always felt the centralisi=
ng effects of ASIC manufacturing would resolve themselves once the first mo=
ver advantage had been exhausted and the industry had the opportunity to ma=
ture.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">I had always assumed initial=
 centralisation would be harmless since miners have no incentive to harm th=
e network. This does not consider the risk of a single entity with sufficie=
nt 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 tak=
en to protect the network from malicious actions by any party able to exert=
 influence over a substantial portion
 of SHA256 hardware.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">Inspired by UASF, I believe =
we should implement a Malicious miner Reactive Proof of Work Additions (MR =
POWA).</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">This would be a hard fork ac=
tivated in response to a malicious attempt by a hashpower majority to intro=
duce a contentious hard fork.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">The activation would occur o=
nce 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.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">I don=92t think we should el=
iminate SHA256 as a hashing method and change POW entirely. That would be t=
hrowing the baby out with the bathwater and hurt the non-malicious miners w=
ho have invested in hardware, making
 it harder to gain their support.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">Instead I believe we should =
introduce multiple new proofs of work that are already established and prov=
en within existing altcoin implementations. As an example we could add Scry=
pt, 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 dec=
entralisation. Initial difficulty could simply be an estimated portion of e=
xisting infrastructure.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">This example would mean 4 pr=
oofs of work with 40 minute block target difficulty for each. There could a=
lso 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 im=
pact the functioning of the network between difficulty adjustments. This al=
so adds protection from attacks
 by the malicious SHA256 hashpower which could even be required to wait unt=
il all other methods have found a block before being allowed to hash again.=
</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">50% hashing time would mean =
that the cost of electricity in relation to hardware would fall by 50%, red=
ucing some of the centralising impact of subsidised or inexpensive electric=
ity in some regions over others.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">Such a hard fork could also,=
 counter-intuitively, introduce a block size increase since while we=92re h=
ard forking it makes sense to minimise the number of future hard forks wher=
e possible. It could also activate SegWit
 if it hasn=92t already.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">The beauty of this method is=
 that it creates a huge risk to any malicious actor trying to abuse their p=
osition. Ideally, MR POWA would just serve as a deterrent and never activat=
e.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">If consensus were to form ar=
ound 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 econom=
ic significance: a vestigial chain
 immediately abandoned with no miner incentive.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">I think this would be a grea=
t 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 majo=
rity can always find a way around.</div>
<p class=3D"m_-9016794004783773829gmail_msg"></p>
</div>
</div>
</div>
</div>
______________________________<wbr>_________________<br class=3D"m_-9016794=
004783773829gmail_msg">
bitcoin-dev mailing list<br class=3D"m_-9016794004783773829gmail_msg">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"m_-901679=
4004783773829gmail_msg" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfound=
ation.org</a><br class=3D"m_-9016794004783773829gmail_msg">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" class=3D"m_-9016794004783773829gmail_msg" target=3D"_bla=
nk">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>de=
v</a><span class=3D"HOEnZb"><font color=3D"#888888"><br class=3D"m_-9016794=
004783773829gmail_msg">
</font></span></blockquote>
</div>
</div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div dir=3D"ltr">-- <br>
</div>
<div data-smartmail=3D"gmail_signature">Andrew Johnson<br>
<div><br>
</div>
</div>
</font></span><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>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</body>
</html>

--_000_BL2PR03MB4354CBF603056F44BD98C61EE3A0BL2PR03MB435namprd_--