path: root/a3/14716da38464da3bae4534fe4c3844431f374e

Return-Path: <zawy@yahoo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6A7B3BAC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  9 Oct 2017 21:28:12 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from sonic312-22.consmr.mail.gq1.yahoo.com
	(sonic312-22.consmr.mail.gq1.yahoo.com [98.137.69.203])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 3AE6B367
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  9 Oct 2017 21:28:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
	t=1507584490; bh=INK6TyBbNQXHOjk9GWmbBLaWFNm6Aw87PfIRbnBY6pw=;
	h=Date:From:To:Subject:References:From:Subject;
	b=WSojLEoyFgECF4Rkl4rEejW9NYqgfnRAz4iS7n1z2G0X35w4GKbsT1l16MOjbjyPfb22uKsfQf9TTwfvK71bbVi4wCzUeiEhKF1PmKTChBcAkLlQlAFjfdJ9RAV1U8bdtxy9ZHaaMb1DZ0P3fbegIx+z6zhkdLbtrKG6P+vVlv80EIjKLXnMp3Rqm3ScJFpNdzJ7QyaYOCoYoVXDXpIG681rbd0f4cMjm8/Dj8mzr0cF4w/X8dwl2AqM2jHULlP8XK7Z+YGtSB5W6NTQLsdBWatNi2rws8QnKFk9bfXO8dQdat4V+0RppeJMbvLT/yjHjWF3v8OE7jcpI3cP/gghsQ==
X-YMail-OSG: zxEitLgVM1lHjCdNNOkQRVn_aKFPhZB_ZeHuZO19ERTREQGACSX7KPupEg7TEcu
	VDZ.eQNWfJ7c1Mur_z9R27fVHwJrMxtBMu.vRf620.ROgwrVbsfZkBw.ucIpq45tKw5igtqylug.
	3XC5bYRPNu90mOh4dvOy9ZJSAU_ieIkyK2nHCY1oICOdWF8NxXMP2rEqD3IQgbH2.bjHNUzmqXtE
	l3SrlMy78MRzQuMnfn7BfoagLfSO3pB.xy8JII17vGKyF1IPe.Qu1s1XqmV95evalYikWneR.WU7
	.j0QdgOcwkMJqEJYWR1nQxIvsIBI_2fVgLG1nraiFDnXk5EXtKMukAm4UWcfTXLMaZJjcyIpYpAw
	nM_t3O5hWeP03gn0caf2KfbbYg_RXwHwfjTvleRt.JWKWZxeArXIlq2.mf8aZhkB_69DAa2MG2_i
	TvKu6wXEMBV1YNOU.hMTOfUsWTbo5H2IY_i0MuqKNSEpVkF5SU04cFcn6ApCbABaoic0tFW1JSC_
	46waoRdUMDT7WfHXcYZJ4oJkV1zba2kTVSLCmJdfL0dGana7_lVMTdY.1Kw--
Received: from sonic.gate.mail.ne1.yahoo.com by
	sonic312.consmr.mail.gq1.yahoo.com with HTTP;
	Mon, 9 Oct 2017 21:28:10 +0000
