<oembed><type>rich</type><version>1.0</version><author_name>npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd</author_name><author_url>https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-07-22&#xA;📝 Original message:&gt;&#xA;&gt; Until we’re able to merge blockchain forks like we’re able to merge git&#xA;&gt; repo forks, the safest option is no fork.&#xA;&gt;&#xA;&#xA;Block chain forks merge in the same way as git forks all the time, that&#39;s&#xA;how the reorg algorithm works. Transactions that didn&#39;t make it into the&#xA;post-reorg chain go back into the mempool and miners attempt to reinclude&#xA;them: this is the &#34;merge&#34; process. If they now conflict with other&#xA;transactions they are dropped and this is &#34;resolving merge conflicts&#34;.&#xA;&#xA;However you have to want to merge with the new chain. If your software is&#xA;programmed not to do that out of some bizarre belief that throttling your&#xA;own user base is a good idea, then of course, no merge happens. Once you&#xA;stop telling your computer to do that, you can then merge (reorg) back onto&#xA;the main chain again.&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/88e446a6/attachment.html&gt;</html></oembed>