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 E3FC2BC4 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 20 Mar 2017 21:23:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-oln040092002086.outbound.protection.outlook.com [40.92.2.86]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5BE7219A for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 20 Mar 2017 21:23:19 +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=l6GdcPRloiD+BoHlNyiXr1CGkjsF/WF4B1sQsW50dBg=; b=smROtc3bquhPaNpqbkrAM+irLkHu/1GhEpcmVO1enkBLOS7NUHpxRzzpRLWtSm6Lg2QfNO41AL7cvwlbjZFXu/KyodMqfuNUd8eIzYkbhDW3st3LvDW+nBUMU0ZcsjCgCRWBjn3yBwaCUlEyjCvz/pxvsrtsjYYPD1RtG8gJRD8JcctZWZW8blm+iNK/m6LdwZBY6vGiDJcTVwbyGHuss52s3mLE2et8sldv9Q0OrWs674kZdRqFQUNVvQ58d/MFNjJKDaB51CSQnWKYZtqtrX627pb1ZjfVMvrz2uuY1KxIrA5NthMA2e/i4sy8CdkDtce5WsvBwmGytawoLI1mrg== Received: from BY2NAM01FT037.eop-nam01.prod.protection.outlook.com (10.152.68.55) by BY2NAM01HT065.eop-nam01.prod.protection.outlook.com (10.152.69.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.10; Mon, 20 Mar 2017 21:23:17 +0000 Received: from BL2PR03MB435.namprd03.prod.outlook.com (10.152.68.56) by BY2NAM01FT037.mail.protection.outlook.com (10.152.68.63) 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:23:17 +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:23:17 +0000 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-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bittorrent.com; dkim=none (message not signed) header.d=none;bittorrent.com; dmarc=none action=none header.from=seebitcoin.com; x-incomingtopheadermarker: OriginalChecksum:19B7FB831641E0E5E8BCFE67A73D83671C3A3B3244D4AD45D59BF613867D7584; UpperCasedChecksum:B622F53D1A58F3083719A672FB46CF7E95ABF40A962F1ECC33F3AAF97F6A4F50; SizeAsReceived:8425; Count:43 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>> <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 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;">> <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 <bram@b= ittorrent.com><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> </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"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o= rg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></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_--