Date: Mon, 9 Oct 2017 21:26:50 +0000 (UTC)
From: Scott Roberts <zawy@yahoo.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <1091872802.4256448.1507584410826@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_4256447_1338361221.1507584410824"
References: <1091872802.4256448.1507584410826.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.10668 YMailNorrin Mozilla/5.0 (Windows NT 6.1; Win64;
	x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100
	Safari/537.36
X-Spam-Status: No, score=1.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FORGED_MUA_MOZILLA,FREEMAIL_FROM,HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=disabled version=3.3.1
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 09 Oct 2017 21:46:41 +0000
Subject: [bitcoin-dev] New difficulty algorithm needed for SegWit2x fork?
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, 09 Oct 2017 21:28:12 -0000

------=_Part_4256447_1338361221.1507584410824
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Background:
The bitcoin difficulty algorithm does not seem to be a good one.=C2=A0 If t=
here is a fork due to miners seeking maximum profit without due regard to s=
ecurity, users, and nodes, the "better" coin could end up being the minorit=
y chain. If 90% of hashrate is really going to at least initially go toward=
s using SegWit2x, BTC would face 10x delays in confirmations until the next=
 difficulty adjustment, negatively affecting its price relative to BTC1, ca=
using further delays from even more miner abandonment (until the next adjus=
tment). The 10% miners remaining on BTC do not inevitably lose by staying t=
o endure 10x delays because they have 10x less competition, and the same si=
tuation applies to BTC1 miners. If the prices are the same and stable, all =
seems well for everyone, other things aside.=C2=A0 But if the BTC price doe=
s not fall to reflect the decreased hashrate, the situation seems to be a b=
ig problem for both coins: BTC1 miners will jump back to BTC when the diffi=
culty adjustment occurs, initiating a potentially never-ending oscillation =
between the two coins, potentially worse than what BCH is experiencing.=C2=
=A0 They will not issue coins too fast like BCH because that is a side effe=
ct of the asymmetry in BCH's rise and fall algorithm.
Solution:
Hard fork to implement a new difficulty algorithm that uses a simple rollin=
g average with a much smaller window.=C2=A0 Many small coins have done this=
 as a way to stop big miners from coming on and then suddenly leaving, leav=
ing constant miners stuck with a high difficulty for the rest of a (long) a=
veraging window.=C2=A0 Even better, adjust the reward based on recent solve=
times to motivate more mining (or less) if the solvetimes are too slow (or =
too fast).=C2=A0 This will keep keep the coin issuance rate perfectly on sc=
hedule with real time.=C2=A0
I recommend the following for Bitcoin, as fast, simple, and better than any=
 other difficulty algorithm I'm aware of.=C2=A0 This is the result of a lot=
 of work the past year.
=3D=3D=3D Begin difficulty algorithm =3D=3D=3D# Zawy v6 difficulty algorith=
m (modified for bitcoin)# Unmodified Zawy v6 for alt coins:=C2=A0# http://z=
awy1.blogspot.com/2017/07/best-difficulty-algorithm-zawy-v1b.html# My faile=
d attempts at something better:# https://github.com/seredat/karbowanec/comm=
it/231db5270acb2e673a641a1800be910ce345668a## Keep negative solvetimes to c=
orrect bad timestamps.# Do not be tempted to use:# next_D =3D sum(last N Ds=
) * T / [max(last N TSs) - min(last N TSs];# D=3Ddifficulty, ST=3D Solvetim=
e, TS =3D timestamp, T=3DTargetSolveTime
# set constants until next hard fork:
T=3D600;=C2=A0N=3D30; # Averaging window. Smoother than N=3D15, faster resp=
onse than N=3D60.X=3D5; # size of sudden hashrate changes expected as multi=
ple of base hashrate.limit =3D X^(2/N); # limit rise and fall to protect ag=
ainst timestamp errors & manipulationadjust =3D 1/(1+0.67/N);=C2=A0 # keeps=
 avg solvetime on track for small N.
# begin difficulty algorithm=C2=A0
avg_ST=3D0; # avg SolveTimeavg_D=3D0;for ( i=3Dheight;=C2=A0 i > height-N;=
=C2=A0 i--) {=C2=A0 # go through N most recent blocks=C2=A0 =C2=A0avg_ST +=
=3D (TS[i] - TS[i-1]) / N; # TS=3Dtimestamps=C2=A0 =C2=A0avg_D +=3D D[i]/N;=
}avg_ST =3D T*limit if avg_ST > T*limit;=C2=A0avg_ST =3D T/limit if avg_ST =
< T/limit;=C2=A0
next_D =3D avg_D * T / avg_ST * adjust;=C2=A0
# Tim Olsen suggested changing coin reward to protect against hash attacks.=
# Karbowanek coin suggested something similar.# After testing many ideas, I=
 could not find anything better than the simplest idea below.# It was a sur=
prise that coin issuance rate came out perfect.# BaseReward =3D coins per b=
lock
next_reward =3D BaseReward * avg_ST / T;
=3D=3D=3D=3D=3D=3D=3D end algo =3D=3D=3D=3D
Due to the limit and keeping negative solvetimes in a true average, timesta=
mp errors resulting in negative solvetimes are corrected in the next block.=
 Otherwise, one would need to do like Zcash and cause a 5-block delay in th=
e response by resorting to the median of past 11 blocks (MTP) as the most r=
ecent timestamp, offsetting the timestamps from their corresponding difficu=
lties by 5 blocks. (it does not cause an averaging problem, but it does cau=
se a 5-block delay in the response.)
Small N windows like keep the correct median, but cause avg solvetime to be=
 above the target. The "adjust" constant (empirically determined) fixes thi=
s, but it causes the median to be that same percentage too low, below the i=
deal Poisson median which is 0.693 of the mean. I was not able to find a fi=
x to this that did not slow down the response to hashrate changes.
------=_Part_4256447_1338361221.1507584410824
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div style=3D"font-family:Helvetica Neue, Helvetic=
a, Arial, sans-serif;font-size:16px;"><div style=3D"font-family:Helvetica N=
eue, Helvetica, Arial, sans-serif;font-size:16px;"><div>Background:</div><d=
iv><br></div><div>The bitcoin difficulty algorithm does not seem to be a go=
od one.&nbsp; If there is a fork due to miners seeking maximum profit witho=
ut due regard to security, users, and nodes, the "better" coin could end up=
 being the minority chain. If 90% of hashrate is really going to at least i=
nitially go towards using SegWit2x, BTC would face 10x delays in confirmati=
ons until the next difficulty adjustment, negatively affecting its price re=
lative to BTC1, causing further delays from even more miner abandonment (un=
til the next adjustment). The 10% miners remaining on BTC do not inevitably=
 lose by staying to endure 10x delays because they have 10x less competitio=
n, and the same situation applies to BTC1 miners. If the prices are the sam=
e and stable, all seems well for everyone, other things aside.&nbsp; But if=
 the BTC price does not fall to reflect the decreased hashrate, the situati=
