Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 68F6F8D4 for ; Mon, 20 Mar 2017 18:02:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f182.google.com (mail-pf0-f182.google.com [209.85.192.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 958EA24F for ; Mon, 20 Mar 2017 18:02:53 +0000 (UTC) Received: by mail-pf0-f182.google.com with SMTP id p189so45917497pfp.1 for ; Mon, 20 Mar 2017 11:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=KSGE5DyFvvOonRDXMvqTtm9l1Zz59iBMTKleGoaoOy0=; b=DtxP6wcJqAe4nk+UTpbPeFeiS37A4IZGZtnw1BtEEA03Pa8SZGD7/1FLW5WTh2jHf0 svnLgsUmnnzVRloE9p+zky1K9aNNXf3UqB/K2Pu19MgYYWhR6tPSiBKvnjXVpfW5OFqP G2QCvkQGOcf5uoICmMrnKdoQoQYtVDyH9Fmx5Dhf3CzA2ZKBmu9pMK9kG08nydc1XzA7 pvX4eeKuQEOdwBaLhNZsiBKM5lh8c7D4W+e0/As+PkFndMMm1ZtrW41hA2SojtNDfoNX p5+LAhuikiPYkpvJrfJzsLYBiWZnm3PeBtM5E/ej8lVVKfZOVSdR1uj6HaJNobK6Bj8j Yw3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=KSGE5DyFvvOonRDXMvqTtm9l1Zz59iBMTKleGoaoOy0=; b=P9x2hQpt8/o9oIHDhv9VZpdxqj0N5Es6rLPftwXBXpreFAtTQkpbQ0GOpwmAL9xRK2 3wfzRSgguCHjXVfAOsXhhQ29p3SuGKfuWOAucEOvdsLNzkVefebfeGizcBTAZ+eA3/i8 rK7XSNPCLusHTBRRJWN8+w4KAi4hgkJN6f7O30R6Ke6IoP7h9cbIwOCVFuAG14+akEn7 Do+Rj2jidWaAFEPdy6OhuDyo9FCN2lnuw7pVMg3HjcEHEwYQ72m/0JcrqaOFtRDCsxF6 DVfF+QBg+GMe9IdouVHdFRi+5Hwofw6xF9UNv9t/pT08rf5cVPByMvzBm6uob04l5pwM HQnA== X-Gm-Message-State: AFeK/H0eiu8gUl0jFaMqCwjEFXWjzLjSaCdtPM6FcI+D/1uIm+DFlfrocYnkdvnt5JG1mVWothJUc9cp7saVJw== X-Received: by 10.98.7.203 with SMTP id 72mr33756978pfh.197.1490032973184; Mon, 20 Mar 2017 11:02:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.162.208 with HTTP; Mon, 20 Mar 2017 11:02:52 -0700 (PDT) In-Reply-To: References: From: Nick ODell Date: Mon, 20 Mar 2017 12:02:52 -0600 Message-ID: To: Andrew Johnson , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a1143e10412045d054b2d56b3 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham 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 18:22:34 +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 18:02:54 -0000 --001a1143e10412045d054b2d56b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Chain work currently means the expected number of sha256d evaluations needed to build a chain. Given that these hash functions are not equally hard, 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 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 whi= m? > > 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 since > the beginning. > > On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I=E2=80=99m very worried about the state of miner centralisation in Bitc= oin. >> >> I always felt the centralising effects of ASIC manufacturing 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 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 to the security of Bitcoin and preemptive action needs to be >> taken 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 activated in response to a malicious attempt b= y >> 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 >> duration for activation would need to be carefully considered. >> >> I don=E2=80=99t think we should eliminate SHA256 as a hashing method and= change >> POW entirely. That would be throwing the baby out with the bathwater and >> hurt 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 implementatio= ns. >> 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 methods) would also be positive for >> decentralisation. Initial difficulty could simply be an estimated portio= n >> of existing infrastructure. >> >> This example would mean 4 proofs of work with 40 minute block target >> difficulty for each. There could also be a rule that two different proof= s >> 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 sudde= n >> gain or drop in hashpower from a particular method does not dramatically >> impact the functioning of the network between difficulty adjustments. Th= is >> also adds protection from attacks by the malicious SHA256 hashpower whic= h >> could even be required to wait until all other methods have found a bloc= k >> before being allowed to hash again. >> >> 50% hashing time would mean that the cost of electricity in relation to >> hardware would fall by 50%, reducing some of the centralising impact of >> subsidised or inexpensive electricity in some regions over others. >> >> Such a hard fork could also, counter-intuitively, introduce a block size >> increase since while we=E2=80=99re hard forking it makes sense to minimi= se the >> number of future hard forks where possible. It could also activate SegWi= t >> if it hasn=E2=80=99t already. >> >> The beauty of this method is that it creates a huge risk to any maliciou= s >> 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 b= e >> able to upgrade and MR POWA, while automatically activating on non-upgra= ded >> nodes, would be of no economic significance: a vestigial chain immediate= ly >> 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 Bitcoin: for any ro= ad >> block 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 >> > -- > Andrew Johnson > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a1143e10412045d054b2d56b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Chain work currently means the expected number of sha= 256d evaluations needed to build a chain. Given that these hash functions a= re not equally hard, 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 behind bitcoin mining. How can you reliably invest in = hardware if you have no idea when or if your profitability is going to be c= ut by 50-75% based on a whim?

You may also inadver= tently create an entirely new attack vector if 50-75% of the SHA256 hardwar= e is taken offline and purchased by an entity who intends to do harm to the= network.=C2=A0

Bitcoin only works if most miners = are honest, this has been known since the beginning.=C2=A0

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

I=E2=80=99m very worried abo= ut 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 belie= ve 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 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=E2=80=99t think we sho= uld eliminate SHA256 as a hashing method and change POW entirely. That woul= d be throwing the baby out with the bathwater and hurt the non-malicious mi= ners 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 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 met= hods) would also be positive for decentralisation. Initial difficulty could= simply be an estimated portion of existing 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 hardw= are 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 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=E2=80= =99re hard forking it makes sense to minimise the number of future hard for= ks where possible. It could also activate SegWit if it hasn=E2=80=99t alrea= dy.

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 ince= ntive.

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


--001a1143e10412045d054b2d56b3--