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 DA1239FA for ; Mon, 20 Mar 2017 15:46:32 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from COL004-OMC3S11.hotmail.com (col004-omc3s11.hotmail.com [65.55.34.149]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 84AD91F5 for ; Mon, 20 Mar 2017 15:46:31 +0000 (UTC) Received: from NAM02-BL2-obe.outbound.protection.outlook.com ([65.55.34.136]) by COL004-OMC3S11.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 20 Mar 2017 08:46:30 -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=dIRxyx/PJogZvZpxhqkQKtXSMXXp0Q6OrpVQeNwiM/Q=; b=nifXbpdXErs4iNd4z1T18KsVwYV9MuEG9QS7gej0ruTssxvbXs1q7/3x2wT7U0v9NbuR8cCaFDtkcOcNzA+uxA5zX+SUT4+xTmRpuRjqaQDSFpKl5wuzxzoPfuXIEjZMLMyMhOhq81Ub2gk8E3Cn7Kus3bKaseS24jNY9kLAY3+oPqO4kfuWkBzSTBFpYx8UOoDezrsJho1H1E9S9K1u9wwQLUTxCSWxnxTs/rjUpKLf5U0qqgVDgccQOEN3nMtAomWtvR6aY7AZpF+0nkSDj9LKOJnAeMQuxreaT9Ptkg1ztL1Tm3ak1StAIoZDNztEgKQKUOknBBmyme7ihqRx0g== Received: from SN1NAM02FT027.eop-nam02.prod.protection.outlook.com (10.152.72.54) by SN1NAM02HT061.eop-nam02.prod.protection.outlook.com (10.152.73.70) 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 15:46:29 +0000 Received: from BL2PR03MB435.namprd03.prod.outlook.com (10.152.72.56) by SN1NAM02FT027.mail.protection.outlook.com (10.152.72.99) 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 15:46: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 15:46:29 +0000 From: John Hardy To: Andrew Johnson , Bitcoin Protocol Discussion Thread-Topic: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners Thread-Index: AQHSoADHJYPXh2ezvUyqDSZwzGpL4qGd3+iAgAABHP0= Sender: John Hardy Date: Mon, 20 Mar 2017 15:46:28 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; gmail.com; dmarc=none action=none header.from=seebitcoin.com; x-incomingtopheadermarker: OriginalChecksum:F568E8D36405075B6B6CC999AEDA234E529A1BC67BDB4784CCB141C1539C7E9C; UpperCasedChecksum:8BDC370FED98A409B0688F5FAE4B607F807A2F82D7AED86F0255B1AF76A67E2A; SizeAsReceived:8440; Count:43 x-ms-exchange-messagesentrepresentingtype: 2 x-tmn: [VWx0S/VZLXpdtmHLa52WRDstlkDBiNih] x-microsoft-exchange-diagnostics: 1; SN1NAM02HT061; 5:JJcfw1L9EzCLrOLfUljKdZTPfHzF5aZvbbWKNyXGZxhd75SYELiJfheBetB1X/IvmEhYOsS+iWXuI+xe7PNeTWKKCtA+/t64DQf+JWuuY3Q4BZ4RsthN4F8xv24Gr8g/gLUSuVGpwcdzW0ROT5Kj6Q==; 24:WFIes8aFGM3q3JEbj9tuF4eSZDTfbjtKBrKJt8drwN9k/wjtheb+w22jMzs/6aODYeiH6KGP4rgG9guyyZyFvCTzNve5WOOPhhOiUF0C4YU=; 7:g0ZVnWjGCMNfR0rUrUiIE+Yz/LZro0yabtXoKdFsOiZKg1uYVMELa1grb2VBN4g/mJs1/HmAQpVLPBiXs7ol0Q3ZxHWG41zHeiHE9IhjSfS6bbFf8D7sOKgQcZYiPaAYxE1ZYOipw1mLsrbdQlNUjgkutI3c82nWD9rr7zvO5VuDpvCH9csxhuXsjyZng6ILKmy0114SRUE2jZzLZbbu/I2LNI/N38ZsurSOxYut+j8etXJ7fwdq9RWoBWJJbNiz2QW2x5r75PD+R8zfupJ+NfuPIWqwC7C5vqiBFP1q1AOCjwqDhEQF8tfPE8+oDpkH x-incomingheadercount: 43 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900017); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM02HT061; H:BL2PR03MB435.namprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: b111a303-166e-407b-37c2-08d46fa8466a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(1603101448)(1601125254)(1701031045); SRVR:SN1NAM02HT061; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015281)(444000031); SRVR:SN1NAM02HT061; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM02HT061; x-forefront-prvs: 02524402D6 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0BL2PR03MB435namprd_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 15:46:28.9515 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT061 X-OriginalArrivalTime: 20 Mar 2017 15:46:30.0953 (UTC) FILETIME=[24F4F990:01D2A191] 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, RCVD_IN_DNSWL_NONE 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 15:50:02 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 15:46:33 -0000 --_000_BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0BL2PR03MB435namprd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > By doing this you're significantly changing the economic incentives behin= d bitcoin mining. How can you reliably invest in hardware if you have no id= ea when or if your profitability is going to be cut by 50-75% based on a wh= im? Of course, that's why this is a last resort, successfully activated only in= response to a contentious hard fork. If it succeeds just once it should he= lp prevent the same situation occurring in the future. > 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 int= ends to do harm to the network. How so? If you have four proof of work methods, that 50-75% of SHA256 hashp= ower would equate to 13-18% of total hashpower. If you can harm the network= with this much hashpower bitcoin was DOA. ________________________________ From: Andrew Johnson Sent: Monday, March 20, 2017 3:38:01 PM To: Bitcoin Protocol Discussion; John Hardy Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA= ): Protecting Bitcoin from malicious miners 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 > 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 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Andrew Johnson --_000_BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0BL2PR03MB435namprd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

