From: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative;
	boundary=Apple-Mail-0858C34E-84BB-4B7C-B1DC-EDBB070403C4
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Mon, 9 Oct 2017 19:19:11 -0700
Message-Id: <B34C76A2-4FD7-4BA9-81AD-816B163463C9@friedenbach.org>
References: <1213518291.4328204.1507589852818.ref@mail.yahoo.com>
	<1213518291.4328204.1507589852818@mail.yahoo.com>
In-Reply-To: <1213518291.4328204.1507589852818@mail.yahoo.com>
To: Scott Roberts <zawy@yahoo.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x
	fork? (reformatted text)
Precedence: list


--Apple-Mail-0858C34E-84BB-4B7C-B1DC-EDBB070403C4
Content-Type: text/plain;
	charset=gb2312
Content-Transfer-Encoding: quoted-printable

The problem of fast acting but non vulnerable difficulty adjustment algorith=
ms is interesting. I would certainly like to see this space further explored=
, and even have some ideas myself.

However without commenting on the technical merits of this specific proposal=
, I think it must be said upfront that the stated goal is not good. The larg=
est technical concern (ignoring governance) over B2X is that it is a rushed,=
 poorly reviewed hard fork. Hard forks should not be rushed, and they should=
 receive more than the usual level of expert and community review.

I=A1=AFm that light, doing an even more rushed hard fork on an even newer id=
ea with even less review would be hypocritical at best. I would suggest refr=
aming as a hardfork wishlist research problem for the next properly planned h=
ard fork, if one occurs. You might also find the hardfork research group a m=
ore accommodating venue for this discussion:

https://bitcoinhardforkresearch.github.io/

> On Oct 9, 2017, at 3:57 PM, Scott Roberts via bitcoin-dev <bitcoin-dev@lis=
ts.linuxfoundation.org> wrote:
>=20
> Sorry, my previous email did not have the plain text I intended.
>=20
> Background:=20
>=20
> The bitcoin difficulty algorithm does not seem to be a good one. If there=20=

> is a fork due to miners seeking maximum profit without due regard to=20
> security, users, and nodes, the "better" coin could end up being the=20
> minority chain. If 90% of hashrate is really going to at least initially g=
o=20
> towards using SegWit2x, BTC would face 10x delays in confirmations=20
> until the next difficulty adjustment, negatively affecting its price relat=
ive=20
> to BTC1, causing further delays from even more miner abandonment=20
> (until the next adjustment). The 10% miners remaining on BTC do not=20
> inevitably lose by staying to endure 10x delays because they have 10x=20
> less competition, and the same situation applies to BTC1 miners. If the=20=

> prices are the same and stable, all seems well for everyone, other things=20=

> aside. But if the BTC price does not fall to reflect the decreased hashrat=
e,=20
> he situation seems to be a big problem for both coins: BTC1 miners will=20=

> jump back to BTC when the difficulty adjustment occurs, initiating a=20
> potentially never-ending oscillation between the two coins, potentially=20=

> worse than what BCH is experiencing.  They will not issue coins too fast=20=

> like BCH because that is a side effect of the asymmetry in BCH's rise and=20=

> fall algorithm.=20
>=20
> Solution:=20
>=20
> Hard fork to implement a new difficulty algorithm that uses a simple rolli=
ng=20
> average with a much smaller window.  Many small coins have done this as=20=

