Currently, if I didn't misunderstand, in case of a network split when the two networks merged again only one of them would be "valid" and everything else would be discarded.

This seems overly simplistic and un-technologic for me: a smart system able to handle splits and merge like distributed version control systems do (like hg or git). Of course that wouldn't be easy to do properly, and it's totally understandable it hasn't been done yet, but I would be surprised if nobody even bothered to draft some kind of proposal about it.

Does such a draft exist?

3 Answers 3


There is one inherent problem with the solution you described in regards to Bitcoin: the block chain is created in a very specific way. Each block in the block chain links to one and only one previous block, and it is encoded in such a way that if you change the internal structure of the block, it is no longer valid. You should look into the block hashing algorithm. Generally, if you wanted to merge two blocks together, you'd have to solve them all over again.

This does not mean, however, that the transactions from the invalid branch are lost. Unless the coins were already spent in the valid branch, one can take those "lost" transactions and include them in the next block to be mined. This would mean that the transactions would end up having a couple less confirmations, but they would still go through.

  • I'll take it as a "No, nobody bothered to write such a draft, and the problems it would encounter currently are [body]"
    – o0'.
    Jan 10, 2012 at 8:28
  • 1
    @Lohoris A bit of a simplified summary. Probably many people have considered it, but nobody has worked out a working solution yet. Even the concept of Bitcoins as it is currently is so revolutionary that even cryptography proffesionals have problems understanding it straight away. Making something more complicated requires someone to solve even more complicated problems.
    – ThePiachu
    Jan 10, 2012 at 9:10
  • Technically it just dawned on me it's not impossible to import both chains into a new one, hash the new one considering both chains, mark them as branches splitted at block X and merged at block Y, and have the clients check the hashes accordingly.
    – o0'.
    Aug 5, 2012 at 11:06
  • @Lohoris It would probably be more complicated than just discarding one branch and recycling transactions from it into a new block. Handling splits and merges would require some code specifically for this issue, and it might never be used. This could create some new network vulnerability.
    – ThePiachu
    Aug 5, 2012 at 20:51

Your solution is worse than the problem it solves. It's bad enough that both chains can't be valid and there may be some losers. You want to change it so that neither chain is valid and everybody loses? That just doesn't make any sense.

There are two cases:

1) There are no double spending attacks. In this case, everybody wins (except people who mined blocks in the "losing" chain). Any transactions in the "losing" chain that are not in the "winning" chain are still valid. They will automatically be added to the "losing" chain by miners, since they want the transaction fees.

2) There are double spending attacks. In this case, you fundamentally need some way to resolve the conflicts. The method Bitcoin uses is that the winning chain's transactions stand. (This is important because it means the longer the chain, the higher the chance your transaction will stand -- this is the crux of Bitcoin's security model.) Anyone who loses out has the conflicting transaction and so can prove they were ripped off by the sender.

I don't see how you can do better.

  • Lol where did I say I wanted neither chain to be valid, wtf? I just asked if someone made a proposal to fix this problem, I didn't even propose anything!
    – o0'.
    Dec 12, 2011 at 8:21
  • You proposed a merge using an algorithm other than one of the chains being valid and the other not. Since they cannot both be valid, that only leaves neither being valid. That would mean ensuring your transaction was in the longest chain (the one currently treated as valid) would no longer suffice. Dec 12, 2011 at 19:30
  • My impression is that Lohoris is asking why we can't make both chains valid. Jan 4, 2012 at 22:05
  • @TannerL.Swett In case 1, we can and we do. In case 2, we can't because we have conflicts that have to be resolved. Jan 4, 2012 at 22:15

I don't think there's much of a benefit to merging split chains in the current implementation, since both sides of the split probably contain all the same transactions. Even if you were able to deduplicate transactions and resolve any double spends, you'd still have to store the extra copies forever in the blockchain. Where I think this gets more interesting is in a possible future where you don't expect all nodes to receive all transactions.

Maybe this could happen for performance reasons. The network could become so large that no one can handle the volume of transactions. Then we could partition the network into Blockchain USA and Blockchain Europe, or whatever. Transactions would be broadcast only to the partition they originate from, but the blocks themselves could be merged later into a single transaction history. I don't know how much savings we can really expect if we still have to transmit all blocks to all participants (since those blocks just contain the original transactions we decided were too much). But maybe they could compress better? And it might reduce the transaction volume that thin clients have to deal with?

Or maybe this could happen for distance reasons. If some people on Mars start using Bitcoin, they might be as much as 20 light minutes away. With that time lag, they could send transactions, but they'd never be able to mine blocks, and their confirmation delay would be ~45 minutes. But if we created Blockchain Mars, they could have quick confirmations for Mars->Mars transactions, and they could participate in mining with their blocks merged later into Blockchain Earth.

I suppose in such a setup you'd want the average-of-10-minutes-per-block difficulty adjustments to be done within each partition, so the difficulty of each network could end up being different. Not sure how you'd handle mining rewards in that case. But when a block merges multiple parents from different chains, you could count them all towards its difficulty for the purpose of determining the longest chain.

I'd be curious to hear people's thoughts.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.