user196: 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?

user85: 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.

user323: 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.

196: <p><a href="https://bitcoin.stackexchange.com/questions/1738/what-would-happen-if-a-portion-of-the-bitcoin-network-was-separated-from-the-res">Currently</a>, 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.</p>

<p>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.</p>

<p>Does such a draft exist?</p>
 85: <p>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 <em>neither</em> chain is valid and everybody loses? That just doesn't make any sense.</p>

<p>There are two cases:</p>

<p>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.</p>

<p>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.</p>

<p>I don't see how you can do better.</p>
 323: <p>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 <a href="https://en.bitcoin.it/wiki/Block_hashing_algorithm" rel="nofollow">the block hashing algorithm</a>. Generally, if you wanted to merge two blocks together, you'd have to solve them all over again.</p>

<p>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.</p>
