Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D69B0721 for ; 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 ; Tue, 10 Oct 2017 02:57:25 +0000 (UTC) Received: by mail-wm0-f54.google.com with SMTP id q124so1174254wmb.0 for ; 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: References: <1213518291.4328204.1507589852818.ref@mail.yahoo.com> <1213518291.4328204.1507589852818@mail.yahoo.com> From: Ben Kloester Date: Tue, 10 Oct 2017 13:57:23 +1100 Message-ID: To: Mark Friedenbach , Bitcoin Protocol Discussion 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 , 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
Is there a contingency plan in the case that the incumbent= chain following the Bitcoin Core consensus rules comes under 51% attack?= =C2=A0

If the 2x fork really does have the support of &g= t;66% of miners (which remains to be seen), it seems like they'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?

I'm aware of Luke's work on=C2=A0BitcoinHardfork, 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?

Ben Kloe= ster


On 10 October 2017 at 13:19, Mark Friedenbac= h via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.o= rg> wrote:
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.

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


On Oct 9, 2017, at 3:57 PM, Scott Roberts via = bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Sorry, my previous email d= id not have the plain text I intended.

Bac= kground:

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
secur= ity, users, and nodes, the "better" coin could end up being the <= /span>
minority chain. If 90% of hashrate is really going to at le= ast initially go
towards using SegWit2x, BTC would face 10= x delays in confirmations
until the next difficulty adjust= ment, negatively affecting its price relative
to BTC1, cau= sing further delays from even more miner abandonment
(unti= l the next adjustment). The 10% miners remaining on BTC do not
<= span>inevitably lose by staying to endure 10x delays because they have 10x =
less competition, and the same situation applies to BTC1 m= iners. If the
prices are the same and stable, all seems we= ll for everyone, other things
aside. But if the BTC price = does not fall to reflect the decreased hashrate,
he situat= ion seems to be a big problem for both coins: BTC1 miners will
<= span>jump back to BTC when the difficulty adjustment occurs, initiating a <= /span>
potentially never-ending oscillation between the two coins,= potentially
worse than what BCH is experiencing.=C2=A0 Th= ey 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.=C2=A0 = Many small coins have done this as
a way to stop big miner= s from coming on and then suddenly leaving, leaving
consta= nt miners stuck with a high difficulty for the rest of a (long) averaging <= /span>
window.=C2=A0 Even better, adjust the reward based on recen= t solvetimes to
motivate more mining (or less) if the solv= etimes are too slow (or too fast).
This will keep keep coi= n issuance rate perfectly on schedule with real time.

I recommend the following for Bitcoin, as fast, simple, and be= tter 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 algorithm (modified for bitcoi= n)
# Unmodified Zawy v6 for alt coins:
# = http://zawy1.blogspot.com/2017/07/best-di= fficulty-algorithm-zawy-v1b.html
# All my failed = attempts at something better:
# https://github.com/seredat/karbowanec/commit/231db= 5270acb2e673a641a1800be910ce345668a
#
= # 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 Solvetim= e, TS =3D timestamp

# set constants until= next hard fork:

T=3D600; # coin's Ta= rgetSolvetime
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); =C2=A0# keeps avg solvetime on = track

# begin difficulty algorithm

avg_ST=3D0; avg_D=3D0;
for ( i= =3Dheight; =C2=A0i > height-N; =C2=A0i--) { =C2=A0# go through N most re= cent blocks
avg_ST +=3D (TS[i] - TS[i-1]) / N;
= avg_D +=3D D[i]/N;
}
avg_ST =3D T*l= imit 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 changi= ng reward to protect against hash attacks.
# Karbowanek co= in suggested something similar.
# I could not find anythin= g better than the simplest idea below.
# It was a great su= rprise that coin issuance rate came out perfect.
# BaseRew= ard =3D coins per block

next_reward =3D B= aseReward * avg_ST / T;

=3D=3D=3D=3D=3D= =3D=3D end algo =3D=3D=3D=3D

Due to the l= imit and keeping negative solvetimes in a true average,
ti= mestamp errors resulting in negative solvetimes are corrected in the next <= /span>
block. Otherwise, one would need to do like Zcash and cause= a 5-block
delay in the response by resorting to the media= n of past 11 blocks (MPT)
as the most recent timestamp, of= fsetting the timestamps from their
corresponding difficult= ies by 5 blocks. (it does not cause an averaging
problem, = but it does cause a 5-block delay in the response.)
_______= ________________________________________
bitcoin-dev m= ailing list
bitcoin-dev@lists.linuxfoundation.org<= /span>
https://lists.linuxfoundation.org/ma= ilman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--f403043a0ddc6ab839055b287733--