Hi ZmnSCPxj,
Basically, in case of a sidechain fork, the mainchain considers the
longest chain to be valid if it is longer by the SPV proof required
length. In the above, at mainchain block 10, the sidechain H is now 4
blocks (H,G,F,E) longer than the other sidechain fork that ended at d.
Mainchain
nodes can validate this rule because the sidechain headers are embedded
in the mainchain block's coinbase. Thus, mainchain fullnodes can
validate this part of the sidechain rule of "longest work chain".
What happens in the case that the provided merkle tree hash has a invalid transaction in it? Wouldn't this mean that the mainchain nodes would think the longest work chain is the valid chain, and it would kill off any consensus valid chain that sidechain miners are trying to construct? It seems that a malicious miner could extend the chain to whatever the SPV proof block height is and make it impossible for the chain to reorg after that. I guess if that is a sufficiently long block waiting period it may not be a realistic concern, but something to think about any way.
Just a side note -- I think it should be highly recommended that the coinbase maturity period on the sidechain to be longer than 288 (or whatever we decide on the parameter). This incentivizes the s:miners to work together to extend the chain by working with other s:miners (otherwise they won't be able to claim their bribes). If they do not work together they will not be able to spend their s:coinbase_tx outputs until they extend their own sidechain by 288 blocks meaning they need to tie up a large amount of capital to go rogue on their fork.
Another interesting thing might be to use the
OP_WITHDRAWPROOFVERIFY op code used in the elements project. Since the cannonical merkle root hashes are included in the mainchain, we can provide a merkle proof to the bitcoin blockchain to initiate a withdrawl from the sidechain. I wrote up a blog post on how OP_WPV works
here. This allows us to prove that a transaction occurred on the sidechain to lock up those funds.