<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">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.<div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div><a href="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="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><span>Sorry, my previous email did not have the plain text I intended.</span><br><span></span><br><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 fork due to miners seeking maximum profit without due regard to </span><br><span>security, users, and nodes, the "better" coin could end up being the </span><br><span>minority chain. If 90% of hashrate is really going to at least initially go </span><br><span>towards using SegWit2x, BTC would face 10x delays in confirmations </span><br><span>until the next difficulty adjustment, negatively affecting its price relative </span><br><span>to BTC1, causing further delays from even more miner abandonment </span><br><span>(until 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 miners. If the </span><br><span>prices are the same and stable, all seems well 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 situation 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. &nbsp;They will not issue coins too fast </span><br><span>like BCH because that is a side effect of the asymmetry 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 implement a new difficulty algorithm that uses a simple rolling </span><br><span>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 suddenly leaving, leaving </span><br><span>constant miners stuck with a high difficulty 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>motivate 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 difficulty algorithm I'm aware of. &nbsp;This is the result of a lot of work the </span><br><span>past year. </span><br><span></span><br><span>=== Begin difficulty algorithm === </span><br><span># Zawy v6 difficulty algorithm (modified for bitcoin) </span><br><span># Unmodified Zawy v6 for alt coins: </span><br><span># <a href="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 attempts at something better: </span><br><span># <a href="https://github.com/seredat/karbowanec/commit/231db5270acb2e673a641a1800be910ce345668a">https://github.com/seredat/karbowanec/commit/231db5270acb2e673a641a1800be910ce345668a</a> </span><br><span># </span><br><span># Keep negative solvetimes to correct bad timestamps. </span><br><span># Do not be tempted to use: </span><br><span># next_D = sum(last N Ds) * T / [max(last N TSs) - min(last N TSs]; </span><br><span># ST= Solvetime, TS = timestamp </span><br><span></span><br><span># set constants until next hard fork: </span><br><span></span><br><span>T=600; # coin's TargetSolvetime </span><br><span>N=30; # Averaging window. Smoother than N=15, faster response than N=60. </span><br><span>X=5; </span><br><span>limit = X^(2/N); # limit rise and fall in case of timestamp manipulation </span><br><span>adjust = 1/(1+0.67/N); &nbsp;# keeps avg solvetime on track </span><br><span></span><br><span># begin difficulty algorithm </span><br><span></span><br><span>avg_ST=0; avg_D=0; </span><br><span>for ( i=height; &nbsp;i &gt; height-N; &nbsp;i--) { &nbsp;# go through N most recent blocks </span><br><span>avg_ST += (TS[i] - TS[i-1]) / N; </span><br><span>avg_D += D[i]/N; </span><br><span>} </span><br><span>avg_ST = T*limit if avg_ST &gt; T*limit; </span><br><span>avg_ST = T/limit if avg_ST &lt; T/limit; </span><br><span></span><br><span>next_D = avg_D * T / avg_ST * adjust; </span><br><span></span><br><span># Tim Olsen suggested changing reward to protect against hash attacks. </span><br><span># Karbowanek coin suggested something similar. </span><br><span># I could not find 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 = coins per block </span><br><span></span><br><span>next_reward = BaseReward * avg_ST / T; </span><br><span></span><br><span>======= end algo ==== </span><br><span></span><br><span>Due to the limit and keeping negative solvetimes in a true average, </span><br><span>timestamp 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 of past 11 blocks (MPT) </span><br><span>as the most recent timestamp, offsetting the timestamps from their </span><br><span>corresponding difficulties 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>_______________________________________________</span><br><span>bitcoin-dev mailing list</span><br><span><a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a></span><br><span><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></div></body></html>