path: root/fc/536b962388c5a3fe69fbc73620b46b2f5f2002

Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E9E0295E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 16 Apr 2017 20:05:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f181.google.com (mail-qt0-f181.google.com
	[209.85.216.181])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A118BD5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 16 Apr 2017 20:04:59 +0000 (UTC)
Received: by mail-qt0-f181.google.com with SMTP id c45so89879345qtb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 16 Apr 2017 13:04:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:reply-to:in-reply-to:references:from:date:message-id
	:subject:to; bh=ULrWIGbz8PbOFhwbRmV+4dnVAi6xRolCKg5i2+o+CqY=;
	b=Ea1vaVa9cCvEgYq2BSd/oGX+8I7QntjIciJ8HcfUGQNh3tFcDKE5RSqHZDQWQXJTZV
	DpZ5uCmNg1G8an3qyqp79gobNjmEUJwK982imUZvSmT3F3zH0fp/MRJ0q9843djZvBxk
	V3e3pSa8W7x5A9ai5D70UzKokQPkBiT0/l/k0/89NgnPwGoMg+zlofrx8k8TooYTuIH1
	KMJKbFzS6LAH+9KxjGBYwzjsV8Aay+cvi3GAosAmioXx2e59gB/K+QEKPQe+W0bh4bLU
	YDsjVjtxSNloJO0W85WzJ79wDbMLc8ztydbHbIuw7Ebfohtc8zrmYlAaMFadzZROLImU
	0Q3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:reply-to:in-reply-to:references
	:from:date:message-id:subject:to;
	bh=ULrWIGbz8PbOFhwbRmV+4dnVAi6xRolCKg5i2+o+CqY=;
	b=qxGomAh6zPCVSXs2z+qocFmPTqFfoBVyVkg/ipj9fU7konmv0lDULTM1gGuI/shraT
	QhfGFHAfVJxwXVD7UJfzSGGi0e/dJcdqxlbDPl6Qvstou+qt1oHrbToWBAaTLuhaTMHx
	IWu+cOwKvw4cW3Y9qLEOZWdluK1v8g70+NdydLGPl24PM2oHZ0BmQSPF5n6AfkPtsZca
	lQK66QissVq0+yZbU10Nli2zbrcgJDh9NYrW9HfnQo6Jg08XQ58eCMs3KkBCDixUSQQy
	W47D0vn6Ur0WsxijWuzlEWVFVcpfkbZ9kzduJkxRjlQz1Ot4+QEY+mL2G+WZGxDG26uf
	3KNA==
X-Gm-Message-State: AN3rC/6uM/2iQ0eI1MyuW6hC+Alh6LbIZKDu1Get70v3VwZFYQWtsdMx
	LAZtpas3hi6GHSDTp7JqB4dPfhfX2IdJ
X-Received: by 10.200.55.193 with SMTP id e1mr6177047qtc.190.1492373098512;
	Sun, 16 Apr 2017 13:04:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.0.146 with HTTP; Sun, 16 Apr 2017 13:04:56 -0700 (PDT)
Received: by 10.200.0.146 with HTTP; Sun, 16 Apr 2017 13:04:56 -0700 (PDT)
Reply-To: erik@q32.com
In-Reply-To: <0690791a46d7a7699fc3427e92a76e9b.squirrel@mail.fairluck.net>
References: <BL2PR03MB435F510935FC7E230118AD3EE380@BL2PR03MB435.namprd03.prod.outlook.com>
	<CAAy62_K5ePDuvVn8=DtwJX6ek00Z_r4u9LyA0W11vgZmQ=zzDg@mail.gmail.com>
	<0690791a46d7a7699fc3427e92a76e9b.squirrel@mail.fairluck.net>
From: Erik Aronesty <earonesty@gmail.com>
Date: Sun, 16 Apr 2017 16:04:56 -0400
Message-ID: <CAJowKg+dZr-PcHfCY5AO2BO8_-5QfwzvG3PuJA+mTLWw9=a-Og@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	mm@mm-studios.com
Content-Type: multipart/alternative; boundary=001a113e79e868c6e0054d4e30e5
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW, 
	RCVD_IN_SORBS_SPAM 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: Sun, 16 Apr 2017 20:09:06 +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: Sun, 16 Apr 2017 20:05:01 -0000

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

This is a great solution.

8 or more secure hashes, each of which can be implemented on GPU/CPU, but
rotate through them - per block round robin.

Hardware, infrastructue investment is protected.  ASIC is not.

Each pow has different tracking metrics and difficulty adjustments.  This
means the difficulty adjust will be less accurate (1/8th the samples),  but
that's never been an issue.

ASIC will never beat this - because it will be 8x more expensive to
maintain the cold circuits.

Miners with gpu/generalized hardware will always be in business.

Should be done gradually and pre-emptively.    Change one at a time on a
slow schedule, allowing a graceful transition.





