Is there some kind of draft to support a chain split+merge, like Version Control systems do?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.