From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A53EC898 for ; Sat, 18 Mar 2017 16:01:17 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from BAY004-OMC1S26.hotmail.com (bay004-omc1s26.hotmail.com [65.54.190.37]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A4EDB141 for ; Sat, 18 Mar 2017 16:01:16 +0000 (UTC) Received: from NAM03-BY2-obe.outbound.protection.outlook.com ([65.54.190.60]) by BAY004-OMC1S26.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 18 Mar 2017 09:01:16 -0700 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=mPnvoHDPkahXwWFUeliMvmejCmUUH3KdnOGgceGZX4o=; b=vI5xLezZDwZmmIjOBv2o1Hkvcpx2ApoDdtN6M+KWDWEP2OsUM999EPf1NcRVVBBGPq5HvIJ7pF2WaMgIwJWxZ5qEsdC/G8M5I9g8KNxBik1GA7buRnS608oSwE0gQC7O5knCtrNnH8/xrZxgkr1wDIQGLTNm7IrhtGmQh8aTUWZ2PNLaKYOg089epBAT16eU2DOifvUYOEKD80+eQqMrBtwZdIXhptoB7/330MOB2AiZ1z0BeD8HIRUd5ml6Pj3eIKyWThNMyCafL9/BhtqIfkFldUUuUrtizSa5BarAWzuHWypQx+2sYudZOdCkbjju0E6Na/pfwNepzZhCjNw59w== Received: from BY2NAM03FT055.eop-NAM03.prod.protection.outlook.com (10.152.84.60) by BY2NAM03HT064.eop-NAM03.prod.protection.outlook.com (10.152.85.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.977.7; Sat, 18 Mar 2017 16:01:15 +0000 Received: from BL2PR03MB435.namprd03.prod.outlook.com (10.152.84.53) by BY2NAM03FT055.mail.protection.outlook.com (10.152.85.245) 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; Sat, 18 Mar 2017 16:01:15 +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; Sat, 18 Mar 2017 16:01:09 +0000 From: John Hardy To: "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 Date: Sat, 18 Mar 2017 16:01:08 +0000 Message-ID: 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:D25C598331FE4057E72A83731694860D6CC2148D5D5DF995802A9289303F38B9; UpperCasedChecksum:16F59F2A0D6B8107E8D4636D0C47CBD18F11CA83E27E6609755D283B1217070A; SizeAsReceived:8115; Count:41 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

I=92m very worried about the state of miner centralisation in Bitcoin.=

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.

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.

Inspired by UASF, I believe we should implement a Malicious miner Reac= tive 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 d= uration for activation would need to be carefully considered.

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.

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.

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.

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.

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.

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.

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.

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.

--_000_BL2PR03MB435F510935FC7E230118AD3EE380BL2PR03MB435namprd_--