path: root/bf/568165e3370923ce50d65e2b61231872496b2e

Return-Path: <bram@bittorrent.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9348BB93
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Mar 2017 17:50:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f42.google.com (mail-it0-f42.google.com
	[209.85.214.42])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A536D24E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Mar 2017 17:50:00 +0000 (UTC)
Received: by mail-it0-f42.google.com with SMTP id y18so44703156itc.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 20 Mar 2017 10:50:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=bittorrent-com.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=p+pc3tDdGJWEC3hFu/fYm7TqH0tYMAgHzRlWanyKrgE=;
	b=OkZoi4nlvXYuzEo2u6QpjmiC7UUfdoIBYYdb4I+7kkqBIEOfAIK7xl2jiJCWllGjOp
	pQ716L8lTrbVhIDcZ03MZjHfC7xFygtJKgkIf1T46XilG8DhHXoTn6QBipCSCI0xBuQK
	Q8Evo3CHKQti4+BUQnCDyWX9E7PU0zWOvo9oe2CoW4D7rp1Nh07FvNcvkAh9VbdY+hqy
	4Sr2GuYPZFl5prSLrcpuDajOFJOUWjAX6dbmcewJgXPgjDHjJ4ZrF88MHp+qbd6DCFsj
	fcPHSkM2jULKSgqvk1GSwBP9aINKehXeHfkG6JTfZnkG8Z8yu0fn4XEcueWVWE7L64zZ
	mrig==
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=p+pc3tDdGJWEC3hFu/fYm7TqH0tYMAgHzRlWanyKrgE=;
	b=B6vLUYL3UoJGocwQh4y4cqBQfwVpkw71GsEdbzZpV0djx8mU13LtuAQRgvIk9ul8wk
	poH7g+zNxDas6r7m/NUv1RWkmb2pl+hpb78SW3VtDKyojmNcueLOA5rBZP6OnfxT+43i
	tRZnoW+gzI4o7O7IGQHyezyb6syzV3Tj0vhSGf/NY/LGDNkMnxiZ6IHD/Jfe21o6Fzuu
	7TUDxDU+WNOd+HGAGFW2xLEvqLUtcAObX15AUC4unGIA8r9Bt7fWWXTexokLQXkc3Q/j
	ZOy/bt7bL3au+hL0opL59F6xAD2YEyOY1A8gJdnf+DU8ePYETG0tWU3flbiB1635RPKl
	qRFQ==
X-Gm-Message-State: AFeK/H2YKMWiPfNnEbn9jYRu5dT1pPWqkXqAJT5pKKuKJfyBUvJ6jjKUQ/qQf3jjC+GiRf+I36VO5fnHw9a7DJWO
X-Received: by 10.36.127.207 with SMTP id r198mr6801270itc.98.1490032199908;
	Mon, 20 Mar 2017 10:49:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.36.254.132 with HTTP; Mon, 20 Mar 2017 10:49:59 -0700 (PDT)
In-Reply-To: <BL2PR03MB435F510935FC7E230118AD3EE380@BL2PR03MB435.namprd03.prod.outlook.com>
References: <BL2PR03MB435F510935FC7E230118AD3EE380@BL2PR03MB435.namprd03.prod.outlook.com>
From: Bram Cohen <bram@bittorrent.com>
Date: Mon, 20 Mar 2017 10:49:59 -0700
Message-ID: <CA+KqGkpc5DVe75g8M9=MnCGCPO4vnHdHXeZx4T3n7GMCK6MoEw@mail.gmail.com>
To: John Hardy <john@seebitcoin.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1147bc32fb1826054b2d2702
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
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 17:50:01 -0000

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

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
contain 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
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 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
is 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
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 equihash.

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

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

<div dir=3D"ltr">It&#39;s possible to switch PoW algorithms with a soft for=
k 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 contain the exact same transactions. The new work rule =
is that the weighted geometric mean of the quality of the new-style block a=
nd the old-style block has to exceed the work threshold, with the weighting=
 starting almost entirely on the old-style block and shifting gradually ove=
r to the new-style block until in the end the amount of work to generate th=
e old-style block is completely trivial and doesn&#39;t matter any more.=C2=
=A0<div><br></div><div>The most interesting part of the whole thing is keep=
ing it so that the new work limit is consistently the limiting factor on mi=
ning difficulty rather than the old one interfering. Getting that to work r=
ight is an interesting problem which I&#39;m not sure how to do off the top=
 of my head but I believe is manageable.</div><div><br></div><div>Using man=
y PoWs is a bad idea, that generally gets the worst of everything rather th=
an the best. There are two ways to go with a PoW, either make it as advanta=
ged on custom hardware as possible, which means sha3, or make it as difficu=
lt to ASIC as possible, which at this point means cuckoo since there&#39;s =
already hardware for equihash.</div></div><div class=3D"gmail_extra"><br><d=
iv class=3D"gmail_quote">On Sat, Mar 18, 2017 at 9:01 AM, John Hardy via bi=
tcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir=3D"ltr">
<div id=3D"m_7235471870693523876divtagdefaultwrapper" style=3D"font-size:12=
pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif" dir=3D"ltr=
">
<p></p>
<div>I=E2=80=99m very worried about the state of miner centralisation in Bi=
tcoin.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Inspired by UASF, I believe we should implement a Malicious miner Reac=
tive Proof of Work Additions (MR POWA).</div>
<div><br>
</div>
<div>This would be a hard fork activated in response to a malicious attempt=
 by a hashpower majority to introduce a contentious hard fork.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>I don=E2=80=99t think we should eliminate SHA256 as a hashing method a=
nd change POW entirely. That would be throwing the baby out with the bathwa=
ter and hurt the non-malicious miners who have invested in hardware, making=
 it harder to gain their support.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Such a hard fork could also, counter-intuitively, introduce a block si=
ze 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 S=
egWit if it hasn=E2=80=99t already.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<p></p>
</div>
</div>

<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>

--001a1147bc32fb1826054b2d2702--