<div dir="ltr"><div class="gmail_extra">As I feared, request on feedback for this specific BIP has devolved into a general debate about the merits of soft-forks versus hard-forks (versus semi-hard Kosher Free Range forks...).</div><div class="gmail_extra"><br></div><div class="gmail_extra">I&#39;ve replied to several people privately off-list to not waste people&#39;s time rehashing arguments that have been argued to death in the past.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I do want to briefly address all of the concerns that stem from &quot;what if a significant fraction of hashpower (e.g. 25%) stick with the 1mb branch of the chain.&quot;</div><div class="gmail_extra"><br></div><div class="gmail_extra">Proof of work cannot be spoofed. If there is very little (a few percent) of hashpower mining a minority chain, confirmations on that chain take orders of magnitude longer.  I wrote about why the incentives are extremely strong for only the stronger branch to survive here:</div><div class="gmail_extra"> <a href="http://gavinandresen.ninja/minority-branches">http://gavinandresen.ninja/minority-branches</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">... the debate about whether or not that is correct doesn&#39;t belong here in bitcoin-dev, in my humble opinion.</div><div class="gmail_extra"><br></div><div class="gmail_extra">All of the security concerns I have seen flow from an assumption that significant hashpower continues on the weaker branch. The BIP that is under discussion assumes that analysis is correct. I have not seen any evidence that it is not correct; all experience with previous forks (of both Bitcoin and altcoins) is that the stronger branch survives and the weaker branch very quickly dies.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div><br></div><div>As for the argument that creating and testing a patch for Core would take longer than 28 days:</div><div><br></div><div>The glib answer is &quot;people should just run Classic, then.&quot;</div><div><br></div><div>A less glib answer is it would be trivial to create a patch for Core that accepted a more proof-of-work chain with larger blocks, but refused to mine larger blocks.</div><div><br></div><div>That would be a trivial patch that would require very little testing (extensive testing of 8 and 20mb blocks has already been done), and perhaps would be the best compromise until we can agree on a permanent solution that eliminates the arbitrary, contentious limits.</div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>--<br>Gavin Andresen<br></div><div><br></div></div></div></div></div>
</div></div>