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 F3164BC4 for ; Mon, 20 Mar 2017 21:29:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-oln040092002035.outbound.protection.outlook.com [40.92.2.35]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B9CF11A5 for ; Mon, 20 Mar 2017 21:29:30 +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=C8cHAE3qmyl3uC+EGZSrvNl54MADW3HjuMYPDcSYJf0=; b=eGWyWoEoeo/VSQEwiouYtQTyEExJmyoEDb8BbXrz8LLkhA4E/Jnu6+klkD31U5tIsMtcvJLQNYnGDzUSvkWAD7WOsNFpiVw1qrimFsExKfZJbS+ubSoa6sliUizoOv8tXEnIFeCdG/0ZD8DPxQyCm3wyPFg0flDVeW0/sK62aCSW5LGRhomody3P0yxLgQscO9pchCUWBt1IfObRApeTde7h2/giH8TVAUYU5Y6nB/OItZ7sGU9X25JqOuCHzsKrSuTENdVW5sBxADffE9yOb9ivzsmZuTRkiSAwxgN67WMCMHL90FAcpy+/8vQnGFlhtD20Niyior0mhfUKAuysGA== Received: from BN3NAM01FT005.eop-nam01.prod.protection.outlook.com (10.152.66.58) by BN3NAM01HT137.eop-nam01.prod.protection.outlook.com (10.152.67.218) 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 21:29:29 +0000 Received: from BL2PR03MB435.namprd03.prod.outlook.com (10.152.66.58) by BN3NAM01FT005.mail.protection.outlook.com (10.152.66.163) 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:29: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 21:29:29 +0000 From: John Hardy To: Bitcoin Protocol Discussion Thread-Topic: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners Thread-Index: AQHSoADHJYPXh2ezvUyqDSZwzGpL4qGd3+iAgAAoeACAADlDQg== Sender: John Hardy Date: Mon, 20 Mar 2017 21:29:29 +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: 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:8E13ACE3203764A0DA99A237CA5540A047A1B7E1A0B2A403EAF09AD08B20A02E; UpperCasedChecksum:A2947F6C1BB373B64EC71471E9726A567BB18861DF863B2D6B0414A83A45E181; SizeAsReceived:8459; Count:43 x-ms-exchange-messagesentrepresentingtype: 2 x-tmn: [qJI3JE7h4raBbOZqnjjR+UwrS5Axr50o] x-microsoft-exchange-diagnostics: 1; BN3NAM01HT137; 5:TcAoVSWnx2HWP32Y64OlZBmKd5cwe8UIvVSbqbbdEARJ0JT9QQvKRGaRLSUaLWXvoRKleUGEnCYPwG58agobeTW5QDRWdxPVEEQOiUxndB5ZU9iGyZ9Xm5g0/NXL5kjs3uItOQgXCb5oR7ThAhsaGw==; 24:Uvr+kqhyTYCF3xnz6MYplQe1HBchV9UpVGZCZya6OIy/Dx9jStJVE08T2w5zveGlnN5OYQLe97MRjg/4OQE624XC6jwqRtrcd0jXVm/IPPU=; 7:iCHuhpJLIsk1WNDrtriC2Fd1JHVlB4Yfte4byqR2UZFabXiCFUvzVPJcJSXYe4NDQGjFeNk/6fEsWVxcO1F2WI1pkrUwODogUj5EUdZGGqrWnoz76GZyIGfv2cif4fZeo7Q18p8+ZOw/yo9/Qlb/8ypMJtNtwAEFdO8JPKgUwzB7TeAaYE6XBevlKgTgMGPGKNkLt53ptUt3oY0Dh2K1Cu6gSOtJcS3PAX99JJAEhZiA0/5Z2iSG6bNwEvOn4syRWdPUuahFrbGN0AfDEsCbKRwzrzx534g9F/RVHn2WO0Q0qHgJayBh0hXJXL11vGZt x-incomingheadercount: 43 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98900017); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT137; H:BL2PR03MB435.namprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 20536890-ab92-4d5b-ec4b-08d46fd8312d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(1603101448)(1601125254)(1701031045); SRVR:BN3NAM01HT137; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BN3NAM01HT137; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT137; x-forefront-prvs: 02524402D6 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL2PR03MB4354CBF603056F44BD98C61EE3A0BL2PR03MB435namprd_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2017 21:29:29.1652 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT137 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, RP_MATCHES_RCVD 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: Wed, 22 Mar 2017 19:51:49 +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 21:29:32 -0000 --_000_BL2PR03MB4354CBF603056F44BD98C61EE3A0BL2PR03MB435namprd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > Chain work currently means the expected number of sha256d evaluations nee= ded to build a chain. Given that these hash functions are not equally hard,= what should the new definition of chain work be? They're not equally hard, but they can be equally relative. If you had 4 proofs of work you can weigh them each at 25% and compare the = overall chain weight from there, shouldn't be difficult. Initially, some hardware would have an advantage, but over time the market = will always average itself out. ________________________________ From: bitcoin-dev-bounces@lists.linuxfoundation.org on behalf of Nick ODell via bitcoin-dev Sent: Monday, March 20, 2017 6:02:52 PM To: Andrew Johnson; Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA= ): Protecting Bitcoin from malicious miners Chain work currently means the expected number of sha256d evaluations neede= d to build a chain. Given that these hash functions are not equally hard, w= hat should the new definition of chain work be? On Mon, Mar 20, 2017 at 9:38 AM, Andrew Johnson via bitcoin-dev > = wrote: 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --_000_BL2PR03MB4354CBF603056F44BD98C61EE3A0BL2PR03MB435namprd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