> By do= ing this you're significantly changing the economic incentives behind bitco= in 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?


Of course, that= 's why this is a last resort, successfully activated only in response to a = contentious hard fork. If it succeeds just once it should help prevent the = same situation occurring in the future.


> You may also inadverten= tly create an entirely new attack vector if 50-75% of the SHA256 hardware i= s taken offline and purchased by an entity who intends to do harm to the network. 

How so? If you have four proof of work methods, that 50-75% of SHA256 hashp= ower would equate to 13-18% of total hashpower. If you can harm the network= with this much hashpower bitcoin was DOA.

From: Andrew Johnson <an= drew.johnson83@gmail.com>
Sent: Monday, March 20, 2017 3:38:01 PM
To: Bitcoin Protocol Discussion; John Hardy
Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (= MR POWA): Protecting Bitcoin from malicious miners
 
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?

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. 

Bitcoin only works if most miners are honest, this has been known sinc= e the beginning. 

On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:

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

I always felt the centralising effects of ASIC man= ufacturing would resolve themselves once the first mover advantage had been= exhausted and the industry 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 n= ot consider the risk of a single entity with sufficient power and either po= or, malicious or coerced decision making. I now believe that such centralisation poses a huge risk to the se= curity of Bitcoin and preemptive action needs to be taken to protect the ne= twork from malicious actions by any party able to exert influence over a su= bstantial 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 har= d fork.

The activation would occur once a fork was detecte= d violating protocol (likely oversize blocks) with a majority of hashpower.= The threshold and duration for activation would need to be carefully consi= dered.

I don=92t think we should eliminate SHA256 as a ha= shing method and change POW entirely. That would be throwing the baby out w= ith the bathwater and hurt the non-malicious miners who have invested in ha= rdware, 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 alt= coin implementations. As an example we could add Scrypt, Ethash and Equihas= h. Much of the code and mining infrastructure already exists. Diversification of hardware (a mix of CPU and memory inten= sive methods) would also be positive for decentralisation. Initial difficul= ty could simply be an estimated portion of existing infrastructure.

This example would mean 4 proofs of work with 40 m= inute block target difficulty for each. There could also be a rule that two= different proofs of work must find a block before a method can start hashi= ng again. This means there would only be 50% of hardware hashing at a time, and a sudden gain or drop in hashpow= er from a particular method does not dramatically impact the functioning of= the network between difficulty adjustments. This also adds protection from= attacks by the malicious SHA256 hashpower which could even be required to wait until all other methods hav= e found a block before being allowed to hash again.

50% hashing time would mean that the cost of elect= ricity in relation to hardware would fall by 50%, reducing some of the cent= ralising impact of subsidised or inexpensive electricity in some regions ov= er others.

Such a hard fork could also, counter-intuitively, = introduce a block size increase since while we=92re hard forking it makes s= ense to minimise the number of future hard forks where possible. It could a= lso activate SegWit if it hasn=92t already.

The beauty of this method is that it creates a hug= e risk to any malicious actor trying to abuse their position. Ideally, MR P= OWA would just serve as a deterrent and never activate.

If consensus were to form around a hard fork in th= e future nodes would be able to upgrade and MR POWA, while automatically ac= tivating on non-upgraded nodes, would be of no economic significance: a ves= tigial chain immediately abandoned with no miner incentive.

I think this would be a great way to help prevent = malicious use of hashpower to harm the network. This is the beauty of Bitco= in: for any road block that emerges the economic majority can always find a= way around.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linu= xfoundation.org/mailman/listinfo/bitcoin-dev
--
Andrew Johnson

--_000_BL2PR03MB435F8B16B15BA7E0992DCA5EE3A0BL2PR03MB435namprd_--