on seems to be a big problem for both coins: BTC1 miners will jump back to =
BTC when the difficulty adjustment occurs, initiating a potentially never-e=
nding oscillation between the two coins, potentially worse than what BCH is=
 experiencing.&nbsp; They will not issue coins too fast like BCH because th=
at is a side effect of the asymmetry in BCH's rise and fall algorithm.</div=
><div><br></div><div>Solution:</div><div><br></div><div>Hard fork to implem=
ent a new difficulty algorithm that uses a simple rolling average with a mu=
ch smaller window.&nbsp; Many small coins have done this as a way to stop b=
ig miners from coming on and then suddenly leaving, leaving constant miners=
 stuck with a high difficulty for the rest of a (long) averaging window.&nb=
sp; Even better, adjust the reward based on recent solvetimes to motivate m=
ore mining (or less) if the solvetimes are too slow (or too fast).&nbsp; Th=
is will keep keep the coin issuance rate perfectly on schedule with real ti=
me.&nbsp;</div><div><br></div><div>I recommend the following for Bitcoin, a=
s fast, simple, and better than any other difficulty algorithm I'm aware of=
.&nbsp; This is the result of a lot of work the past year.</div><div><br></=
div><div>=3D=3D=3D Begin difficulty algorithm =3D=3D=3D</div><div># Zawy v6=
 difficulty algorithm (modified for bitcoin)</div><div># Unmodified Zawy v6=
 for alt coins:&nbsp;</div><div># http://zawy1.blogspot.com/2017/07/best-di=
fficulty-algorithm-zawy-v1b.html</div><div># My failed attempts at somethin=
g better:</div><div># https://github.com/seredat/karbowanec/commit/231db527=
0acb2e673a641a1800be910ce345668a</div><div>#</div><div># Keep negative solv=
etimes to correct bad timestamps.</div><div># Do not be tempted to use:</di=
v><div># next_D =3D sum(last N Ds) * T / [max(last N TSs) - min(last N TSs]=
;</div><div># D=3Ddifficulty, ST=3D Solvetime, TS =3D timestamp, T=3DTarget=
SolveTime</div><div><br></div><div># set constants until next hard fork:</d=
iv><div><br></div><div>T=3D600;&nbsp;</div><div>N=3D30; # Averaging window.=
 Smoother than N=3D15, faster response than N=3D60.</div><div>X=3D5; # size=
 of sudden hashrate changes expected as multiple of base hashrate.</div><di=
v>limit =3D X^(2/N); # limit rise and fall to protect against timestamp err=
ors &amp; manipulation</div><div>adjust =3D 1/(1+0.67/N);&nbsp; # keeps avg=
 solvetime on track for small N.</div><div><br></div><div># begin difficult=
y algorithm&nbsp;</div><div><br></div><div>avg_ST=3D0; # avg SolveTime</div=
><div>avg_D=3D0;</div><div>for ( i=3Dheight;&nbsp; i &gt; height-N;&nbsp; i=
--) {&nbsp; # go through N most recent blocks</div><div>&nbsp; &nbsp;avg_ST=
 +=3D (TS[i] - TS[i-1]) / N; # TS=3Dtimestamps</div><div>&nbsp; &nbsp;avg_D=
 +=3D D[i]/N;</div><div>}</div><div>avg_ST =3D T*limit if avg_ST &gt; T*lim=
it;&nbsp;</div><div>avg_ST =3D T/limit if avg_ST &lt; T/limit;&nbsp;</div><=
div><br></div><div>next_D =3D avg_D * T / avg_ST * adjust;&nbsp;</div><div>=
<br></div><div># Tim Olsen suggested changing coin reward to protect agains=
t hash attacks.</div><div># Karbowanek coin suggested something similar.</d=
iv><div># After testing many ideas, I could not find anything better than t=
he simplest idea below.</div><div># It was a surprise that coin issuance ra=
te came out perfect.</div><div># BaseReward =3D coins per block</div><div><=
br></div><div>next_reward =3D BaseReward * avg_ST / T;</div><div><br></div>=
<div>=3D=3D=3D=3D=3D=3D=3D end algo =3D=3D=3D=3D</div><div><br></div><div>D=
ue to the limit and keeping negative solvetimes in a true average, timestam=
p errors resulting in negative solvetimes are corrected in the next block. =
Otherwise, one would need to do like Zcash and cause a 5-block delay in the=
 response by resorting to the median of past 11 blocks (MTP) as the most re=
cent timestamp, offsetting the timestamps from their corresponding difficul=
ties by 5 blocks. (it does not cause an averaging problem, but it does caus=
e a 5-block delay in the response.)</div><div><br></div><div>Small N window=
s like keep the correct median, but cause avg solvetime to be above the tar=
get. The "adjust" constant (empirically determined) fixes this, but it caus=
es the median to be that same percentage too low, below the ideal Poisson m=
edian which is 0.693 of the mean. I was not able to find a fix to this that=
 did not slow down the response to hashrate changes.</div></div></div></bod=
y></html>
------=_Part_4256447_1338361221.1507584410824--