path: root/8e/ea02cd5ec8845ffe28bb2e61da224c5a05e267

Return-Path: <benkloester@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D69B0721
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 10 Oct 2017 02:57:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7A32C455
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 10 Oct 2017 02:57:25 +0000 (UTC)
Received: by mail-wm0-f54.google.com with SMTP id q124so1174254wmb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 09 Oct 2017 19:57:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=YtjO7jKhnCdPwmjbSKneOi/ZNDVREeH3D7mvtrazV90=;
	b=toU4xONrBZNXFYpRIsZx4TiPFNBErNvQgapEcZD0SIDcD/9CTF7c9DP80vjwqZ64PW
	yvYunmwXpajOV8/UYr8IhhmN7Zhq3Bfm37k1bNfgwbvtyirl65pkFAXAwwypx8xXbkh5
	TZRzlPQZzBh9jQ16T+FBNh8bwYEc2mhW9UbbI8T0X49PUMBDMbulMYJAeG1mDpEhNiIc
	5j6fDTsBP9Y7PcNLU00cz7fRj5uRMN4NE4CVcr/agdhxwOJAMIhaaDcllS9rw7vYOFHT
	zgmoNxYh9dYtZH7O8F7EwXMdSJwbwFBn/dVOOv9/OYT40tHmHVByr/KO2Wqm7lOXVIX/
	fTPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=YtjO7jKhnCdPwmjbSKneOi/ZNDVREeH3D7mvtrazV90=;
	b=LVug5mz1rXx4y7jSEG8Ie7FGcGjNlN8cHLRhjkLqzwKYSv2SKpZJc6reZfpKx1dmK0
	LJnPGHsVEINA7sQ/Hmr3Vf9KjRkbtWfg19MIuqACaD7Py7mqh9E2WUXz+hGF686pXCI9
	76VT97lRLUY3oWLT7fWq7tvbbtRz3YjjG8638mQIlAWcyRJwNrXR09unredvLkcsaJSd
	4NvZqtSalQFlEwspGXxq/ETGjrnmHep3zSGGnaSBfXyKPNA4qhjowtd74MULOpLBgt3Z
	ZY5xhC8ckKTygAcHXgt4H7q8kqfXDBekZphFkg8bnZNMwv9ou+nY7SlXS5BokTNIAvC8
	PNEQ==
X-Gm-Message-State: AMCzsaUPUDZ+A6QPmsaX4qeLpT08IUNO4apIZ4Eq0nM/zkdxsHipYQWn
	e4okA68JA6TtiVazhtiEqEL5QI6AALrEbff1fhN6klJf
X-Google-Smtp-Source: AOwi7QCfFbGVDlDzub7K3xDX3iRdd5/Xlm2AkdxAp4eyw2QRM7L1xLmvzjj2BkwP8+JYVI1luxT1WeVggOCf7wb6ot4=
X-Received: by 10.223.182.80 with SMTP id i16mr10672043wre.110.1507604243854; 
	Mon, 09 Oct 2017 19:57:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.143.102 with HTTP; Mon, 9 Oct 2017 19:57:23 -0700 (PDT)
In-Reply-To: <B34C76A2-4FD7-4BA9-81AD-816B163463C9@friedenbach.org>
References: <1213518291.4328204.1507589852818.ref@mail.yahoo.com>
	<1213518291.4328204.1507589852818@mail.yahoo.com>
	<B34C76A2-4FD7-4BA9-81AD-816B163463C9@friedenbach.org>
From: Ben Kloester <benkloester@gmail.com>
Date: Tue, 10 Oct 2017 13:57:23 +1100
Message-ID: <CANgJ=T8M1fYFBai7gJA=Znmix9WKfRxm7y9yQbJhB282SgDtTg@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="f403043a0ddc6ab839055b287733"
X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
X-Mailman-Approved-At: Tue, 10 Oct 2017 03:17:37 +0000
Cc: Scott Roberts <zawy@yahoo.com>
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:57:26 -0000

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

Is there a contingency plan in the case that the incumbent chain following
the Bitcoin Core consensus rules comes under 51% attack?

If the 2x fork really does have the support of >66% of miners (which
remains to be seen), it seems like they'd have spare capacity to perform
such an attack. In which case, a rushed hard fork might be the only option
to guarantee the survival of the chain, would it not?

