Thanks for the comment! It makes sense, but also makes me wonder about the value of "transfer a bitcoin to the sidechain and back to the btc blockchain" - what would be the real world example when moving is superior to cross-coin trading? Not to be critical, just a genuine attempt to understand. In other words, what can't be done in a world where there are only merge mined coins (chains)  and no pegged coins? I couldn't think of anything...

Yes, that is true. However, that does not create any additional risks compared to completely separate mining (if that is what you are getting at). Miners could simply switch and mine NameCoin if they liked. So, no downside. In fact there are upsides:

a. If significant number of bitcoin miners also merge mines namecoin that makes it difficult for an outsider or newcomer to assembly a critical mass for 51% attack.

b. Miners incentives - merged mining allows extra reward from all merge mined currencies included in the block. From miners perspective it would be the best if all compatible chains were merge mined.


Considering that the hash rate is the ultimate determinant of coin robustness and that the hash rate is a function of mining reward, the security of given coin is directly proportionate to it's cost. Cheaper coins are more vulnerable. So, in a long run NameCoin has no choice but to deflate in order to stay secure and prevent 51% attacks.

I'm sorry if this is off-topic (I hope it is not)... but I still can't get a clear understanding of what makes pegged side chains fundamentally better than merged mining? I see some benefits but not a single one that won't be attainable within merged mining concept:

a. Ease of implementation and spawning a new chain? Can be done with merged mining with some alterations to bitcoin scripting language (pegged chains require that also)

b. Robustness? Looks to be the same, more or less, between pegged and merge mined chains

c. Blockchain pollution? Merged mining takes just 40 bytes (slightly less) per block for arbitrary, unlimited number of merged chains.

d. Atomic conversion and swap? I'm not sure if the side chain needs to be pegged for that. Again, peg or not can be done with merge mined chains. No?

What's left then?

From what I understand, there is general aversion to OP_CAT due to inherent vulnerabilities that are hard to contain in the script interpreter (potential stack explosion). It may be safer and simpler to introduce an OP_FIND instead. OP_FINE would A better option may be to re-code your transaction with something like OP_FIND -1 if the substring is not found or the index of the beginning if it is. The return value will be numeric, i.e. CScriptNum type.

If OP_FIND was available and OP_HASH256 variant that would take two arguments rather than one, it would be possible to code p2sh transaction to validate headers of alternative chains. Here is an example for NameCoin. This is just an illustration of the concept. It is likely not to cover all possible malicious inputs.

Input:
<push merge mined header> <-- This is a header that does not satisfy BitCoin difficulty but is good enough for alt chain(s)
<push merkle hashN>,
<push merkle hashN-1>,
..
<push merkle hash2>,
<push merkle hash1>,
<push the merkle root of merge mined chain headers> <-- Obtained through getAuxWork from alt chains or through some other means.
<push the merge mined coinbase> 

Script:
OP_TUCK                          //// Save the merge mining coinbase for subsequent check for inclusion in the merge mined block
OP_FIND                          //// Check that the merkle root of merge mined chain headers is in the coinbase, i.e. that this is indeed a valid proof of work
-1
OP_EQUALVERIFY             //// Exit if the merkle root of side chains is not present in the merge mined coinbase
OP_HASH256_2               ////  Compute HASH256(<merge mined coinbase>, <merkle hash1>), i.e. move up one level in the merkle tree of transactions
OP_TUCK                        ////  Save the result to save it for computation of the next level if needed.
OP_EQUAL                      ////   If the result is equal to the next item then we've reached the top of the merkle tree and it is valid
OP_IF
OP_TRUE                        ///    Push TRUE and do nothing else - essentially finish the script with TRUE
OP_ELSE

OP_HASH256_2               ////  Compute HASH256(<merge mined coinbase>, <merkle hash1>), i.e. move up one level in the merkle tree of transactions
OP_TUCK                        ////  Save the result to save it for computation of the next level if needed.
OP_EQUAL
OP_IF
OP_TRUE
OP_ELSE

OP_HASH256_2               ////  Compute HASH256(<merge mined coinbase>, <merkle hash1>), i.e. move up one level in the merkle tree of transactions
OP_TUCK                        ////  Save the result to save it for computation of the next level if needed.
OP_EQUAL
OP_IF
OP_TRUE
OP_ELSE

...

...

OP_HASH256_2               ////  Compute HASH256(<merge mined coinbase>, <merkle hash1>), i.e. move up one level in the merkle tree of transactions
OP_TUCK                        ////  Save the result to save it for computation of the next level if needed.
OP_EQUAL
OP_IF
OP_TRUE
OP_ELSE

OP_ENDIF   ///
OP_ENDIF   ///
OP_ENDIF   /// Close all IF blocks
OP_ENDIF   ///
OP_FALSE   //// Merkle tree is invalid


Obviously this won't work if the merkle tree is deeper than the number of check blocks. However, that shouldn't be a concern as very deep trees can be accommodated withing the 520 byte script size limit.

Both, OP_FIND and OP_HASH256_2 produce fixed size input, which make them safe from the perspective of causing potential memory/stack explosion.