[bitcoin-dev] New difficulty algorithm needed for SegWit2x fork? (reformatted text)

Ben Kloester benkloester at gmail.com
Tue Oct 10 02:57:23 UTC 2017

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 at 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 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 largest 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’m 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 suggest
> reframing as a hardfork wishlist research problem for the next properly
> planned hard fork, if one occurs. You might also find the hardfork research
> 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 at 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, leaving
> 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.
> === Begin difficulty algorithm ===
> # 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 = sum(last N Ds) * T / [max(last N TSs) - min(last N TSs];
> # ST= Solvetime, TS = timestamp
> # set constants until next hard fork:
> T=600; # coin's TargetSolvetime
> N=30; # Averaging window. Smoother than N=15, faster response than N=60.
> X=5;
> limit = X^(2/N); # limit rise and fall in case of timestamp manipulation
> adjust = 1/(1+0.67/N);  # keeps avg solvetime on track
> # begin difficulty algorithm
> avg_ST=0; avg_D=0;
> for ( i=height;  i > height-N;  i--) {  # go through N most recent blocks
> avg_ST += (TS[i] - TS[i-1]) / N;
> avg_D += D[i]/N;
> }
> avg_ST = T*limit if avg_ST > T*limit;
> avg_ST = T/limit if avg_ST < T/limit;
> next_D = 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 = coins per block
> next_reward = BaseReward * avg_ST / T;
> ======= end algo ====
> 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171010/a592d3b6/attachment-0001.html>

More information about the bitcoin-dev mailing list