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

This is exactly the problem, and one which exists in a different form in any sidechain proposal. In drivechain, malicious mainchain miners may arbitrarily downvote any side-to-main peg even if the side-to-main peg is valid on the sidechain, with mainchain fullnodes unable to gainsay them. In original sidechain's SPV proofs, malicious mainchain miners may provide an invalid SPV proof and then censor any reorg proof against that SPV proof. In both of those cases, trust in the sidechain and the value of sidecoin necessarily takes a hit.

Of course, in both of those two cases, the hit is "temporary" and the sidechain could theoretically recover. In sidechain-headers-on-mainchain, the hit would permanently kill the sidechain.

The fact that sidechains are merge mined and cannot be mined off-mainchain makes sidechains entirely dependent on mainchain miner's support. I agree with Sztorc that sidechains must be merge mined entirely, otherwise the sidechain will effectively reduce mainchain security by pulling away potential miners from mainchain.

OP_BRIBEVERIFY, which is intended to allow sidechain miners/protectors to be a separate datacenter from miners, allows anyone with either enough hashpower or enough maincoin to disrupt a sidechain by spamming its slot with random hash values. With enough disruption, the sidechain may become unusable in drivechains, but may indeed be killed that way in sidechain-headers-on-mainchain.

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

Even without sidechain headers on mainchain, one might consider plain blind merged mining to have put even the "previous block hash" in the sidechain block coinbase transaction. Thus, one might consider that in blind merged mining, h' commitments are really merkle tree roots, and the previous block hash is encoded in a special sidechain transaction on one side of the merkle tree, while sidechain block transactions are encoded in the other side of the merkle tree root. This allows OP_WITHDRAWPROOFVERIFY to be used on blind merged mining, but without sidechain headers on mainchain, a compact SPV proof somehow must still be provided, or we are forced to use drivechain miner voting.