> On Jul 22, 2015, at 3:01 PM, Mike Hearn <he...@vinumeris.com> wrote: > > Until we’re able to merge blockchain forks like we’re able to merge git repo > forks, the safest option is no fork. > > 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". > > 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. >
Mike, you might be surprized to learn that there are other hard fork proposals out there besides increasing block size.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
