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 E3FC2BC4 for ; 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 ; 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 To: Bram Cohen , Bitcoin Protocol Discussion Thread-Topic: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners Thread-Index: AQHSoADHJYPXh2ezvUyqDSZwzGpL4qGeBMeAgAA22nI= Sender: John Hardy Date: Mon, 20 Mar 2017 21:23:17 +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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 > 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 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --_000_BL2PR03MB435E077052146EA1706A5A9EE3A0BL2PR03MB435namprd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

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


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.


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?


> Using many PoWs is a ba= d idea, that generally gets the worst of everything rather than the best.


Upon what do yo= u base this assertion?


From: Bram Cohen <bram@b= ittorrent.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 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;

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.

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.

On Sat, Mar 18, 2017 at 9:01 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 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.


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


--_000_BL2PR03MB435E077052146EA1706A5A9EE3A0BL2PR03MB435namprd_--