<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jul 22, 2015, at 3:01 PM, Mike Hearn &lt;<a href="mailto:hearn@vinumeris.com" class="">hearn@vinumeris.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class="">Until we’re able to merge blockchain forks like we’re able to merge git repo forks, the safest option is no fork.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Block chain forks merge in the same way as git forks all the time, that's how the reorg algorithm works. Transactions that didn't make it into the post-reorg chain go back into the mempool and miners attempt to reinclude them: this is the "merge" process. If they now conflict with other transactions they are dropped and this is "resolving merge conflicts".</div><div class=""><br class=""></div><div class="">However you have to want to merge with the new chain. If your software is programmed not to do that out of some bizarre belief that throttling your own user base is a good idea, then of course, no merge happens. Once you stop telling your computer to do that, you can then merge (reorg) back onto the main chain again.</div><div class=""><br class=""></div></div></div></div>
</div></blockquote></div><br class=""><div class="">Mike, you might be surprized to learn that there are other hard fork proposals out there besides increasing block size.<br class=""><div><blockquote type="cite" class=""></blockquote></div></div><div class=""><br class=""></div></body></html>