> a way to stop big miners from coming on and then suddenly leaving, leaving=
=20
> constant miners stuck with a high difficulty for the rest of a (long) aver=
aging=20
> window.  Even better, adjust the reward based on recent solvetimes to=20
> motivate more mining (or less) if the solvetimes are too slow (or too fast=
).=20
> This will keep keep coin issuance rate perfectly on schedule with real tim=
e.=20
>=20
> I recommend the following for Bitcoin, as fast, simple, and better than an=
y=20
> other difficulty algorithm I'm aware of.  This is the result of a lot of w=
ork the=20
> past year.=20
>=20
> =3D=3D=3D Begin difficulty algorithm =3D=3D=3D=20
> # Zawy v6 difficulty algorithm (modified for bitcoin)=20
> # Unmodified Zawy v6 for alt coins:=20
> # http://zawy1.blogspot.com/2017/07/best-difficulty-algorithm-zawy-v1b.htm=
l=20
> # All my failed attempts at something better:=20
> # https://github.com/seredat/karbowanec/commit/231db5270acb2e673a641a1800b=
e910ce345668a=20
> #=20
> # Keep negative solvetimes to correct bad timestamps.=20
> # Do not be tempted to use:=20
> # next_D =3D sum(last N Ds) * T / [max(last N TSs) - min(last N TSs];=20
> # ST=3D Solvetime, TS =3D timestamp=20
>=20
> # set constants until next hard fork:=20
>=20
> T=3D600; # coin's TargetSolvetime=20
> N=3D30; # Averaging window. Smoother than N=3D15, faster response than N=3D=
60.=20
> X=3D5;=20
> limit =3D X^(2/N); # limit rise and fall in case of timestamp manipulation=
=20
> adjust =3D 1/(1+0.67/N);  # keeps avg solvetime on track=20
>=20
> # begin difficulty algorithm=20
>=20
> avg_ST=3D0; avg_D=3D0;=20
> for ( i=3Dheight;  i > height-N;  i--) {  # go through N most recent block=
s=20
> avg_ST +=3D (TS[i] - TS[i-1]) / N;=20
> avg_D +=3D D[i]/N;=20
> }=20
> avg_ST =3D T*limit if avg_ST > T*limit;=20
> avg_ST =3D T/limit if avg_ST < T/limit;=20
>=20
> next_D =3D avg_D * T / avg_ST * adjust;=20
>=20
> # Tim Olsen suggested changing reward to protect against hash attacks.=20
> # Karbowanek coin suggested something similar.=20
> # I could not find anything better than the simplest idea below.=20
> # It was a great surprise that coin issuance rate came out perfect.=20
> # BaseReward =3D coins per block=20
>=20
> next_reward =3D BaseReward * avg_ST / T;=20
>=20
> =3D=3D=3D=3D=3D=3D=3D end algo =3D=3D=3D=3D=20
>=20
> Due to the limit and keeping negative solvetimes in a true average,=20
> timestamp errors resulting in negative solvetimes are corrected in the nex=
t=20
> block. Otherwise, one would need to do like Zcash and cause a 5-block=20
> delay in the response by resorting to the median of past 11 blocks (MPT)=20=

> as the most recent timestamp, offsetting the timestamps from their=20
> corresponding difficulties by 5 blocks. (it does not cause an averaging=20=

> problem, but it does cause a 5-block delay in the response.)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-0858C34E-84BB-4B7C-B1DC-EDBB070403C4
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">The problem of fast acting but non vulnerab=
le difficulty adjustment algorithms is interesting. I would certainly like t=
o see this space further explored, and even have some ideas myself.<div><br>=
</div><div>However without commenting on the technical merits of this specif=
ic proposal, I think it must be said upfront that the stated goal is not goo=
d. The largest technical concern (ignoring governance) over B2X is that it i=
s a rushed, poorly reviewed hard fork. Hard forks should not be rushed, and t=
hey should receive more than the usual level of expert and community review.=
</div><div><br></div><div>I=E2=80=99m that light, doing an even more rushed h=
ard fork on an even newer idea with even less review would be hypocritical a=
t best. I would suggest reframing as a hardfork wishlist research problem fo=
r the next properly planned hard fork, if one occurs. You might also find th=
e hardfork research group a more accommodating venue for this discussion:</d=
iv><div><br></div><div><a href=3D"https://bitcoinhardforkresearch.github.io/=
">https://bitcoinhardforkresearch.github.io/</a></div><div><div><br>On Oct 9=
, 2017, at 3:57 PM, Scott Roberts via bitcoin-dev &lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>=
&gt; wrote:<br><br></div><blockquote type=3D"cite"><div><span>Sorry, my prev=
ious email did not have the plain text I intended.</span><br><span></span><b=
r><span>Background: </span><br><span></span><br><span>The bitcoin difficulty=
 algorithm does not seem to be a good one. If there </span><br><span>is a fo=
rk due to miners seeking maximum profit without due regard to </span><br><sp=
an>security, users, and nodes, the "better" coin could end up being the </sp=
an><br><span>minority chain. If 90% of hashrate is really going to at least i=
nitially go </span><br><span>towards using SegWit2x, BTC would face 10x dela=
ys in confirmations </span><br><span>until the next difficulty adjustment, n=
egatively affecting its price relative </span><br><span>to BTC1, causing fur=
ther delays from even more miner abandonment </span><br><span>(until the nex=
t adjustment). The 10% miners remaining on BTC do not </span><br><span>inevi=
tably lose by staying to endure 10x delays because they have 10x </span><br>=
<span>less competition, and the same situation applies to BTC1 miners. If th=
e </span><br><span>prices are the same and stable, all seems well for everyo=
ne, other things </span><br><span>aside. But if the BTC price does not fall t=
o reflect the decreased hashrate, </span><br><span>he situation seems to be a=
 big problem for both coins: BTC1 miners will </span><br><span>jump back to B=
TC when the difficulty adjustment occurs, initiating a </span><br><span>pote=
ntially never-ending oscillation between the two coins, potentially </span><=
br><span>worse than what BCH is experiencing. &nbsp;They will not issue coin=
s too fast </span><br><span>like BCH because that is a side effect of the as=
ymmetry in BCH's rise and </span><br><span>fall algorithm. </span><br><span>=
</span><br><span>Solution: </span><br><span></span><br><span>Hard fork to im=
plement a new difficulty algorithm that uses a simple rolling </span><br><sp=
an>average with a much smaller window. &nbsp;Many small coins have done this=
 as </span><br><span>a way to stop big miners from coming on and then sudden=
