path: root/d5/17b55424f04dbbf1aceab0664017d0b457069d

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6FF1C901
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 16 Sep 2018 23:20:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com
	[209.85.215.194])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 33E3A102
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 16 Sep 2018 23:20:08 +0000 (UTC)
Received: by mail-pg1-f194.google.com with SMTP id r1-v6so6747211pgp.11
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 16 Sep 2018 16:20:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=OQ4l4HyuaR11M0goJ3PfjdfYSHi1Rdrwl7z4MgfxD94=;
	b=hxQmrlbxDXr7Nfj8lBE6d0EwAAMHSV6nDhSChiAvE3TSqjeNr/h6GuxYPYSsjZsUDv
	d0kvHvHWtuUG7PLKP43zV+SbQirXHl82GS8LtL3cu5f12ev/LsqeNLbpcAO3iIHr8WNj
	NqLA0HtVmctbELei4BO5PPIj7MaapUZFFcLs0ku7BNQq5Hqhe/cURfsQOKl1oDKHiz2j
	EkT5wJHjrvOjlEEc4g+nGzlQKYEP1lPV0+0OdL6kgrOouxScJjoZ69nY5PmXLJ0HC+sN
	KQ4aqW4z3rt947MBqgdMVPrh9jNCjDcFp1Q7HgRVmJ7VVq5+gKvwhYMzwlEV6gKdxfBz
	XMDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=OQ4l4HyuaR11M0goJ3PfjdfYSHi1Rdrwl7z4MgfxD94=;
	b=BRdnz69/DefFjs+PSWpqWtiPWM/3b30Axc+xQgttxn/MnDzAJwagDgSae1udfC47aA
	qg2RLsysqg1eLC7MYY3cmbYS2KjnAEpUXSjV9TORZG8UYMWwp09U+GcB+stBRyhdI6l0
	hDvdEeWvyyx5ZvDVHKnYgfyQco3oXg68JkSPzB1NDTotnepn4uz+md+JUeSB5rp3ybVf
	3JwnYj/0DpwPuexozxwjMnyQD2/8W+qnjsqIDEfZ1VZx+6c01EtroH7QsRWuT9XpCGgf
	Do+vEHjRbCmEgRWvYwnUE5gmSAo7mNnXm6lg7Wg1evHOdVlLpGp3NXz0TGFOLu62yX6e
	/CqQ==
X-Gm-Message-State: APzg51CIT3qqLVkW/EyOWZ2O1Qs4yvYwpgyBgs6WgzYLQCQYO6dNvKZl
	etTO7kwKTKhUOhY/xPXzBl0BvA==
X-Google-Smtp-Source: ANB0VdZhIC0nV2aYeDzlOVyJrn2cWxbguWcNzxkdQolGqqBnWCQl7Zis/IVWZvCfveCsYKWlOSkbJA==
X-Received: by 2002:a62:20f:: with SMTP id
	15-v6mr23454927pfc.100.1537140007632; 
	Sun, 16 Sep 2018 16:20:07 -0700 (PDT)
Received: from [192.168.40.177] (h-66-167-53-79.sttn.wa.globalcapacity.com.
	[66.167.53.79]) by smtp.gmail.com with ESMTPSA id
	k4-v6sm20720064pfj.30.2018.09.16.16.20.06
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sun, 16 Sep 2018 16:20:06 -0700 (PDT)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-29BE0082-6063-4EF7-B183-46794C05D2B5
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <PS2P216MB0179A4E6401D831166E749089D180@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
Date: Sun, 16 Sep 2018 16:20:05 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <B1863BA1-59D4-40FD-8D6E-8991BC25BFC8@voskuil.org>
References: <CAL8tG=k+kXHMbQdUXO3BXKv7fQwp5t2QuaQut7sPUtEYgwzn0A@mail.gmail.com>
	<CAL8tG=mui_izrob0V66QqNzSJs1Lpbm0xxUYMpzb65-JR9QhRw@mail.gmail.com>
	<PS2P216MB017942E0336DD337CB1EB6A89D180@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
	<CAL8tG==LgUecK5bbZ-FcwSZvJzVuK3nGu6cCUNFMPi4uR0CriA@mail.gmail.com>
	<PS2P216MB0179A4E6401D831166E749089D180@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
