But who would merge-mine a chain where you get zero revenue from merge-mining?
There is never "zero revenue", because you are still paid. Every transaction has a fee. Mainchain transaction, LN transaction, or even sidechain transaction. Those transactions for peg-ins, transfers on the sidechain, and peg-outs will have a fee. Of course, it could be zero if you want, but nothing stops those miners for confirming those things.
The fee of the sidechain miners, is simply the fee that comes from batching: if someone will do some transactions, that will pay 0.01 BTC, then the fee for the user will be the same. But it will be possible to batch things, and collect fees from batching transactions, in a similar way how LN nodes collect their routing fees.
Also, if you read how Drivechain is implemented, then you note there are two kinds of fees: L1 fees, and L2 fees. Here, it will be similar.
but would that be enough to prevent 51% attacks?
It depends on the computing power. If you will have a bunch of CPU miners, sitting on a particular sidechain, then of course they would collect single satoshis, and of course the Proof of Work coverage will be quite low. Which means, if you have Lightning Network, then you have penalty transactions, and absolutely none Proof of Work protection (lightning transactions are simply zero-confirmation transactions, as long as they are not broadcasted). Here, you will have the same level of protection as in the Lightning Network, but also with Proof of Work coverage, and a public watchtower, where every honest node will send penalty transactions when needed.
I don't believe these fees can be high
It depends on the traffic, and on the Proof of Work coverage. I expect it could be on a similar level, like in LN, or maybe somewhat higher, because in sidechains, you can send your coins to anyone, without creating additional on-chain transaction, if your coins are already in the sidechain.
How do you achieve this? How can this script look like?
The mainchain should be blind, when it comes to everything that is happening on the sidechain. If you want to just test things, you should be able to do a self-transfer, or even no-transfer-at-all, and check, how it works. For that reason, every Script should be allowed, no matter what it contains, and then it is up to the users to define the conditions.
Don't we need covenants or some other opcodes Script does currently not provide, to really create a blocking/unblocking mechanism on Bitcoin which ensures that we can't do the above mentioned attack?
If they are needed, they could be implemented on a sidechain, because that part will not require any consensus changes, and will work as well.
How exactly can homomorphic encryption help here?
Because then, the sidechain can act like a global watchtower. If you have LN closing channel transactions, or penalty transactions, you just keep them on your node, but the drawback is, that your node should then be online, 24/7. However, if you encrypt things first, and then post them in encrypted form to some P2P network, then honest nodes could observe the mainchain 24/7, and if they notice a transaction, that will match, they will decrypt the penalty transaction you posted before, and act as a global watchtower. Also, in the same way, they will block any double-spending attempt on that sidechain.
Can you create a sort of "covenant" with it?
You can perform any computation you want, according to the ways it was "encrypted". Which means, if for example some public key is exposed, then you can create a multisig out of it. Or if some Schnorr signature is exposed, then you can bring the missing part, and join those signatures. Or you can do other tricks, for example prove that you solved puzzle number 66, without revealing the public key, and letting everyone break it before reaching the first confirmation. And yes, I guess making covenants is also possible, but I didn't explore the details yet.
How do you exactly block the coins on Bitcoin, before you "move to the sidechain", to be later able to release them exactly to the person/address who pegs-out BTC on the sidechain?
You don't block the coins. You inform people, that you own the coins, and then they can decide, if they want to join your Script, and if the proof you provided is sufficient. For example, if you have already existing Lightning Network channel, then you should not close it, and then open "sidechain peg-in". You should simply show people: "here are my coins, here is my signature, here is my unlocking Script, can you accept that?". And guess what: some scripts are already acceptable. And also, some scripts are acceptable, if you want to just test things.
Also, sometimes you don't need to move coins. Sometimes you want to only test something. Then, what do you need? Not that much: you need to inform people, that you own some coins (even on P2PK), then you can do your testing, and then you can move your coins back on-chain, for example because you want to send them somewhere. And then, everything will be batched to a single on-chain transaction, and the destination would be the outcome of batching everything you did in the middle. Isn't it beautiful? Testing without producing new coins, out of thin air? Posting for example Ordinals on the sidechain, and sharing it with the network, without bloating the mainnet? Creating your own assets or tokens, and preserving the ownership, without pushing all of that to the mainnet? I think it is worth at least trying, and I think allowing any Script is needed, because those use cases, where coins are negligible, should be cheap on sidechain, and expensive on mainchain.
I believe you and @vjudeu are talking about a similar sidechain model, but I can't find any information about it. Are there any whitepapers/links?
Not yet, but as you noticed, we talk to each other, and we created some small, private test network, and some of our posts just reflect the results of our testing. Of course, things are not yet ready to be shared publicly, but I think they are good enough to be discussed. And also, we need some feedback to fix some bugs, before we release all of that publicly. We don't want to flood the mainnet, or to harm it in any other way, and we know, that if we release something, then there is no "undo" button (as you can read in my signature).
Is there any real-world example for that concept?
Not yet, but testing sounds promising. Of course, NameCoin used Merged Mining, but there are some flaws, and our implementation is different. But still, there are some bugs to be fixed, and some extreme cases are hard to fix, so we will see, what to include in the first version.
My impression is that this isn't an easy task and may be even be impossible if both metachain and pegged chain (Bitcoin) are decentralized, because it could allow attacks on several of the weaker chains happen at once to harm the metachain or steal coins.
You won't attack metachain that easily, because it would blindly follow the heaviest chain of Proof of Work. Which means, you can produce invalid headers, and the sidechain will trace that, and react accordingly. Because if you look at BCH or other altcoins, then you can notice, that one of their mistakes, was related to replay protection, and difficulty adjustments.
In case of 51% attack (or even 99% attack), the current network simply ignores invalid blocks, even if their Proof of Work is enormous. And I think it is a mistake. It should be noted, that "hey, the attack is ongoing", and the network should react accordingly. Which means, that invalid headers should still be notarized, and the value of the honest network should be relative to the total Proof of Work, produced by honest nodes and attackers combined. Because if it is not, then it is like pretending that there is no attack, which is a bad approach.