ly leaving, leaving </span><br><span>constant miners stuck with a high diffi=
culty for the rest of a (long) averaging </span><br><span>window. &nbsp;Even=
 better, adjust the reward based on recent solvetimes to </span><br><span>mo=
tivate more mining (or less) if the solvetimes are too slow (or too fast). <=
/span><br><span>This will keep keep coin issuance rate perfectly on schedule=
 with real time. </span><br><span></span><br><span>I recommend the following=
 for Bitcoin, as fast, simple, and better than any </span><br><span>other di=
fficulty algorithm I'm aware of. &nbsp;This is the result of a lot of work t=
he </span><br><span>past year. </span><br><span></span><br><span>=3D=3D=3D B=
egin difficulty algorithm =3D=3D=3D </span><br><span># Zawy v6 difficulty al=
gorithm (modified for bitcoin) </span><br><span># Unmodified Zawy v6 for alt=
 coins: </span><br><span># <a href=3D"http://zawy1.blogspot.com/2017/07/best=
-difficulty-algorithm-zawy-v1b.html">http://zawy1.blogspot.com/2017/07/best-=
difficulty-algorithm-zawy-v1b.html</a> </span><br><span># All my failed atte=
mpts at something better: </span><br><span># <a href=3D"https://github.com/s=
eredat/karbowanec/commit/231db5270acb2e673a641a1800be910ce345668a">https://g=
ithub.com/seredat/karbowanec/commit/231db5270acb2e673a641a1800be910ce345668a=
</a> </span><br><span># </span><br><span># Keep negative solvetimes to corre=
ct bad timestamps. </span><br><span># Do not be tempted to use: </span><br><=
span># next_D =3D sum(last N Ds) * T / [max(last N TSs) - min(last N TSs]; <=
/span><br><span># ST=3D Solvetime, TS =3D timestamp </span><br><span></span>=
<br><span># set constants until next hard fork: </span><br><span></span><br>=
<span>T=3D600; # coin's TargetSolvetime </span><br><span>N=3D30; # Averaging=
 window. Smoother than N=3D15, faster response than N=3D60. </span><br><span=
>X=3D5; </span><br><span>limit =3D X^(2/N); # limit rise and fall in case of=
 timestamp manipulation </span><br><span>adjust =3D 1/(1+0.67/N); &nbsp;# ke=
eps avg solvetime on track </span><br><span></span><br><span># begin difficu=
lty algorithm </span><br><span></span><br><span>avg_ST=3D0; avg_D=3D0; </spa=
n><br><span>for ( i=3Dheight; &nbsp;i &gt; height-N; &nbsp;i--) { &nbsp;# go=
 through N most recent blocks </span><br><span>avg_ST +=3D (TS[i] - TS[i-1])=
 / N; </span><br><span>avg_D +=3D D[i]/N; </span><br><span>} </span><br><spa=
n>avg_ST =3D T*limit if avg_ST &gt; T*limit; </span><br><span>avg_ST =3D T/l=
imit if avg_ST &lt; T/limit; </span><br><span></span><br><span>next_D =3D av=
g_D * T / avg_ST * adjust; </span><br><span></span><br><span># Tim Olsen sug=
gested changing reward to protect against hash attacks. </span><br><span># K=
arbowanek coin suggested something similar. </span><br><span># I could not f=
ind anything better than the simplest idea below. </span><br><span># It was a=
 great surprise that coin issuance rate came out perfect. </span><br><span>#=
 BaseReward =3D coins per block </span><br><span></span><br><span>next_rewar=
d =3D BaseReward * avg_ST / T; </span><br><span></span><br><span>=3D=3D=3D=3D=
=3D=3D=3D end algo =3D=3D=3D=3D </span><br><span></span><br><span>Due to the=
 limit and keeping negative solvetimes in a true average, </span><br><span>t=
imestamp errors resulting in negative solvetimes are corrected in the next <=
/span><br><span>block. Otherwise, one would need to do like Zcash and cause a=
 5-block </span><br><span>delay in the response by resorting to the median o=
f past 11 blocks (MPT) </span><br><span>as the most recent timestamp, offset=
ting the timestamps from their </span><br><span>corresponding difficulties b=
y 5 blocks. (it does not cause an averaging </span><br><span>problem, but it=
 does cause a 5-block delay in the response.)</span><br><span>______________=
_________________________________</span><br><span>bitcoin-dev mailing list</=
span><br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-dev@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lis=
ts.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoun=
dation.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></d=
iv></body></html>=

--Apple-Mail-0858C34E-84BB-4B7C-B1DC-EDBB070403C4--