path: root/11/c79a932df1a089cbb27228e9757da2014acd31

Return-Path: <andrew.johnson83@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A3B9394F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Mar 2017 15:38:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com
	[209.85.220.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B6B8B1C0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Mar 2017 15:38:12 +0000 (UTC)
Received: by mail-qk0-f180.google.com with SMTP id y76so113221645qkb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Mar 2017 08:38:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=3QZcqbthEcBR33/SLd/ENnZMrrh29o9o46mvyxpdIvM=;
	b=LOSC9H8QB/vGN+uI2aXJy9yM7pbGCyl2VuROY0h+9oxTDzF7kZ/vMyfvnERITzZX0T
	1WfC2KmtT2Gly2H7+PpXrXOM6j56DtLHJcuj3++k72HFq7iF9O6Y/TUnMYXSb+sSCC8H
	s/focrSSByUJVx4M7pkGQlbPJnx3AP1P1mT91hTEh4OzRJZSq8NQjxaKaYgikuBnnZon
	xq0xS6pk/nyUk/xDyxBop7ZTzVRvdw/xH9U35Z/OeK9QyVVUrz/VlAeokf8+948onQLG
	JayUK79E3Y04ffisF+6rlW1oS6qEwLVniFgf93wlCtcCbcJyK5UPq59616wE+RLAOF8t
	PUmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=3QZcqbthEcBR33/SLd/ENnZMrrh29o9o46mvyxpdIvM=;
	b=LZDNEU1X35W4PGlCZNaLn4uB+ibdUQxw4XqHpVmddbl8ZxTPu9idi4qvcEjBRz087d
	fLE7BjFMisohNIcUXi2Uxxdny/qe4m/u6jsU33Z9StRIpjL7ENXLyeIfgRqv0hbGVEJR
	bXwrh2nmCTjCS5kRYfqWIxbywzf1A4QG9Lsr5MJP32rxO7WLFIOjVqKbxEhO5+8zn+Oe
	3ZHkYQBZZmMOiv7u2YCjG0SrLQ1kUkjQzVZ1Bm01qB5m9ziuOZ1uKFgwZD/U098/NtZG
	ROkksZeWc2S6ugQGGzY62c/Ft3PKUXc9sY2R0q5nsk3wfEcRvgh+SKf5RXuG0gc5u1n3
	rtpg==
X-Gm-Message-State: AFeK/H2kirxs6PClR/cRqlXL+7Yui9BObGEaY2ndjwWgDAsfWErAkb3haIwDF/xgf6c2TOa9IQpehdyC8Hobpg==
X-Received: by 10.55.129.71 with SMTP id c68mr24828201qkd.113.1490024291888;
	Mon, 20 Mar 2017 08:38:11 -0700 (PDT)
MIME-Version: 1.0
References: <BL2PR03MB435F510935FC7E230118AD3EE380@BL2PR03MB435.namprd03.prod.outlook.com>
In-Reply-To: <BL2PR03MB435F510935FC7E230118AD3EE380@BL2PR03MB435.namprd03.prod.outlook.com>
From: Andrew Johnson <andrew.johnson83@gmail.com>
Date: Mon, 20 Mar 2017 15:38:01 +0000
Message-ID: <CAAy62_K5ePDuvVn8=DtwJX6ek00Z_r4u9LyA0W11vgZmQ=zzDg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	John Hardy <john@seebitcoin.com>
Content-Type: multipart/alternative; boundary=94eb2c06266aa01c0b054b2b501e
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,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:45:28 +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 15:38:13 -0000

--94eb2c06266aa01c0b054b2b501e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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%
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 Bitco=
in.
>
> I always felt the centralising effects of ASIC manufacturing would resolv=
e
> 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 miner=
s
> 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 Reactiv=
e
> 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
> 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 ar=
e
> already established and proven within existing altcoin implementations. A=
s
> 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 portion
> 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 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
> impact the functioning of the network between difficulty adjustments. Thi=
s
> also adds protection from attacks by the malicious 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%, 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 minimis=
e the
> number of future hard forks where possible. It could also activate SegWit
> if it hasn=E2=80=99t already.
>
> The beauty of this method is that it creates a huge risk to any malicious
> actor trying to abuse their position. Ideally, MR POWA would just serve a=
s
> 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-upgrad=
ed
> nodes, would be of no economic significance: a vestigial chain immediatel=
y
> 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 roa=
d
> 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
>
--=20
Andrew Johnson

--94eb2c06266aa01c0b054b2b501e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>By doing this you&#39;re significantly changing the economic incentive=
s behind bitcoin mining. How can you reliably invest in hardware if you hav=
e no idea when or if your profitability is going to be cut by 50-75% based =
on a whim?</div><div><br></div><div>You may also inadvertently create an en=
tirely 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.=C2=A0</di=
v><div><br></div><div>Bitcoin only works if most miners are honest, this ha=
s been known since the beginning.=C2=A0</div><div><br></div><div><div class=
=3D"gmail_quote"><div>On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoi=
n-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">




<div class=3D"gmail_msg">
<div id=3D"m_6451335042833672793divtagdefaultwrapper" style=3D"font-size:12=
pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" class=3D"g=
mail_msg">
<p class=3D"gmail_msg"></p>
<div class=3D"gmail_msg">I=E2=80=99m very worried about the state of miner =
centralisation in Bitcoin.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">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.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">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 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"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">Inspired by UASF, I believe we should implement a =
Malicious miner Reactive Proof of Work Additions (MR POWA).</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">This would be a hard fork activated in response to=
 a malicious attempt by a hashpower majority to introduce a contentious har=
d fork.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">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.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">I don=E2=80=99t think we should eliminate SHA256 a=
s 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.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">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 intensive met=
hods) would also be positive for decentralisation. Initial difficulty could=
 simply be an estimated portion of existing infrastructure.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">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 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"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">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.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">Such a hard fork could also, counter-intuitively, =
introduce a block size increase since while we=E2=80=99re hard forking it m=
akes sense to minimise the number of future hard forks where possible. It c=
ould also activate SegWit if it hasn=E2=80=99t already.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">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.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">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.</div>
<div class=3D"gmail_msg"><br class=3D"gmail_msg">
</div>
<div class=3D"gmail_msg">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.</div>
<p class=3D"gmail_msg"></p>
</div>
</div>

_______________________________________________<br class=3D"gmail_msg">
bitcoin-dev mailing list<br class=3D"gmail_msg">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"g=
mail_msg">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev</a><br class=3D"gmail_msg">
</blockquote></div></div><div dir=3D"ltr">-- <br></div><div data-smartmail=
=3D"gmail_signature">Andrew Johnson<br><div><br></div></div>

--94eb2c06266aa01c0b054b2b501e--