Forking of a blockchain with the goal of merging them

[Souri]

I hope this is the right subforum for this question, if not feel free to move it, afterall it is the first time I am dipping my toes in the real bitcointalks and leaving the local german subforum.

At a talk I was on the other day, a question came up that I couldn't let go till now and I thought to myself I will adress this question to you, as you have far more technical understanding than me.

It is quite clear that you can fork a blockchain in the flavours "Soft" and "Hard" and with a hard fork the blockchains are incompatible with each other due to changed rules from the moment of the fork although they share the same history. I also know that you can use so-called sidechains to conduct transactions according to the standard of the main blockchain and then integrate them back again.

Now the question was, could you fork (especially a PoW blockchain) a blockchain and have it run parallel for a while and then reunite them? When a block is found at the same time in the Bitcoin PoW concept afaik the chain that gathers new blocks faster becomes dominant and the sidechain is abandoned by the miners and therefore dies, so it is a hash or die kind of thing. But would there be a (at least theoretical) possibility to merge two chains of common origin in which both blocks were mined and thus logically respect what was written in the blocks of this blockchain.


I know that this is a completely theoretical consideration and I probably don't have enough technical competence to fully penetrate it, but I find the idea somehow interesting. Maybe one of you can say something more qualified than me about what brings me closer to me gaining any knowledge?

[1714838211]

1714838211

[1714838211]

1714838211

[RGBKey]

I'd say a coin would probably have to be built from the ground up to support something like this. Bitcoin would never be able to accomplish this for a few reasons.

Firstly, the two chains would have two different sets of transactions after they split, where people could send the same input once on each chain, to possibly different addresses. When the chains merged back together, there would be no way to say which version was valid, unless the transactions on one chain were going to be completely discarded, which would sort of ruin the idea of merging them. Plus any transaction that depended on that output, and any other ones that depended on the next and so on would also be invalid, leaving a vast majority of transactions in conflict with the other version of the chain.

Secondly, they would each have different versions of the same block at the same height. Software would have to be re-written from the ground up to support that, and that's never going to happen.

Basically there's way way way too many obstacles in the way of some sort of chain merge, many on a very low level. Such a thing would never be possible for Bitcoin, and even if you could build some coin that would have a structure supporting something like that, I'm not sure why you would want to as I cannot see any benefits from it.

[Xynerise]

Now the question was, could you fork (especially a PoW blockchain) a blockchain and have it run parallel for a while and then reunite them?

What you're referring to is a blockchain reorganisation.
There can only be one chain and one chain will be orphaned with its blocks so there will be one transaction history.
A reorg can only happen with compatible blockchains following the same consensus rules (eg when 2 miners find the solution to the same block, one of the blocks is eventually invalidated to favor the one with the highest difficulty sum/POW)
For example, BCash won't reorg to Bitcoin even though the bitcoin core has more proof of work because they aren't compatible/follow different consensus rules: Bcash's genesis block, 478559, has to be greater than 1MB and bitcoin  can't fulfill that rule so to BCash nodes, the Bitcoin chain is invalid.

[Kogs]

I cannot think of any way how this would be possible.

A reorg as Xynerise already explained can only invalidade (orphan) the shorter chain, but this would not be a merge.
A reorg in this case would be a disaster. The losing chain would throw back all transactions to the mempool.
This would first of all spam the mempool (depending of how many transactions happened parallel in the forked chain) and I guess it would invalidate most transactions which references to any double spend coins.

The main problem here are the double spends.

When you spend some coins on fork 1 and on fork 2, which transaction after the merge would be valid?
It cannot be both, it would brake the consensus rule of double spending. So it only can be one of them.

And if it can only be one of them someone need to chose which one.
And if the decision was made which one is valid, that mean that ALL transactions from this side of the fork need to be valid and ALL transactions from the other side of the fork need to be invalid. And now we are back at the reorg.

You cannot chose some transactions from fork 1 and some from fork 2.

[Xynerise]

And if it can only be one of them someone need to chose which one.

For bitcoin and most POW coins, the winning chain is the one with the most cumulative proof of work done.
So the chain that will be orphaned will be the one with  less proof of work done.

And if the decision was made which one is valid, that mean that ALL transactions from this side of the fork need to be valid and ALL transactions from the other side of the fork need to be invalid. And now we are back at the reorg.

You cannot chose some transactions from fork 1 and some from fork 2.

The blockchain doesn't usually split for long enough before a reorg, unless there's a serious problem with node clients or internet partition.
Blockchain.info's Orphaned Blocks page shows that reorgs don't usually exceed 2 blocks
Till date, I think the 2010 Overflow bug is the longest reorg. And that was because of a bug in the node client.