path: root/79/6f94755e6aa379fd06cf23308616f24a505a88

Return-Path: <nickodell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 68F6F8D4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Mar 2017 18:02:53 +0000 (UTC)
Received: by mail-pf0-f182.google.com with SMTP id p189so45917497pfp.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAAy62_K5ePDuvVn8=DtwJX6ek00Z_r4u9LyA0W11vgZmQ=zzDg@mail.gmail.com>
References: <BL2PR03MB435F510935FC7E230118AD3EE380@BL2PR03MB435.namprd03.prod.outlook.com>
	<CAAy62_K5ePDuvVn8=DtwJX6ek00Z_r4u9LyA0W11vgZmQ=zzDg@mail.gmail.com>
From: Nick ODell <nickodell@gmail.com>
Date: Mon, 20 Mar 2017 12:02:52 -0600
Message-ID: <CANN4kmdMcbQ9pYC44a02+wzzVzoMt8n5TAL=Z3bRaBkT_6Vnpg@mail.gmail.com>
To: Andrew Johnson <andrew.johnson83@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr"><div>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?</div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Mar=
 20, 2017 at 9:38 AM, Andrew Johnson via bitcoin-dev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div>By doing this you&#39;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?</div><div><br></div><div>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</div><div><br></div><div>Bitcoin only works if most miners =
are honest, this has been known since the beginning.=C2=A0</div><div><br></=
div><div><div class=3D"gmail_quote"><div><div class=3D"h5"><div>On Mon, Mar=
 20, 2017 at 9:50 AM John Hardy via bitcoin-dev &lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>=
linuxfoundation.org</a>&gt; wrote:<br></div></div></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div><div class=3D"h5">




<div class=3D"m_-9016794004783773829gmail_msg">
<div id=3D"m_-9016794004783773829m_6451335042833672793divtagdefaultwrapper"=
 style=3D"font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,=
sans-serif" class=3D"m_-9016794004783773829gmail_msg">
<p class=3D"m_-9016794004783773829gmail_msg"></p>
<div class=3D"m_-9016794004783773829gmail_msg">I=E2=80=99m very worried abo=
ut the state of miner centralisation in Bitcoin.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">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.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">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.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">Inspired by UASF, I believe =
we should implement a Malicious miner Reactive Proof of Work Additions (MR =
POWA).</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">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.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">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.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">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.=
</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">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.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">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.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">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.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">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.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">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.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">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.</div>
<div class=3D"m_-9016794004783773829gmail_msg"><br class=3D"m_-901679400478=
3773829gmail_msg">
</div>
<div class=3D"m_-9016794004783773829gmail_msg">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.</div>
<p class=3D"m_-9016794004783773829gmail_msg"></p>
</div>
</div></div></div>

______________________________<wbr>_________________<br class=3D"m_-9016794=
004783773829gmail_msg">
bitcoin-dev mailing list<br class=3D"m_-9016794004783773829gmail_msg">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"m_-901679=
4004783773829gmail_msg" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfound=
ation.org</a><br class=3D"m_-9016794004783773829gmail_msg">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" class=3D"m_-9016794004783773829gmail_msg" target=3D"_bla=
nk">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>de=
v</a><span class=3D"HOEnZb"><font color=3D"#888888"><br class=3D"m_-9016794=
004783773829gmail_msg">
</font></span></blockquote></div></div><span class=3D"HOEnZb"><font color=
=3D"#888888"><div dir=3D"ltr">-- <br></div><div data-smartmail=3D"gmail_sig=
nature">Andrew Johnson<br><div><br></div></div>
</font></span><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a1143e10412045d054b2d56b3--