To: Damian Williamson <willtech@live.com.au>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, MIME_QP_LONG_LINE,
	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: Sun, 16 Sep 2018 23:52:10 +0000
Subject: Re: [bitcoin-dev] Selfish Mining Prevention
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 Sep 2018 23:20:10 -0000


--Apple-Mail-29BE0082-6063-4EF7-B183-46794C05D2B5
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hash rate cannot get =E2=80=9Cmore uneconomical=E2=80=9D. Mining will always=
 seek a return equal to the cost of capital, as does all production, and the=
 energy expended will always be fundamentally a function of the fee level an=
d energy price. Fee level is determined by variable demand for a fixed suppl=
y of confirmation.

When you say greed you are simply referring to economically-rational behavio=
r. It canny be eliminated, nor would that be a benefit.

WRT energy consumption, there is nothing that can be done to reduce it excep=
t for people to stop using Bitcoin or for energy to get more expensive.

e

> On Sep 15, 2018, at 15:45, Damian Williamson via bitcoin-dev <bitcoin-dev@=
lists.linuxfoundation.org> wrote:
>=20
> I see what you say, however, since the proposal as I have read it says "An=
d this will keep happening as long as hashrate keeps rising," - what actuall=
y happens in the case hashrate stagnates or falls?
>=20
> I would prefer to see (not only with your proposal) greater bias toward ha=
shrate being exponentially more uneconomical the more it rises to stifle gre=
ed. The current level of mining already greatly exceeds that necessary for t=
he stability of the network and far lower hashrates are completely acceptibl=
e provided the network is protected from large switch-ons, which I say is ac=
hievable.
>=20
> I do have other thoughts to approach greed that I have not yet made formal=
 on this list, much unrelated to your proposal, but, I see freedom of use of=
 Bitcoin needing to be censorship resistant but not necessarily mining provi=
ded it is protected enough or free or flexible enough to allow for, say, 50k=
 globally distributed standard mining hardware units to exist operating at a=
