Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 96A0D97 for ; Wed, 11 Oct 2017 01:44:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f180.google.com (mail-wr0-f180.google.com [209.85.128.180]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 46D134F3 for ; Wed, 11 Oct 2017 01:44:54 +0000 (UTC) Received: by mail-wr0-f180.google.com with SMTP id l1so110060wrc.3 for ; Tue, 10 Oct 2017 18:44:54 -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=5AH8jCS8Lkn6ofmC2ZMCGxuheTMq1CwPT6p036wy8vc=; b=NdSefVCHrw1rBirrJIrYoFn2kvOvl+M+VES5CPNom+f5othmHqXkvyINsrJpn/kL4e rqrZspmVYZxXJP5GcHRNSV1aPr2M+Lcn+Ft/MXoD83/NonTppyPVowXSJV2lkP9hWy9m L835HFCXqlcQdhEnVE1uNqKJ8tKSNxxJJj+HHQDYkaPMuDKHKMW4W1OYTRw3J35FkGKO B2pWDB0FsBRkm9bqYQTeUPX1rOIrxHFnyaqMwF8wVjFJILOPu/ipOGqW25k7F9dmBbRB XgQgOqYEhQFqjXZXkDzGdv8GPN7rH+K5GGoY7uhxF7V1IROd0JRB+NPP5SNtzMtyLFcE UcqA== 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=5AH8jCS8Lkn6ofmC2ZMCGxuheTMq1CwPT6p036wy8vc=; b=XC+BhHmXDrR1n7jXjWyb3f5r3VX3pTImyWDSNEPt+vWO2DN/r/Mk9WmLql9pAbstHv Cv1USDFh+cm4YE1MfWYRaQj0x+YhvbvSMYhPTzX7XKC2S3qnijvHhqExI6V1/n02PfHI Gr6K9ML7qftRB3bxtMpJMB2FZbzSVbWLTGlQtis2zKziu+N+BknWuZnai1ez1/SICAhm w/Wtj3o48XRa3CosBXqPrEqzonAh1ZdDns2ShdOtCwmyEEE/ThGslt5lMeWImAvGdscw ExlnncIo2XtSwIDuvbEqg1ph2EYNZbFrN3LFolnxsI0qSXn8fkpogD4KE4l694spFL7o +jAQ== X-Gm-Message-State: AMCzsaUsih0DMUB8BXg5cYE9fBmkdPROQ6stmQExps8+zIuwl01egoXF QjNuX2yj1hNJh4qs3vflfeyhnE/qxh3b7zB2SF4= X-Google-Smtp-Source: AOwi7QCrCLIPmLS4gdIFJirrM0spFXqYVw0yltTH7l9wnObocq2MfIgwu5qQjJ94UvmdfjStqVSkJphkPaMITOZhsMA= X-Received: by 10.223.129.198 with SMTP id 64mr13236164wra.59.1507686292674; Tue, 10 Oct 2017 18:44:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.143.102 with HTTP; Tue, 10 Oct 2017 18:44:52 -0700 (PDT) In-Reply-To: References: <1213518291.4328204.1507589852818.ref@mail.yahoo.com> <1213518291.4328204.1507589852818@mail.yahoo.com> From: Ben Kloester Date: Wed, 11 Oct 2017 12:44:52 +1100 Message-ID: To: Mark Friedenbach , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a1148fdc2e85f5d055b3b91bf" 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: Wed, 11 Oct 2017 01:48:31 +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: Wed, 11 Oct 2017 01:44:55 -0000 --001a1148fdc2e85f5d055b3b91bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mark, this seems an awful lot like an answer of "no", to my question "Is there a contingency plan in the case that the incumbent chain following the Bitcoin Core consensus rules comes under 51% attack?" - is this a correct interpretation? In fact, beyond a no, it seems like a "no, and I disagree with the idea of creating one". So if Bitcoin comes under successful 51%, the project, in your vision, has simply failed? *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 > > --001a1148fdc2e85f5d055b3b91bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mark, this seems an awful lot like an answer of "no&q= uot;, to my question "Is there a cont= ingency plan in the case that the incumbent chain following the Bitcoin Cor= e consensus rules comes under 51% attack?" - is this a correct interpr= etation?

= In fact, beyond a no, it seems like a &quo= t;no, and I disagree with the idea of creating one".
=
So if Bitcoin comes under successful 51%, the project, in your= vision, has simply failed?

Ben Kloester


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


--001a1148fdc2e85f5d055b3b91bf--