You just explained exactly a Block-Tree which I developed back in 2012, which the original eMunie project used.
It doesn't provide an sufficient scalability improvement over a blockchain and was subsequently dumped in 2014.
The overhead required to maintain the global state so that everyone knows there are n number of child blocks to a parent block at scale becomes quite extreme. This kills performance past that point.
If you don't keep all nodes consistent to the very latest information (CAP theorem gets in the way a bit here) then two problems arise:
1) Nodes may also not know what the main branch is because they don't have all the state information and reference parents in weaker branches by mistake. If that happens, your main branch becomes weaker, because hash power is inadvertently distributed across many branches and lots of miners don't get rewarded.
2) New blocks that are children of old parents will be created and won't be included in the uncle list of the next real block of that parent due to it being created already.
Your diagram that you put together shows exactly this (by coincedence I assume):
Block(X) is not reference by other blocks, maybe it came in late. There is also no guarantee if or when it will be referenced by any future blocks either and therefore poses a double spend security risk.
You also have the problem that a dishonest miner can throw in a block on a recent parent with more POW than the other blocks referencing that parent and those which come after it. That then becomes the branch with the most work. Therefore, any inputs in a block higher up, can be represented in a block as a child of that new block. If the input that is seen first is considered the legit spend, and those after it are considered double spends, well.....double spends can happen.
It doesn't provide an sufficient scalability improvement over a blockchain and was subsequently dumped in 2014.
The overhead required to maintain the global state so that everyone knows there are n number of child blocks to a parent block at scale becomes quite extreme. This kills performance past that point.
If you don't keep all nodes consistent to the very latest information (CAP theorem gets in the way a bit here) then two problems arise:
1) Nodes may also not know what the main branch is because they don't have all the state information and reference parents in weaker branches by mistake. If that happens, your main branch becomes weaker, because hash power is inadvertently distributed across many branches and lots of miners don't get rewarded.
2) New blocks that are children of old parents will be created and won't be included in the uncle list of the next real block of that parent due to it being created already.
Your diagram that you put together shows exactly this (by coincedence I assume):
Block(X) is not reference by other blocks, maybe it came in late. There is also no guarantee if or when it will be referenced by any future blocks either and therefore poses a double spend security risk.
You also have the problem that a dishonest miner can throw in a block on a recent parent with more POW than the other blocks referencing that parent and those which come after it. That then becomes the branch with the most work. Therefore, any inputs in a block higher up, can be represented in a block as a child of that new block. If the input that is seen first is considered the legit spend, and those after it are considered double spends, well.....double spends can happen.