On Mar 20, 2017 8:59 AM, "Marcos mayorga via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
> Just a thought,
> Bitcoin developers shouldn't care about miners business model, they can
> always sell their hw and close the bz as soon as bitcoin hardforks to
> better ways of doing.
> Just focus on making a better cryptocurrency, the more decentralized the
> best.
>
> M
>
> > 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-7=
5%
> > 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=C3=A2=E2=82=AC=E2=84=A2m very worried about the state of miner centr=
alisation in Bitcoin.
> >>
> >> 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
> >> 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 a=
nd
> >> duration for activation would need to be carefully considered.
> >>
> >> I don=C3=A2=E2=82=AC=E2=84=A2t think we should eliminate SHA256 as a h=
ashing method and
> >> change
> >> POW entirely. That would be throwing the baby out with the bathwater a=
nd
> >> 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 implementations=
.
> >> As
> >> an example we could add Scrypt, Ethash and Equihash. Much of the code
> >> and
> >> mining infrastructure already exists. Diversification of hardware (a m=
ix
> >> 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. Thi=
s
> >> 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 dramatical=
ly
> >> impact the functioning of the network between difficulty adjustments.
> >> This
> >> 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 t=
o
> >> hardware would fall by 50%, reducing some of the centralising impact o=
f
> >> subsidised 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=C3=A2=E2=82=AC=E2=84=A2re hard forking it make=
s sense to minimise the
> >> number of future hard forks where possible. It could also activate
> >> SegWit
> >> if it hasn=C3=A2=E2=82=AC=E2=84=A2t 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 serv=
e
> >> 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-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
> >> hashpower to harm the network. This is the beauty of Bitcoin: for any
> >> road
> >> 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
> >
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">This is a great solution.=C2=A0<div dir=3D"auto"><br></di=
v><div dir=3D"auto">8 or more secure hashes, each of which can be implement=
ed on GPU/CPU, but rotate through them - per block round robin.<div dir=3D"=
auto"><br></div><div dir=3D"auto">Hardware, infrastructue investment is pro=
tected.=C2=A0 ASIC is not.</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">Each pow has different tracking metrics and difficulty adjustments.=C2=
=A0 This means the difficulty adjust will be less accurate (1/8th the sampl=
es), =C2=A0but that&#39;s never been an issue.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">ASIC will never beat this - because it will be 8x mo=
re expensive to maintain the cold circuits. =C2=A0</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">Miners with gpu/generalized hardware will always=
 be in business.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">S=
hould be done gradually and pre-emptively. =C2=A0 =C2=A0Change one at a tim=
e on a slow schedule, allowing a graceful transition.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div di=
r=3D"auto"><br></div></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Mar 20, 2017 8:59 AM, &quot;Marcos mayorga via bitcoin-=
dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">Hi,<br>
Just a thought,<br>
Bitcoin developers shouldn&#39;t care about miners business model, they can=
<br>
always sell their hw and close the bz as soon as bitcoin hardforks to<br>
better ways of doing.<br>
Just focus on making a better cryptocurrency, the more decentralized the<br=
>
best.<br>
<br>
M<br>
<br>
&gt; By doing this you&#39;re significantly changing the economic incentive=
s behind<br>
&gt; bitcoin mining. How can you reliably invest in hardware if you have no=
<br>
&gt; idea<br>
&gt; when or if your profitability is going to be cut by 50-75% based on a<=
br>
&gt; whim?<br>
&gt;<br>
&gt; You may also inadvertently create an entirely new attack vector if 50-=
75%<br>
&gt; of the SHA256 hardware is taken offline and purchased by an entity who=
<br>
&gt; intends to do harm to the network.<br>
&gt;<br>
&gt; Bitcoin only works if most miners are honest, this has been known sinc=
e<br>
&gt; the<br>
&gt; beginning.<br>
&gt;<br>
&gt; On Mon, Mar 20, 2017 at 9:50 AM John Hardy via bitcoin-dev &lt;<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; I=C3=A2=E2=82=AC=E2=84=A2m very worried about the state of miner c=
entralisation in Bitcoin.<br>
&gt;&gt;<br>
&gt;&gt; I always felt the centralising effects of ASIC manufacturing would=
<br>
&gt;&gt; resolve<br>
&gt;&gt; themselves once the first mover advantage had been exhausted and t=
he<br>
&gt;&gt; industry had the opportunity to mature.<br>
&gt;&gt;<br>
&gt;&gt; I had always assumed initial centralisation would be harmless sinc=
e<br>
&gt;&gt; miners<br>
&gt;&gt; have no incentive to harm the network. This does not consider the =
risk<br>
&gt;&gt; of a<br>
&gt;&gt; single entity with sufficient power and either poor, malicious or<=
br>
&gt;&gt; coerced<br>
&gt;&gt; decision making. I now believe that such centralisation poses a hu=
ge<br>
&gt;&gt; risk<br>
&gt;&gt; to the security of Bitcoin and preemptive action needs to be taken=
 to<br>
&gt;&gt; protect the network from malicious actions by any party able to ex=
ert<br>
&gt;&gt; influence over a substantial portion of SHA256 hardware.<br>
&gt;&gt;<br>
&gt;&gt; Inspired by UASF, I believe we should implement a Malicious miner<=
br>
&gt;&gt; Reactive<br>
&gt;&gt; Proof of Work Additions (MR POWA).<br>
&gt;&gt;<br>
&gt;&gt; This would be a hard fork activated in response to a malicious att=
empt<br>
&gt;&gt; by<br>
&gt;&gt; a hashpower majority to introduce a contentious hard fork.<br>
&gt;&gt;<br>
&gt;&gt; The activation would occur once a fork was detected violating prot=
ocol<br>
&gt;&gt; (likely oversize blocks) with a majority of hashpower. The thresho=
ld and<br>
&gt;&gt; duration for activation would need to be carefully considered.<br>
&gt;&gt;<br>
&gt;&gt; I don=C3=A2=E2=82=AC=E2=84=A2t think we should eliminate SHA256 as=
 a hashing method and<br>
&gt;&gt; change<br>
&gt;&gt; POW entirely. That would be throwing the baby out with the bathwat=
er and<br>
&gt;&gt; hurt the non-malicious miners who have invested in hardware, makin=
g it<br>
&gt;&gt; harder to gain their support.<br>
&gt;&gt;<br>
&gt;&gt; Instead I believe we should introduce multiple new proofs of work =
that<br>
&gt;&gt; are<br>
&gt;&gt; already established and proven within existing altcoin implementat=
ions.<br>
&gt;&gt; As<br>
&gt;&gt; an example we could add Scrypt, Ethash and Equihash. Much of the c=
ode<br>
&gt;&gt; and<br>
&gt;&gt; mining infrastructure already exists. Diversification of hardware =
(a mix<br>
&gt;&gt; of<br>
&gt;&gt; CPU and memory intensive methods) would also be positive for<br>
&gt;&gt; decentralisation. Initial difficulty could simply be an estimated<=
br>
&gt;&gt; portion<br>
&gt;&gt; of existing infrastructure.<br>
&gt;&gt;<br>
&gt;&gt; This example would mean 4 proofs of work with 40 minute block targ=
et<br>
&gt;&gt; difficulty for each. There could also be a rule that two different=
<br>
&gt;&gt; proofs<br>
&gt;&gt; of work must find a block before a method can start hashing again.=
 This<br>
&gt;&gt; means there would only be 50% of hardware hashing at a time, and a=
<br>
&gt;&gt; sudden<br>
&gt;&gt; gain or drop in hashpower from a particular method does not dramat=
ically<br>
&gt;&gt; impact the functioning of the network between difficulty adjustmen=
ts.<br>
&gt;&gt; This<br>
&gt;&gt; also adds protection from attacks by the malicious SHA256 hashpowe=
r<br>
&gt;&gt; which<br>
&gt;&gt; could even be required to wait until all other methods have found =
a<br>
&gt;&gt; block<br>
&gt;&gt; before being allowed to hash again.<br>
&gt;&gt;<br>
&gt;&gt; 50% hashing time would mean that the cost of electricity in relati=
on to<br>
&gt;&gt; hardware would fall by 50%, reducing some of the centralising impa=
ct of<br>
&gt;&gt; subsidised or inexpensive electricity in some regions over others.=
<br>
&gt;&gt;<br>
&gt;&gt; Such a hard fork could also, counter-intuitively, introduce a bloc=
k size<br>
&gt;&gt; increase since while we=C3=A2=E2=82=AC=E2=84=A2re hard forking it =
makes sense to minimise the<br>
&gt;&gt; number of future hard forks where possible. It could also activate=
<br>
&gt;&gt; SegWit<br>
&gt;&gt; if it hasn=C3=A2=E2=82=AC=E2=84=A2t already.<br>
&gt;&gt;<br>
&gt;&gt; The beauty of this method is that it creates a huge risk to any<br=
>
&gt;&gt; malicious<br>
&gt;&gt; actor trying to abuse their position. Ideally, MR POWA would just =
serve<br>
&gt;&gt; as<br>
&gt;&gt; a deterrent and never activate.<br>
&gt;&gt;<br>
&gt;&gt; If consensus were to form around a hard fork in the future nodes w=
ould<br>
&gt;&gt; be<br>
&gt;&gt; able to upgrade and MR POWA, while automatically activating on<br>
&gt;&gt; non-upgraded<br>
&gt;&gt; nodes, would be of no economic significance: a vestigial chain<br>
&gt;&gt; immediately<br>
&gt;&gt; abandoned with no miner incentive.<br>
&gt;&gt;<br>
&gt;&gt; I think this would be a great way to help prevent malicious use of=
<br>
&gt;&gt; hashpower to harm the network. This is the beauty of Bitcoin: for =
any<br>
&gt;&gt; road<br>
&gt;&gt; block that emerges the economic majority can always find a way aro=
und.<br>
&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;&gt;<br>
&gt; --<br>
&gt; Andrew Johnson<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;<br>
<br>
<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>
</blockquote></div></div>

--001a113e79e868c6e0054d4e30e5--