From: John Hardy <john@seebitcoin.com>
To: Bram Cohen <bram@bittorrent.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: AQHSoADHJYPXh2ezvUyqDSZwzGpL4qGeBMeAgAA22nI=
Sender: John Hardy <outlook_32F81FD1D1BD8CA0@outlook.com>
Date: Mon, 20 Mar 2017 21:23:17 +0000
Message-ID: <BL2PR03MB435E077052146EA1706A5A9EE3A0@BL2PR03MB435.namprd03.prod.outlook.com>
References: <BL2PR03MB435F510935FC7E230118AD3EE380@BL2PR03MB435.namprd03.prod.outlook.com>,
	<CA+KqGkpc5DVe75g8M9=MnCGCPO4vnHdHXeZx4T3n7GMCK6MoEw@mail.gmail.com>
In-Reply-To: <CA+KqGkpc5DVe75g8M9=MnCGCPO4vnHdHXeZx4T3n7GMCK6MoEw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 2
x-tmn: [9mdw4nfXkUOP+lOiGHWvt3yvQ9kGfh5G]
x-microsoft-exchange-diagnostics: 1; BY2NAM01HT065;
	5:pLrzqIsry6sXPszxU+cbok8x5E8n4t0cfgGh/+P9aWD6gLbf3kzQYvUxsHmFcGeNShae5V4ywVxRMOE7rghjznNZlXDwB/+95DrHTJ/McdIbytFIaurEnEkmZ8z1HldRd0GZsMnpV10tB0kF8pSc9Q==;
	24:ISBcA1Vzc9DCv8vjclrIEAewgQYfX1fyBhZtcNWSE0V7+9R2nS8gNfEraMDw1Pldqnx0RcrdGu86/ct2HOXSY+1jcRO6GLJN1xjwfMQsbLc=;
	7:G40xf9XbeJ4nT6hcbIv6ru2S+FBAzuWh2gyg2jINBSkwbqtDLuG6aTsGz5JnrnBzyqs6CQkOAnOSAiprJH177p85bvb33mhBaP3qQoNIBTAFYB2/fxzdfhWmEaIl5sekUNYKvSW6otNLXwzpZRvTkocDMqJOJVqrDj+PMMxoj3HTMp000L4Vzhuji6Hwg/fRsQJ8yrnuef7mKAeQI31TyVK1IJHaaSgD5MFxdjwDzvkzrRtjePAjH1h5pBwlfFILkiR/Qx139sMNyzSEwuK7+lH0SuoDoG30ZT0jP24YHw4kp0ahNeaXTe8s0yoh+FXC
x-incomingheadercount: 43
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98900017);
	DIR:OUT; SFP:1901; SCL:1; SRVR:BY2NAM01HT065;
	H:BL2PR03MB435.namprd03.prod.outlook.com; FPR:; SPF:None;
	LANG:en; 
x-ms-office365-filtering-correlation-id: 2faf3ee6-049a-4636-3494-08d46fd75399
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320039)(2017031322039)(1603101448)(1601125344)(1701031045);
	SRVR:BY2NAM01HT065; 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031);
	SRVR:BY2NAM01HT065; BCL:0; PCL:0; RULEID:; SRVR:BY2NAM01HT065; 
x-forefront-prvs: 02524402D6
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BL2PR03MB435E077052146EA1706A5A9EE3A0BL2PR03MB435namprd_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 21:23:17.3132 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM01HT065
X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_PSBL, RP_MATCHES_RCVD autolearn=no version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 20 Mar 2017 21:27:54 +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:23:21 -0000

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

> It's possible to switch PoW algorithms with a soft fork rather than a har=
d fork.


You put forward an interesting idea if it could work, but in the adversaria=
l emergency where an entity is contentiously using a POW monopoly, a hard f=
ork would likely be a far easier and more efficient response.


That said unless I'm missing something I can't see how it would work withou=
t still requiring a hard fork since you still need an SHA256 block of suffi=
cient difficulty for the existing network to accept. If the holders of SHA2=
56 hardware didn't want to make their equipment obsolete (likely) they simp=
ly would refuse to mine these alternate PoW blocks. I guess a UASF would be=
 an option to force this, but without co-operation (Turkeys voting for Chri=
stmas is the British idiom) you'd still end up requiring a hard fork proof =
of difficulty change, which kind of defeats the purpose?


> Using many PoWs is a bad idea, that generally gets the worst of everythin=
g rather than the best.


Upon what do you base this assertion?


________________________________
From: Bram Cohen <bram@bittorrent.com>
Sent: Monday, March 20, 2017 5:49:59 PM
To: John Hardy; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA=
): Protecting Bitcoin from malicious miners

It's possible to switch PoW algorithms with a soft fork rather than a hard =
fork. You make it so that there are two different PoWs, the old one and the=
 new one, and each old-style block has to reference a new-style block and c=