ny one time profitably. That said, I am PoW only and not PoS orientated.
> =20
> From: akaramaoun@gmail.com <akaramaoun@gmail.com> on behalf of Andrew <one=
lineproof@gmail.com>
> Sent: Sunday, 16 September 2018 2:01:19 AM
> To: Damian Williamson
> Cc: Bitcoin Protocol Discussion
> Subject: Re: [bitcoin-dev] Selfish Mining Prevention
> =20
> @Moral Agent: No problem. I did ask in the first post what the current
> plans are for selfish miner prevention. So if anyone has any other
> relevant ideas (not just for selfish mining but for making mining more
> decentralized and competetive), then please post it, but I just prefer
> to focus on my proposal more than others.
>=20
> @Damian: I think you are concerned that this will incentivize more
> global resource consumption and will be detrimental to our
> environment? Personally, I believe centralization of energy does more
> harm to the environment rather than total energy consumption. If
> Bitcoin helps "power" to become more decentralized, then I wouldn't be
> surprised if total (global) energy consumption actually decreases. The
> debt based economy is forcing us to continuously grow and use up more
> resources, and collectivism is turning individuals into
> super-organisms capable of doing much more harm to the environment
> than can be done by one or a just a few individuals working
> independently. In my proposal, I actually allow for changing
> environmental conditions by measuring only the peak hashrate of the
> past year, and not the full history of blocks.
>=20
> On Sat, Sep 15, 2018 at 5:29 AM, Damian Williamson <willtech@live.com.au> w=
rote:
> >>This "reserve" part of the fee will be paid to miners if the hashrate
> >> rises.
> >
> >
> > Anticipating ongoing hashrate rise shows that you have not yet thought a=
bout
> > moving outside of the current greed model, a model wherein mining will
> > consume all available resources within the colony's objective just to sp=
read
> > as far as possible with each new miner bringing diminishing individual
> > returns and shortening the life of Earth for no additional gain. Greed m=
odel
> > :=3D bacteria.
> >
> > ________________________________
> > From: bitcoin-dev-bounces@lists.linuxfoundation.org
> > <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Andrew via
> > bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> > Sent: Friday, 14 September 2018 9:19:37 AM
> > To: Bitcoin Dev
> > Subject: Re: [bitcoin-dev] Selfish Mining Prevention
> >
> > I discussed this more at bitcointalk:
> > https://bitcointalk.org/index.php?topic=3D4998410.0
> >
> > The attacks I'm interested in preventing are not only selfish mining
> > and collusion, but also more subtle attacks like block withholding,
> > and in general anything that aims to drive out the competition in
> > order to increase hashrate fraction. I also scrapped the idea of
> > changing the block subsidies, and I am only focuses on fees.
> >
> > You can read more about the motivation and details in the bitcointalk
> > thread, but my proposal in short would be to add the concept of
> > "reserve fees". When a user makes a transaction, for each txout
> > script, they can add parameters that specify the fraction of the total
> > fee that is held in "reserve" and the time it is held in "reserve"
> > (can set a limit of 2016 blocks). This "reserve" part of the fee will
> > be paid to miners if the hashrate rises. So if hashrate is currently h
> > and peak hashrate (from past year) is p, then for each period (1 day),
> > a new hashrate is calculated h1, and if h1 > h, then the fraction
> > (h1-h)/p from the reserve fees created in the past 2016 blocks will be
> > released to miners for that period (spread out over the 144 blocks in
> > that period). And this will keep happening as long as hashrate keeps
> > rising, until the "contract" expires, and the leftover part can be
> > used by the owner of the unspent output, but it can only be used for
> > paying fees, not as inputs for future transactions (to save on block
> > space).
> >
> > This should incentivize miners to not drive out the competition, since
> > if they do, there will be less of these reserve fees given to miners.
> > Yes in the end the miners will get all the fees, but with rising
> > hashrate they get an unconditional subsidy that does not require
> > transactions, thus more space for transactions with fees.
> >
> > I can make a formal BIP and pull request, but I need to know if there
> > is interest in this. Now fees don't play such a large part of the
> > block reward, but they will get more important, and this change
> > wouldn't force anything (would be voluntary by each user), just miners
> > have to agree to it with a soft fork (so they don't spend from the
> > anyone-can-spend outputs used for reserve fees). Resource requirements
> > for validation are quite small I believe.
> >
> > On Sat, Sep 1, 2018 at 12:11 AM, Andrew <onelineproof@gmail.com> wrote:
> >> As I understand, selfish mining is an attack where miners collude to
> >> mine at a lower hashrate then with all miners working independently.
> >> What are the current strategies used to prevent this and what are the
> >> future plans?
> >>
> >> One idea I have is to let the block reward get "modulated" according
> >> to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
> >> consisting of 144 blocks, h is the hashrate of the last 144 block (1
> >> day) period, and r is the base subsidy (12.5 BTC currently). You can
> >> then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
> >> peak you get the full reward. Otherwise you get less, down to a min of
> >> 0.5 r.
> >>
> >> If miners were to collude to mine at a lower than peak hashrate, then
> >> they may be able to do it profitably for 144 blocks, but after that,
> >> the reward would get modulated and it wouldn't be so much in their
> >> interest to continue mining at the lower hashrate.
> >>
> >> What flaws are there with this? I know it could be controversial due
> >> to easier mining present for early miners, so maybe it would have to
> >> be done in combination with a new more dynamic difficulty adjustment
> >> algorithm. But I don't see how hashrate can continue rising
> >> indefinitely, so a solution should be made for selfish mining.
> >>
> >> Also when subsidies stop and a fee market is needed, I guess a portion
> >> of the fees can be withheld for later if hashrate is not at peak.
> >>
> >>
> >> --
> >> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
> >
> >
> >
> > --
> > PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=20
>=20
> --=20
> PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-29BE0082-6063-4EF7-B183-46794C05D2B5
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div></div><div>Hash rate cannot get =E2=80=
=9Cmore uneconomical=E2=80=9D. Mining will always seek a return equal to the=
 cost of capital, as does all production, and the energy expended will alway=
