<div dir="ltr">Is there a contingency plan in the case that the incumbent chain following the Bitcoin Core consensus rules comes under 51% attack? <div><br></div><div>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?<br><br>I'm aware of Luke's work on <a href="https://github.com/BitcoinHardfork" class="gmail-url gmail-fn" rel="author" style="background-color:transparent;font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol";box-sizing:border-box;color:rgb(3,102,214);outline-width:0px">BitcoinHardfork</a>, 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?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><p><b>Ben Kloester</b><br><span style="font-size:10.0pt;color:#595959"></span></p></div></div>
<br><div class="gmail_quote">On 10 October 2017 at 13:19, Mark Friedenbach via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div 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/" target="_blank">https://<wbr>bitcoinhardforkresearch.<wbr>github.io/</a></div><div><div class="h5"><div><div><br>On Oct 9, 2017, at 3:57 PM, Scott Roberts via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>> 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. 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. 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. 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. 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" target="_blank">http://zawy1.blogspot.com/<wbr>2017/07/best-difficulty-<wbr>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" target="_blank">https://github.com/seredat/<wbr>karbowanec/commit/<wbr>231db5270acb2e673a641a1800be91<wbr>0ce345668a</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); # 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; i > height-N; i--) { # 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 > T*limit; </span><br><span>avg_ST = T/limit if avg_ST < 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>______________________________<wbr>_________________</span><br><span>bitcoin-dev mailing list</span><br><span><a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a></span><br><span><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a></span><br></div></blockquote></div></div></div></div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>