From: John Hardy <john@seebitcoin.com>
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: Malice Reactive Proof of Work Additions (MR POWA): Protecting
	Bitcoin from malicious miners
Thread-Index: AQHSoADHJYPXh2ezvUyqDSZwzGpL4g==
Sender: John Hardy <outlook_32F81FD1D1BD8CA0@outlook.com>
Date: Sat, 18 Mar 2017 16:01:08 +0000
Message-ID: <BL2PR03MB435F510935FC7E230118AD3EE380@BL2PR03MB435.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 2
x-tmn: [zAySaTH5ea9Y+jSJqgi7cZ/XA6Us0fqM]
x-microsoft-exchange-diagnostics: 1; BY2NAM03HT064;
	5:SHtQXpMvkGXdVVzndxwUkN2H8U5FdTC3+1PLWJY7s7MMw2pjQCYHbc/yDnK2ncMVrSSk7p3iKIIeYWSVljsJdXjj14CGLOdk7meIN9OjwDi+3bkMMml1kB1cH8TmFO9Oo7snVYRUUjUNudwtu2rzGw==;
	24:9TCwfoJ8Grxgq3iD0AEsNPxs9oa3Ttz3e5E8b3hS/2X7Uv/G+4pS6MpdJgHbOZQA5Iv3p2ueEnmyv99cHEWfPj/Qe499IWh00BWcsNEgVOI=;
	7:TwJ2BgtvxZobN6ZjwHght/vqD/oHkvLlS+86NyA4J/MRohUkoiQ06HQY/1z9F55CcdZtOhxn3tDa87Kv8h6f3ZPvStyL9bx0HuuyUmq+WMWT7ULzf+Q+xlbpDp66xvb+FVBcyy4kLYM4a3EVwYVGd9rap5cD4JjtBhVoPLBcE71E/H6pz7sirUTW+XNuN3tPxfWY/MjquVkhkuM8IRsK2DUIZjv/ES/I/2wWTblQxd/3rfVkrZJTrX6ycLzJBM+6kQgWV1t1BhE7EgxZYfcJJHssm0CfmZDwplm0InC/4Ak2o3Mxj7zuj6W8Ra6uD35T
x-incomingheadercount: 41
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900017);
	DIR:OUT; SFP:1102; SCL:1; SRVR:BY2NAM03HT064;
	H:BL2PR03MB435.namprd03.prod.outlook.com; FPR:; SPF:None;
	LANG:en; 
x-ms-office365-filtering-correlation-id: 23c5707f-8f30-47d5-5c76-08d46e17fe14
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320039)(2017031322039)(1601125254)(1603101448)(1701031045);
	SRVR:BY2NAM03HT064; 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0;
	RULEID:(432015281)(444000031); SRVR:BY2NAM03HT064; BCL:0; PCL:0;
	RULEID:; SRVR:BY2NAM03HT064; 
x-forefront-prvs: 0250B840C1
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BL2PR03MB435F510935FC7E230118AD3EE380BL2PR03MB435namprd_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Mar 2017 16:01:08.7289 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM03HT064
X-OriginalArrivalTime: 18 Mar 2017 16:01:16.0127 (UTC)
	FILETIME=[DFBC4EF0:01D2A000]
X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW,RCVD_IN_PSBL 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 14:50:15 +0000
Subject: [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: Sat, 18 Mar 2017 16:01:17 -0000

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

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.

--_000_BL2PR03MB435F510935FC7E230118AD3EE380BL2PR03MB435namprd_
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">
<p></p>
<div>I=92m very worried about the state of miner centralisation in Bitcoin.=
</div>
<div><br>
</div>
<div>I always felt the centralising effects of ASIC manufacturing would res=
olve themselves once the first mover advantage had been exhausted and the i=
ndustry had the opportunity to mature.</div>
<div><br>
</div>
<div>I had always assumed initial centralisation would be harmless since mi=
ners 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 coe=
rced 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 a=
ctions by any party able to exert influence over a substantial portion of S=
HA256 hardware.</div>
<div><br>
</div>
<div>Inspired by UASF, I believe we should implement a Malicious miner Reac=
tive Proof of Work Additions (MR POWA).</div>
<div><br>
</div>
<div>This would be a hard fork activated in response to a malicious attempt=
 by a hashpower majority to introduce a contentious hard fork.</div>
<div><br>
</div>
<div>The activation would occur once a fork was detected violating protocol=
 (likely oversize blocks) with a majority of hashpower. The threshold and d=
uration for activation would need to be carefully considered.</div>
<div><br>
</div>
<div>I don=92t think we should eliminate SHA256 as a hashing method and cha=
nge POW entirely. That would be throwing the baby out with the bathwater an=
d hurt the non-malicious miners who have invested in hardware, making it ha=
rder to gain their support.</div>
<div><br>
</div>
<div>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 met=
hods) would also be positive for decentralisation. Initial difficulty could=
 simply be an estimated portion of existing infrastructure.</div>
<div><br>
</div>
<div>This example would mean 4 proofs of work with 40 minute block target d=
ifficulty 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 particula=
r method does not dramatically impact the functioning of the network betwee=
n difficulty adjustments. This also adds protection from attacks by the mal=
icious SHA256 hashpower which could
 even be required to wait until all other methods have found a block before=
 being allowed to hash again.</div>
<div><br>
</div>
<div>50% hashing time would mean that the cost of electricity in relation t=
o hardware would fall by 50%, reducing some of the centralising impact of s=
ubsidised or inexpensive electricity in some regions over others.</div>
<div><br>
</div>
<div>Such a hard fork could also, counter-intuitively, introduce a block si=
ze increase since while we=92re hard forking it makes sense to minimise the=
 number of future hard forks where possible. It could also activate SegWit =
if it hasn=92t already.</div>
<div><br>
</div>
<div>The beauty of this method is that it creates a huge risk to any malici=
ous actor trying to abuse their position. Ideally, MR POWA would just serve=
 as a deterrent and never activate.</div>
<div><br>
</div>
<div>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-upgr=
aded nodes, would be of no economic significance: a vestigial chain immedia=
tely abandoned with no miner incentive.</div>
<div><br>
</div>
<div>I think this would be a great way to help prevent malicious use of has=
hpower to harm the network. This is the beauty of Bitcoin: for any road blo=
ck that emerges the economic majority can always find a way around.</div>
<p></p>
</div>
</body>
</html>

--_000_BL2PR03MB435F510935FC7E230118AD3EE380BL2PR03MB435namprd_--