s be fundamentally a function of the fee level and energy price. Fee level i=
s determined by variable demand for a fixed supply of confirmation.</div><di=
v><br></div><div>When you say greed you are simply referring to economically=
-rational behavior. It canny be eliminated, nor would that be a benefit.</di=
v><div><br></div><div>WRT energy consumption, there is nothing that can be d=
one to reduce it except for people to stop using Bitcoin or for energy to ge=
t more expensive.</div><div><br></div><div>e</div><div><br>On Sep 15, 2018, a=
t 15:45, Damian Williamson via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wr=
ote:<br><br></div><blockquote type=3D"cite"><div>

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii">=




<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font-=
family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p style=3D"margin-top:0;margin-bottom:0">I see what you say, however, since=
 the proposal as I have read it
<font size=3D"2"><span style=3D"font-size:11pt;">says "And this will keep ha=
ppening as long as hashrate keeps rising," - what actually happens in the ca=
se hashrate stagnates or falls?</span></font></p>
<p style=3D"margin-top:0;margin-bottom:0"><font size=3D"2"><span style=3D"fo=
nt-size:11pt;"><br>
</span></font></p>
<p style=3D"margin-top:0;margin-bottom:0"><font size=3D"2"><span style=3D"fo=
nt-size:11pt;">I would prefer to see (not only with your proposal) greater b=
ias toward hashrate being exponentially more uneconomical the more it rises t=
o stifle greed. The current level
 of mining already greatly exceeds that necessary for the stability of the n=
etwork and far lower hashrates are completely acceptible provided the networ=
k is protected from large switch-ons, which I say is achievable.<br>
</span></font></p>
<p style=3D"margin-top:0;margin-bottom:0"><font size=3D"2"><span style=3D"fo=
nt-size:11pt;"><br>
</span></font></p>
<p style=3D"margin-top:0;margin-bottom:0"><font size=3D"2"><span style=3D"fo=
nt-size:11pt;"><i>I do have other thoughts to approach greed that I have not=
 yet made formal on this list, much unrelated to your proposal, but, I see f=
reedom of use of Bitcoin needing to
 be censorship resistant but not necessarily mining provided it is protected=
 enough or free or flexible enough to allow for, say, 50k globally distribut=
ed standard mining hardware units to exist operating at any one time profita=
bly. That said, I am PoW only
 and not PoS orientated.</i></span></font><br>
