path: root/26/c9c9a395e0b064508b9941deb7ba28624dc48a

Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 50F27722
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 10 Oct 2017 02:19:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f182.google.com (mail-pf0-f182.google.com
	[209.85.192.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7BEA8422
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 10 Oct 2017 02:19:13 +0000 (UTC)
Received: by mail-pf0-f182.google.com with SMTP id b85so4503514pfj.13
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 09 Oct 2017 19:19:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
	h=from:content-transfer-encoding:mime-version:date:subject:message-id
	:references:in-reply-to:to;
	bh=UrHpNpiGXYad+c8/Fg7n5ibh6E8sVm/lIk07W7Zw7L0=;
	b=mmKNwZlh/1oC2DUE9qQ/8lE3+LXTGiaw1PpGBfmIVl94cNuwEufHRVDqsR2tL7jG2s
	E5DvSE+UvqFBR9foNdulf+W6lL35n+9ayBeY8bD956w53u6Umr0ase9SaAuDJUjmqSzL
	R56Yv2oHjMSg60OeLvp3OoldrvR90k29KepvOszhm54rCvopPqWKxj3jWtlLIGGGNr5G
	a52HvtNgJxUnxq+Ew/vWYEQCJaOsGwI3v4NwbUdrFAklE3vWD9VG31nmO8ByS1Eq9imJ
	TkN4us+Zas+X6CXV8WeuMbq7ICIJ5b08u0x75Ht0mHh2dYvMz4UESEkI6sadzZ8bNaNr
	1zZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:content-transfer-encoding:mime-version:date
	:subject:message-id:references:in-reply-to:to;
	bh=UrHpNpiGXYad+c8/Fg7n5ibh6E8sVm/lIk07W7Zw7L0=;
	b=mvLkyAkXl+JUro2FDKLS4ZQOLtOU2wzKXAE2dtZta2Ozsvt648OCTlVOc6PUcU0mnL
	O9ceF1XMxWq/RoAXij7xJaxEeTCR07GPYRZJGrzyRsdKYx3L/NbEO7tO2s8WVznIwExO
	74MqWiroZ9nYNh8AlpgpJJYcCKEd5A0tLxvnSA9iMkBTRuyKZUfQjKfSBTdkBn5ioSS/
	vie1O+Y1iWR23ieG8BfFyFlP9epx/p0eGhZCP/qFghUcz9HERQXLccIA7wmWn+A0PEIk
	TmISPu2UMAlkubF8TPlvOIh/RYci53GWUpYrujv92OuJAFPsw4FKiDXqK9MPgVWfvmuo
	mQSA==
X-Gm-Message-State: AMCzsaVM8jxbCg+TGFsqIlgdS/7XwGxUMNPxqNpU0hcLu5S+UC8xd8GN
	Q2DsLR4+JdbgXg4Xwo83dM837FEZtFA=
X-Google-Smtp-Source: AOwi7QAwm/rEKxFD4wrFp6UAc6R/bLaC9/oroSPTgNjKJ8lIGM6No8wmgP0SQwdzpoiRhUReGFPbmg==
X-Received: by 10.98.213.194 with SMTP id d185mr11951623pfg.107.1507601952951; 
	Mon, 09 Oct 2017 19:19:12 -0700 (PDT)
Received: from ?IPv6:2601:646:8080:1291:649b:a2e9:4254:d68f?
	([2601:646:8080:1291:649b:a2e9:4254:d68f])
	by smtp.gmail.com with ESMTPSA id
	q69sm6294526pfg.127.2017.10.09.19.19.12
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 09 Oct 2017 19:19:12 -0700 (PDT)
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>
X-Mailer: iPhone Mail (15A402)
X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE autolearn=disabled
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] New difficulty algorithm needed for SegWit2x
	fork? (reformatted text)
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: Tue, 10 Oct 2017 02:19:16 -0000


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