ontain the exact same transactions. The new work rule is that the weighted =
geometric mean of the quality of the new-style block and the old-style bloc=
k has to exceed the work threshold, with the weighting starting almost enti=
rely on the old-style block and shifting gradually over to the new-style bl=
ock until in the end the amount of work to generate the old-style block is =
completely trivial and doesn't matter any more.

The most interesting part of the whole thing is keeping it so that the new =
work limit is consistently the limiting factor on mining difficulty rather =
than the old one interfering. Getting that to work right is an interesting =
problem which I'm not sure how to do off the top of my head but I believe i=
s manageable.

Using many PoWs is a bad idea, that generally gets the worst of everything =
rather than the best. There are two ways to go with a PoW, either make it a=
s advantaged on custom hardware as possible, which means sha3, or make it a=
s difficult to ASIC as possible, which at this point means cuckoo since the=
re's already hardware for equihash.

On Sat, Mar 18, 2017 at 9:01 AM, John Hardy via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrot=
e:

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



--_000_BL2PR03MB435E077052146EA1706A5A9EE3A0BL2PR03MB435namprd_
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>&gt;&nbsp;<span style=3D"color: rgb(33, 33, 33); font-size: 15px;">It's =
possible to switch PoW algorithms with a soft fork rather than a hard fork.=
</span></p>
<p><span style=3D"color: rgb(33, 33, 33); font-size: 15px;"><br>
</span></p>
<p><font color=3D"#212121"><span style=3D"font-size: 15px;">You put forward=
 an interesting idea if it could work, but in the adversarial emergency whe=
re an entity is contentiously using a POW monopoly, a hard fork would likel=
y be a far easier and more efficient
 response.</span></font></p>
<p><font color=3D"#212121"><span style=3D"font-size: 15px;"><br>
</span></font></p>
<p><font color=3D"#212121"><span style=3D"font-size: 15px;">That said unles=
s I'm missing something I can't see how it would work without still requiri=
ng a hard fork since you still need an SHA256&nbsp;block of sufficient diff=
iculty for the existing network to accept.
 If the holders of SHA256 hardware didn't want to make their equipment obso=
lete (likely) they simply would refuse to mine these alternate PoW blocks. =
I guess a UASF would be an option to force this, but without co-operation&n=
bsp;(Turkeys voting for Christmas is
 the British idiom) you'd still end up requiring a hard fork proof of diffi=
culty change, which kind of defeats the purpose?</span></font></p>
<p><font color=3D"#212121"><span style=3D"font-size: 15px;"><br>
</span></font></p>
<p><font color=3D"#212121"><span style=3D"font-size: 15px;">&gt;&nbsp;<span=
 style=3D"color: rgb(33, 33, 33); font-size: 15px;">Using many PoWs is a ba=
d idea, that generally gets the worst of everything rather than the best.</=
span></span></font></p>
<p><font color=3D"#212121"><span style=3D"font-size: 15px;"><br>
</span></font></p>
<p><font color=3D"#212121"><span style=3D"font-size: 15px;">Upon what do yo=
u base this assertion?</span></font></p>
<p><font color=3D"#212121"><span style=3D"font-size: 15px;"><br>
</span></font></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> Bram Cohen &lt;bram@b=
ittorrent.com&gt;<br>
<b>Sent:</b> Monday, March 20, 2017 5:49:59 PM<br>
<b>To:</b> John Hardy; 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">It's possible to switch PoW algorithms with a soft fork ra=
ther than a hard fork. You make it so that there are two different PoWs, th=
e old one and the new one, and each old-style block has to reference a new-=
style block and contain the exact
 same transactions. The new work rule is that the weighted geometric mean o=
f the quality of the new-style block and the old-style block has to exceed =
the work threshold, with the weighting starting almost entirely on the old-=
style block and shifting gradually
 over to the new-style block until in the end the amount of work to generat=
e the old-style block is completely trivial and doesn't matter any more.&nb=
sp;
<div><br>
</div>
<div>The most interesting part of the whole thing is keeping it so that the=
 new work limit is consistently the limiting factor on mining difficulty ra=
ther than the old one interfering. Getting that to work right is an interes=
ting problem which I'm not sure
 how to do off the top of my head but I believe is manageable.</div>
<div><br>
</div>
<div>Using many PoWs is a bad idea, that generally gets the worst of everyt=
hing rather than the best. There are two ways to go with a PoW, either make=
 it as advantaged on custom hardware as possible, which means sha3, or make=
 it as difficult to ASIC as possible,
 which at this point means cuckoo since there's already hardware for equiha=
sh.</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Sat, Mar 18, 2017 at 9:01 AM, John Hardy 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 dir=3D"ltr">
<div id=3D"m_7235471870693523876divtagdefaultwrapper" style=3D"font-size:12=
pt;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>
</div>
<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>
</body>
</html>

--_000_BL2PR03MB435E077052146EA1706A5A9EE3A0BL2PR03MB435namprd_--