</p>
</div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" sty=
le=3D"font-size:11pt" color=3D"#000000"><b>From:</b> <a href=3D"mailto:akara=
maoun@gmail.com">akaramaoun@gmail.com</a> &lt;<a href=3D"mailto:akaramaoun@g=
mail.com">akaramaoun@gmail.com</a>&gt; on behalf of Andrew &lt;<a href=3D"ma=
ilto:onelineproof@gmail.com">onelineproof@gmail.com</a>&gt;<br>
<b>Sent:</b> Sunday, 16 September 2018 2:01:19 AM<br>
<b>To:</b> Damian Williamson<br>
<b>Cc:</b> Bitcoin Protocol Discussion<br>
<b>Subject:</b> Re: [bitcoin-dev] Selfish Mining Prevention</font>
<div>&nbsp;</div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;"=
>
<div class=3D"PlainText">@Moral Agent: No problem. I did ask in the first po=
st what the current<br>
plans are for selfish miner prevention. So if anyone has any other<br>
relevant ideas (not just for selfish mining but for making mining more<br>
decentralized and competetive), then please post it, but I just prefer<br>
to focus on my proposal more than others.<br>
<br>
@Damian: I think you are concerned that this will incentivize more<br>
global resource consumption and will be detrimental to our<br>
environment? Personally, I believe centralization of energy does more<br>
harm to the environment rather than total energy consumption. If<br>
Bitcoin helps "power" to become more decentralized, then I wouldn't be<br>
surprised if total (global) energy consumption actually decreases. The<br>
debt based economy is forcing us to continuously grow and use up more<br>
resources, and collectivism is turning individuals into<br>
super-organisms capable of doing much more harm to the environment<br>
than can be done by one or a just a few individuals working<br>
independently. In my proposal, I actually allow for changing<br>
environmental conditions by measuring only the peak hashrate of the<br>
past year, and not the full history of blocks.<br>
<br>
On Sat, Sep 15, 2018 at 5:29 AM, Damian Williamson &lt;<a href=3D"mailto:wil=
ltech@live.com.au">willtech@live.com.au</a>&gt; wrote:<br>
&gt;&gt;This "reserve" part of the fee will be paid to miners if the hashrat=
e<br>
&gt;&gt; rises.<br>
&gt;<br>
&gt;<br>
&gt; Anticipating ongoing hashrate rise shows that you have not yet thought a=
bout<br>
&gt; moving outside of the current greed model, a model wherein mining will<=
br>
&gt; consume all available resources within the colony's objective just to s=
pread<br>
&gt; as far as possible with each new miner bringing diminishing individual<=
br>
&gt; returns and shortening the life of Earth for no additional gain. Greed m=
odel<br>
&gt; :=3D bacteria.<br>
&gt;<br>
&gt; ________________________________<br>
&gt; From: <a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org">=
bitcoin-dev-bounces@lists.linuxfoundation.org</a><br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev-bounces@lists.linuxfoundation.org">bi=
tcoin-dev-bounces@lists.linuxfoundation.org</a>&gt; on behalf of Andrew via<=
br>
&gt; bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<br>
&gt; Sent: Friday, 14 September 2018 9:19:37 AM<br>
&gt; To: Bitcoin Dev<br>
&gt; Subject: Re: [bitcoin-dev] Selfish Mining Prevention<br>
&gt;<br>
&gt; I discussed this more at bitcointalk:<br>
&gt; <a href=3D"https://bitcointalk.org/index.php?topic=3D4998410.0">https:/=
/bitcointalk.org/index.php?topic=3D4998410.0</a><br>
&gt;<br>
&gt; The attacks I'm interested in preventing are not only selfish mining<br=
>
&gt; and collusion, but also more subtle attacks like block withholding,<br>=

