...
I see the need for merge-mining on a sidechain as only necessary to interact with and support it's backing store (Bitcoin.) That is, what I would call their 'backing store layer'.
The interaction relies on PoW, and therefore the PoW controls the BTC suspended in the Bitcoin blockchain for the Sidechain. This means a >50% attack can steal all of the BTC that backs a two-way convertible sidechain.
Again, I recommend you read the whitepaper published by Blockstream on sidechains. There are several security vulnerabilities that pegged sidechains with two-way convertibility will have.
Initially, at least, I'll only use a sidechain which can recognize an attack and freeze peg operations until the attacker gets tired of wasting his effort and goes away. If it even takes that to protect the sub-system. In the mean time I'll expect many designs to be able to operate just fine but just cannot inflate or deflate while an attack is underway.
In my conception of the world one of the marvelous things about sidechains is that they are much more free to adapt to various kinds of threats (and service more types of needs.) Indeed, that is one of the ways that sidechains support Bitcoin...by creating an endless whack-a-mole for entities trying to attack crypto-currencies more generally. The only totally critical thing is that native Bitcoin itself remains solid and well defended.
You also clearly didn't read my statement on where I do and do not need 'military grade' security. I keep some excess fiat in PayPal, but not my lifes' savings. If they fold and/or steal my money I'll be pissed and I'll try to get it back, but it won't hurt me much because I balance my risk. Indeed, I do the same for fiat in banks. That will be very much the case for sidechains. I'll mainly choose to use sidechains based on my desire to support a particular effort which sponsors them. I'll not put much money into any particular sidechain for some time, if ever, so I simply don't need high level security. I'll use native Bitcoin for my deep storage of real value...unless the bloatchain guys win the war that is.
Even if most transactions occur on lower security sidechains, people will need the Bitcoin main chain to store and access their savings. Now unless you want 1 billion people to only access the main chain once per decade, the 1 MB block size limit needs to be lifted.
Right now it is WAY too early to be trying to force transactions off the main chain. Right now is early adoption phase, meaning Bitcoin needs to grow rapidly and gain users, not look to conduct experiments on block scarcity. 1 MB is way too low a figure to set the limit on how much the main chain will scale.
As I've said before, I'm open to a conversation about blocksize as long as there is a well defined problem and proposed solution regarding scaling. I've made no bones about the fact that I myself have serious concerns about 4-7 tps even when most native Bitcoin transactions are sidechains balancings and user 'safe deposit box' style transactions if/when crypto-currencies are more than a tiny tiny part of the world's financial activity.
None of you pro-fork people have given anything to hint at where you want to stop with your simplistic 'increase block size to scale' scheme, or where you want to draw the line with exclusions. All I hear is 'faith based' assertions that market forces will make everything work out. Start talking numbers and we'll start analyzing. In the mean time, we have one chance to stay within the constraints of what is achievable behind TOR and realistically likewise hardening methods. I'm not interested in throwing it away... especially when there is no need and a very promising solution is around the corner.