I'm aware of Luke's work on BitcoinHardfork
<https://github.com/BitcoinHardfork>, but not aware of whether this has
actually been tested in the field by anyone - ie whether anyone actually
has even run the code much / created a testnet. What are the options for an
emergency hard fork, and how much testing has each seen?

*Ben Kloester*

On 10 October 2017 at 13:19, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The problem of fast acting but non vulnerable difficulty adjustment
> algorithms is interesting. I would certainly like to see this space furth=
er
> 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 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
> they should receive more than the usual level of expert and community
> review.
>
> I=E2=80=99m that light, doing an even more rushed hard fork on an even ne=
wer idea
> with even less review would be hypocritical at best. I would suggest
> reframing as a hardfork wishlist research problem for the next properly
> planned hard fork, if one occurs. You might also find the hardfork resear=
ch
> group a more accommodating venue for this discussion:
>
> https://bitcoinhardforkresearch.github.io/
>
> On Oct 9, 2017, at 3:57 PM, Scott Roberts via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Sorry, my previous email did not have the plain text I intended.
>
> Background:
>
> The bitcoin difficulty algorithm does not seem to be a good one. If there
> is a fork due to miners seeking maximum profit without 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 initially
> go
> towards using SegWit2x, BTC would face 10x delays in confirmations
> until the next difficulty adjustment, negatively affecting its price
> relative
> to BTC1, causing further delays from even more miner abandonment
> (until the next adjustment). The 10% miners remaining on BTC do not
> inevitably lose by staying to endure 10x delays because they have 10x
> less competition, and the same situation applies to BTC1 miners. If the
> prices are the same and stable, all seems well for everyone, other things
> aside. But if the BTC price does not fall to reflect the decreased
> hashrate,
> he situation 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-ending oscillation between the two coins, potentially
> worse than what BCH is experiencing.  They will not issue coins too fast
> like BCH because that is a side effect of the asymmetry in BCH's rise and
> fall algorithm.
>
> Solution:
>
> Hard fork to implement a new difficulty algorithm that uses a simple
> rolling
> average with a much smaller window.  Many small coins have done this as
> a way to stop big miners from coming on and then suddenly leaving, leavin=
g
> constant miners stuck with a high difficulty for the rest of a (long)
> averaging
> window.  Even better, adjust the reward based on recent solvetimes to
> motivate more mining (or less) if the solvetimes are too slow (or too
> fast).
> This will keep keep coin issuance rate perfectly on schedule with real
> time.
>
> I recommend the following for Bitcoin, as fast, simple, and better than
> any
> other difficulty algorithm I'm aware of.  This is the result of a lot of
> work the
> past year.
>
> =3D=3D=3D Begin difficulty algorithm =3D=3D=3D
> # Zawy v6 difficulty algorithm (modified for bitcoin)
> # Unmodified Zawy v6 for alt coins:
> # http://zawy1.blogspot.com/2017/07/best-difficulty-
> algorithm-zawy-v1b.html
> # All my failed attempts at something better:
> # https://github.com/seredat/karbowanec/commit/
> 231db5270acb2e673a641a1800be910ce345668a
> #
> # Keep negative solvetimes to correct bad timestamps.
> # Do not be tempted to use:
> # next_D =3D sum(last N Ds) * T / [max(last N TSs) - min(last N TSs];
> # ST=3D Solvetime, TS =3D timestamp
>
> # set constants until next hard fork:
>
> T=3D600; # coin's TargetSolvetime
> N=3D30; # Averaging window. Smoother than N=3D15, faster response than N=
=3D60.
> X=3D5;
> limit =3D X^(2/N); # limit rise and fall in case of timestamp manipulatio=
n
> adjust =3D 1/(1+0.67/N);  # keeps avg solvetime on track
>
> # begin difficulty algorithm
>
> avg_ST=3D0; avg_D=3D0;
> for ( i=3Dheight;  i > height-N;  i--) {  # go through N most recent bloc=
ks
> avg_ST +=3D (TS[i] - TS[i-1]) / N;
> avg_D +=3D D[i]/N;
> }
> avg_ST =3D T*limit if avg_ST > T*limit;
> avg_ST =3D T/limit if avg_ST < T/limit;
>
> next_D =3D avg_D * T / avg_ST * adjust;
>
> # Tim Olsen suggested changing reward to protect against hash attacks.
> # Karbowanek coin suggested something similar.
> # I could not find anything better than the simplest idea below.
> # It was a great surprise that coin issuance rate came out perfect.
> # BaseReward =3D coins per block
>
> 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,
> timestamp 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 (MPT)
> as the most recent timestamp, offsetting the timestamps from their
> corresponding difficulties by 5 blocks. (it does not cause an averaging
> 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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

<div dir=3D"ltr">Is there a contingency plan in the case that the incumbent=
 chain following the Bitcoin Core consensus rules comes under 51% attack?=
=C2=A0<div><br></div><div>If the 2x fork really does have the support of &g=
t;66% of miners (which remains to be seen), it seems like they&#39;d have s=
pare capacity to perform such an attack. In which case, a rushed hard fork =
might be the only option to guarantee the survival of the chain, would it n=
ot?<br><br>I&#39;m aware of Luke&#39;s work on=C2=A0<a href=3D"https://gith=
ub.com/BitcoinHardfork" class=3D"gmail-url gmail-fn" rel=3D"author" style=
=3D"background-color:transparent;font-family:-apple-system,BlinkMacSystemFo=
nt,&quot;Segoe UI&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&=
quot;,&quot;Segoe UI Emoji&quot;,&quot;Segoe UI Symbol&quot;;box-sizing:bor=
der-box;color:rgb(3,102,214);outline-width:0px">BitcoinHardfork</a>, but no=
t aware of whether this has actually been tested in the field by anyone - i=
e whether anyone actually has even run the code much / created a testnet. W=
hat are the options for an emergency hard fork, and how much testing has ea=
ch seen?</div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div =
class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><p><b>Ben Kloe=
ster</b><br><span style=3D"font-size:10.0pt;color:#595959"></span></p></div=
></div>
<br><div class=3D"gmail_quote">On 10 October 2017 at 13:19, Mark Friedenbac=
h via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.o=
rg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto=
">The problem of fast acting but non vulnerable difficulty adjustment algor=
ithms is interesting. I would certainly like to see this space further expl=
ored, and even have some ideas myself.<div><br></div><div>However without c=
ommenting on the technical merits of this specific proposal, I think it mus=
t be said upfront that the stated goal is not good. The largest technical c=
oncern (ignoring governance) over B2X is that it is a rushed, poorly review=
ed hard fork. Hard forks should not be rushed, and they 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 hard fork on an even =
newer idea with even less review would be hypocritical at best. I would sug=
gest reframing as a hardfork wishlist research problem for the next properl=
y planned hard fork, if one occurs. You might also find the hardfork resear=
ch group a more accommodating venue for this discussion:</div><div><br></di=
v><div><a href=3D"https://bitcoinhardforkresearch.github.io/" target=3D"_bl=
ank">https://<wbr>bitcoinhardforkresearch.<wbr>github.io/</a></div><div><di=
v class=3D"h5"><div><div><br>On Oct 9, 2017, at 3:57 PM, Scott Roberts via =
bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<b=
r><br></div><blockquote type=3D"cite"><div><span>Sorry, my previous email d=
id not have the plain text I intended.</span><br><span></span><br><span>Bac=
kground: </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 fork due to=
 miners seeking maximum profit without due regard to </span><br><span>secur=
ity, users, and nodes, the &quot;better&quot; coin could end up being the <=
/span><br><span>minority chain. If 90% of hashrate is really going to at le=
ast initially go </span><br><span>towards using SegWit2x, BTC would face 10=
x delays in confirmations </span><br><span>until the next difficulty adjust=
ment, negatively affecting its price relative </span><br><span>to BTC1, cau=
sing further delays from even more miner abandonment </span><br><span>(unti=
l the next adjustment). The 10% miners remaining on BTC do not </span><br><=
span>inevitably lose by staying to endure 10x delays because they have 10x =
</span><br><span>less competition, and the same situation applies to BTC1 m=
iners. If the </span><br><span>prices are the same and stable, all seems we=
ll for everyone, other things </span><br><span>aside. But if the BTC price =
does not fall to reflect the decreased hashrate, </span><br><span>he situat=
ion seems to be a big problem for both coins: BTC1 miners will </span><br><=
span>jump back to BTC when the difficulty adjustment occurs, initiating a <=
/span><br><span>potentially never-ending oscillation between the two coins,=
 potentially </span><br><span>worse than what BCH is experiencing.=C2=A0 Th=
ey will not issue coins too fast </span><br><span>like BCH because that is =
a side effect of the asymmetry in BCH&#39;s rise and </span><br><span>fall =
algorithm. </span><br><span></span><br><span>Solution: </span><br><span></s=
pan><br><span>Hard fork to implement a new difficulty algorithm that uses a=
 simple rolling </span><br><span>average with a much smaller window.=C2=A0 =
Many small coins have done this as </span><br><span>a way to stop big miner=
s from coming on and then suddenly leaving, leaving </span><br><span>consta=
nt miners stuck with a high difficulty for the rest of a (long) averaging <=
/span><br><span>window.=C2=A0 Even better, adjust the reward based on recen=
t solvetimes to </span><br><span>motivate more mining (or less) if the solv=
etimes are too slow (or too fast). </span><br><span>This will keep keep coi=
n issuance rate perfectly on schedule with real time. </span><br><span></sp=
an><br><span>I recommend the following for Bitcoin, as fast, simple, and be=
tter than any </span><br><span>other difficulty algorithm I&#39;m aware of.=
=C2=A0 This is the result of a lot of work the </span><br><span>past year. =
</span><br><span></span><br><span>=3D=3D=3D Begin difficulty algorithm =3D=
=3D=3D </span><br><span># Zawy v6 difficulty algorithm (modified for bitcoi=
n) </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" target=3D"_blank">http://zawy1.blogspot.com/<wbr>2017/07/best-di=
fficulty-<wbr>algorithm-zawy-v1b.html</a> </span><br><span># All my failed =
attempts at something better: </span><br><span># <a href=3D"https://github.=
com/seredat/karbowanec/commit/231db5270acb2e673a641a1800be910ce345668a" tar=
get=3D"_blank">https://github.com/seredat/<wbr>karbowanec/commit/<wbr>231db=
5270acb2e673a641a1800be91<wbr>0ce345668a</a> </span><br><span># </span><br>=
<span># Keep negative solvetimes to correct bad timestamps. </span><br><spa=
n># 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 Solvetim=
e, TS =3D timestamp </span><br><span></span><br><span># set constants until=
 next hard fork: </span><br><span></span><br><span>T=3D600; # coin&#39;s Ta=