&gt; and in general anything that aims to drive out the competition in<br>
&gt; order to increase hashrate fraction. I also scrapped the idea of<br>
&gt; changing the block subsidies, and I am only focuses on fees.<br>
&gt;<br>
&gt; You can read more about the motivation and details in the bitcointalk<b=
r>
&gt; thread, but my proposal in short would be to add the concept of<br>
&gt; "reserve fees". When a user makes a transaction, for each txout<br>
&gt; script, they can add parameters that specify the fraction of the total<=
br>
&gt; fee that is held in "reserve" and the time it is held in "reserve"<br>
&gt; (can set a limit of 2016 blocks). This "reserve" part of the fee will<b=
r>
&gt; be paid to miners if the hashrate rises. So if hashrate is currently h<=
br>
&gt; and peak hashrate (from past year) is p, then for each period (1 day),<=
br>
&gt; a new hashrate is calculated h1, and if h1 &gt; h, then the fraction<br=
>
&gt; (h1-h)/p from the reserve fees created in the past 2016 blocks will be<=
br>
&gt; released to miners for that period (spread out over the 144 blocks in<b=
r>
&gt; that period). And this will keep happening as long as hashrate keeps<br=
>
&gt; rising, until the "contract" expires, and the leftover part can be<br>
&gt; used by the owner of the unspent output, but it can only be used for<br=
>
&gt; paying fees, not as inputs for future transactions (to save on block<br=
>
&gt; space).<br>
&gt;<br>
&gt; This should incentivize miners to not drive out the competition, since<=
br>
&gt; if they do, there will be less of these reserve fees given to miners.<b=
r>
&gt; Yes in the end the miners will get all the fees, but with rising<br>
&gt; hashrate they get an unconditional subsidy that does not require<br>
&gt; transactions, thus more space for transactions with fees.<br>
&gt;<br>
&gt; I can make a formal BIP and pull request, but I need to know if there<b=
r>
&gt; is interest in this. Now fees don't play such a large part of the<br>
&gt; block reward, but they will get more important, and this change<br>
&gt; wouldn't force anything (would be voluntary by each user), just miners<=
br>
&gt; have to agree to it with a soft fork (so they don't spend from the<br>
&gt; anyone-can-spend outputs used for reserve fees). Resource requirements<=
br>
&gt; for validation are quite small I believe.<br>
&gt;<br>
&gt; On Sat, Sep 1, 2018 at 12:11 AM, Andrew &lt;<a href=3D"mailto:onelinepr=
oof@gmail.com">onelineproof@gmail.com</a>&gt; wrote:<br>
&gt;&gt; As I understand, selfish mining is an attack where miners collude t=
o<br>
&gt;&gt; mine at a lower hashrate then with all miners working independently=
.<br>
&gt;&gt; What are the current strategies used to prevent this and what are t=
he<br>
&gt;&gt; future plans?<br>
&gt;&gt;<br>
&gt;&gt; One idea I have is to let the block reward get "modulated" accordin=
g<br>
&gt;&gt; to peak hashrate. Say p is the peak hashrate for 365 periods (1 yea=
r)<br>
&gt;&gt; consisting of 144 blocks, h is the hashrate of the last 144 block (=
1<br>
&gt;&gt; day) period, and r is the base subsidy (12.5 BTC currently). You ca=
n<br>
&gt;&gt; then make the max block reward 0.5 r (1 + h/p). So if hashrate is a=
t<br>
&gt;&gt; peak you get the full reward. Otherwise you get less, down to a min=
 of<br>
&gt;&gt; 0.5 r.<br>
&gt;&gt;<br>
&gt;&gt; If miners were to collude to mine at a lower than peak hashrate, th=
en<br>
&gt;&gt; they may be able to do it profitably for 144 blocks, but after that=
,<br>
&gt;&gt; the reward would get modulated and it wouldn't be so much in their<=
br>
&gt;&gt; interest to continue mining at the lower hashrate.<br>
&gt;&gt;<br>
&gt;&gt; What flaws are there with this? I know it could be controversial du=
e<br>
&gt;&gt; to easier mining present for early miners, so maybe it would have t=
o<br>
&gt;&gt; be done in combination with a new more dynamic difficulty adjustmen=
t<br>
&gt;&gt; algorithm. But I don't see how hashrate can continue rising<br>
&gt;&gt; indefinitely, so a solution should be made for selfish mining.<br>
&gt;&gt;<br>
&gt;&gt; Also when subsidies stop and a fee market is needed, I guess a port=
ion<br>
&gt;&gt; of the fees can be withheld for later if hashrate is not at peak.<b=
r>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; PGP: B6AC 822C 451D 6304 6A28&nbsp; 49E9 7DB7 011C D53B 5647<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; PGP: B6AC 822C 451D 6304 6A28&nbsp; 49E9 7DB7 011C D53B 5647<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-d=
ev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
<br>
<br>
-- <br>
PGP: B6AC 822C 451D 6304 6A28&nbsp; 49E9 7DB7 011C D53B 5647<br>
</div>
</span></font></div>


</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></=
html>=

--Apple-Mail-29BE0082-6063-4EF7-B183-46794C05D2B5--