One way mining centralization occurs is due to bandwidth - those that get the newest block first have the best chance of making the next block, and those that get the newest block last have the best chance of making an orphan block. Thus, orphanization is the true culprit in bandwidth-induced centralization. So can we do away with orphanization? This fusion block idea presents a solution, and this solution can be worked in with lightblocks (described in the epitope protocol thread) for a double-whammy. This is a cross post from the bitcointalk technical improvement thread.

Is there any work in this space regarding what could be called sister blocks, or fusion blocks?

Basically, the way I understand it (and granted, my assumptions could be flawed) is that there exists a set of transactions in the mempool. We'll just use 5 here

Trans1 Trans2 Trans3 Trans4 Trans5

If miner A decides to put 1,2,3 in his block (block A), and miner B decides to put 3,4,5 in his block (block B), they are both technically valid blocks (they both have the previous block's hash and contain valid transactions from the mempool). However, due to the nature of satoshi consensus, if block A makes it into the chain first, block B becomes orphan - even though it is entirely valid.

It's even easier to understand the inefficiency of satoshi consensus if block A has 1,2,3 and block B has 4,5. In this case, there's really no reason both blocks aren't valid.

Essentially what I'm thinking is that you can imagine these two blocks existing as blebs on the chain.

                    .
._._._._._._._._._./
                   \,

each dot is a block, and the comma indicates a sister block in current protocol, this would happen

                    ._._._
._._._._._._._._._./
                   \,_,

And eventually one chain would grow longer (which is ultimately influenced by bandwidth) and the entire sister chain would be dropped, and if your node was on that chain you'd experience a reorg (right?).

why couldn't something be implemented where the above fork turns into a bleb

                   .
._._._._._._._._._./\.
                   \,/

which is eventually resolved to a fusion block

._._._._._._._._._._!_._

where the ! indicates a fusion block. When encountering a potential orphan scenario (daemon receives two blocks in close proximity, or already has added a block but then receives a similar block for the same block height) instead of the daemon rejecting one as orphan, it scans the sister block as a candidate for fusion. There would be some parameters (X% of transactions overlap, only concurrent block height are candidates (this is effectively the time window)). As part of this, the system would somehow need to be able to send transaction fees to different blockfinders, but again this seems tractable (though I await to be schooled as to why its not possible). In addition, the block reward itself would need to be apportioned.

Or is this what a reorg does? The way I understand reorgs, this is different than a reorg.

Though upon creation of the fusion block a reorganization would have to occur. So at the cost of overall bandwidth we provide a countermeasure for the loss of economic incentive for large blocks.

And one problem to address is that you would need a new block header for the fusion block, but this could really just be the hash of the two sister blocks. Both sisters are valid, therefore the hash of those valid blocks is valid.