> Chain work currently means the expected number= of sha256d evaluations needed to build a chain. Given that these hash func= tions are not equally hard, what should the new definition of chain work be?

They're not equally hard, but they can be equally relati= ve.

If you had 4 proofs of work you can weigh them each at 25% and compare the = overall chain weight from there, shouldn't be difficult.

Initially, some hardware would have an advantage, but over time the market = will always average itself out.

From: bitcoin-dev-bounces@l= ists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.org&= gt; on behalf of Nick ODell via bitcoin-dev <bitcoin-dev@lists.linuxfoun= dation.org>
Sent: Monday, March 20, 2017 6:02:52 PM
To: Andrew Johnson; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (= MR POWA): Protecting Bitcoin from malicious miners
 
Chain work currently means the expected number of sha256d evaluations = needed to build a chain. Given that these hash functions are not equally ha= rd, what should the new definition of chain work be?

On Mon, Mar 20, 2017 at 9:38 AM, Andrew Johnson = via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> = wrote:
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.linuxfoundation.org> wrote:

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

I always felt the centralisi= ng effects of ASIC manufacturing would resolve themselves once the first mo= ver advantage had been exhausted and the industry had the opportunity to ma= ture.

I had always assumed initial= centralisation would be harmless since miners have no incentive to harm th= e network. This does not consider the risk of a single entity with sufficie= nt power and either poor, malicious or coerced decision making. I now believe that such centralisation poses a= huge risk to the security of Bitcoin and preemptive action needs to be tak= en to protect the network from malicious actions by any party able to exert= influence over 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 ac= tivated in response to a malicious attempt by a hashpower majority to intro= duce a contentious hard fork.

The activation would occur o= nce a fork was detected violating protocol (likely oversize blocks) with a = majority of hashpower. The threshold and duration for activation would need= to be carefully considered.

I don=92t think we should el= iminate SHA256 as a hashing method and change POW entirely. That would be t= hrowing the baby out with the bathwater and hurt the non-malicious miners w= ho 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 prov= en within existing altcoin implementations. As an example we could add Scry= pt, Ethash and Equihash. Much of the code and mining infrastructure already exists. Diversification of hardware= (a mix of CPU and memory intensive methods) would also be positive for dec= entralisation. Initial difficulty could simply be an estimated portion of e= xisting infrastructure.

This example would mean 4 pr= oofs of work with 40 minute block target difficulty for each. There could a= lso 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 particular method does not dramatically im= pact the functioning of the network between difficulty adjustments. This al= so adds protection from attacks by the malicious SHA256 hashpower which could even be required to wait unt= il 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 to hardware would fall by 50%, red= ucing some of the centralising impact of subsidised or inexpensive electric= ity in some regions over others.

Such a hard fork could also,= counter-intuitively, introduce a block size increase since while we=92re h= ard forking it makes sense to minimise the number of future hard forks wher= e 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 actor trying to abuse their p= osition. Ideally, MR POWA would just serve as a deterrent and never activat= e.

If consensus were to form ar= ound a hard fork in the future nodes would be able to upgrade and MR POWA, = while automatically activating on non-upgraded nodes, would be of no econom= ic significance: a vestigial chain immediately abandoned with no miner incentive.

I think this would be a grea= t way to help prevent malicious use of hashpower to harm the network. This = is the beauty of Bitcoin: for any road block that emerges the economic majo= rity can always find a way around.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfound= ation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-de= v
--
Andrew Johnson


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


--_000_BL2PR03MB4354CBF603056F44BD98C61EE3A0BL2PR03MB435namprd_--