rgetSolvetime </span><br><span>N=3D30; # Averaging window. Smoother than N=
=3D15, faster response than N=3D60. </span><br><span>X=3D5; </span><br><spa=
n>limit =3D X^(2/N); # limit rise and fall in case of timestamp manipulatio=
n </span><br><span>adjust =3D 1/(1+0.67/N); =C2=A0# keeps avg solvetime on =
track </span><br><span></span><br><span># begin difficulty algorithm </span=
><br><span></span><br><span>avg_ST=3D0; avg_D=3D0; </span><br><span>for ( i=
=3Dheight; =C2=A0i &gt; height-N; =C2=A0i--) { =C2=A0# go through N most re=
cent 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><span>avg_ST =3D T*l=
imit if avg_ST &gt; T*limit; </span><br><span>avg_ST =3D T/limit if avg_ST =
&lt; T/limit; </span><br><span></span><br><span>next_D =3D avg_D * T / avg_=
ST * adjust; </span><br><span></span><br><span># Tim Olsen suggested changi=
ng reward to protect against hash attacks. </span><br><span># Karbowanek co=
in suggested something similar. </span><br><span># I could not find anythin=
g better than the simplest idea below. </span><br><span># It was a great su=
rprise that coin issuance rate came out perfect. </span><br><span># BaseRew=
ard =3D coins per block </span><br><span></span><br><span>next_reward =3D B=
aseReward * 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 l=
imit and keeping negative solvetimes in a true average, </span><br><span>ti=
mestamp 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 media=
n of past 11 blocks (MPT) </span><br><span>as the most recent timestamp, of=
fsetting the timestamps from their </span><br><span>corresponding difficult=
ies by 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>_______=
_______________________<wbr>_________________</span><br><span>bitcoin-dev m=
ailing list</span><br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><=
/span><br><span><a href=3D"https://lists.linuxfoundation.org/mailman/listin=
fo/bitcoin-dev" target=3D"_blank">https://lists.linuxfoundation.<wbr>org/ma=
ilman/listinfo/bitcoin-<wbr>dev</a></span><br></div></blockquote></div></di=
v></div></div><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>
<br></blockquote></div><br></div>

--f403043a0ddc6ab839055b287733--