<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>

CC BY-SA 3.0
2012-01-10T08:28:41.590Z
I'll take it as a "No, nobody bothered to write such a draft, and the problems it would encounter currently are [body]"
o0'.
CC BY-SA 3.0
2012-01-10T09:10:08.140Z
@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
CC BY-SA 3.0
2012-08-05T11:06:01.463Z
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'.
CC BY-SA 3.0
2012-08-05T20:51:57.000Z
@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
CC BY-SA 3.0
2011-12-10T14:28:23.270Z
2011-12-10T14:28:23.270Z
ThePiachu
<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>

CC BY-SA 3.0
2011-12-12T08:21:47.283Z
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'.
CC BY-SA 3.0
2011-12-12T19:30:04.817Z
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.
David Schwartz
CC BY-SA 3.0
2012-01-04T22:05:41.720Z
My impression is that Lohoris is asking why we can't make both chains valid.
Sophie Swett
CC BY-SA 3.0
2012-01-04T22:15:30.490Z
@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.
David Schwartz
CC BY-SA 3.0
2011-12-10T23:49:19.310Z
2011-12-10T23:49:19.310Z
David Schwartz
<p>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.</p>

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

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

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

<p>I'd be curious to hear people's thoughts.</p>

CC BY-SA 3.0
2013-07-03T16:09:51.427Z
2013-07-03T16:09:51.427Z
Jack O'Connor
<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>

<network>
Is there some kind of draft to support a chain split+merge, like Version Control systems do?
o0'.
# Is there some kind of draft to support a chain split+merge, like Version Control systems do?

(Asked by: username_0 on 2011-12-10)

[Currently](https://bitcoin.stackexchange.com/questions/1738/what-would-happen-if-a-portion-of-the-bitcoin-network-was-separated-from-the-res), 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?

**Tags:** network


---

## 3 answers

### Answer by username_1 on 2011-12-10. Score: 3 | Accepted answer

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](https://en.bitcoin.it/wiki/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.

> **Comments:**
> **username_0**: I'll take it as a "No, nobody bothered to write such a draft, and the problems it would encounter currently are [body]"  
> **username_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.  
> **username_0**: 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.  
> **username_1**: @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.  

---

### Answer by username_2 on 2011-12-10. Score: 1

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.

> **Comments:**
> **username_0**: 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**!  
> **username_2**: 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.  
> **username_3**: My impression is that Lohoris is asking why we can't make both chains valid.  
> **username_2**: @TannerL.username_3 In case 1, we can and we do. In case 2, we can't because we have conflicts that have to be resolved.  

---

### Answer by username_4 on 2013-07-03. Score: 0

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.


---

