Quote from: domob on August 02, 2019, 05:13:49 AM

One thing I wonder about is this: With Armadillo, you need to place the commit-to-parents vector directly in the Bitcoin coinbase input, right? That means that unlike classical merge mining where you have a Merkle tree of mined chains, you can only merge-mine so many (a rather small number) of coins with Armadillo.

About "classical" merge mining: namecoin defined a scheme which AFAIK did not work well for more than one merge-mined chain. No other project simultaneously adhered to this scheme.

"specs" here: https://en.bitcoin.it/wiki/Merged_mining_specification

Because of these flaws, RSK used a single independent tag for its sidechain, not part of a tree of hashes.
One of the reasons was the early idea of putting more info in the tag to be seen by the whole network. If it was buried in a tree, the it was obscured.

Therefore each merge-mined sidechain would need to consume 12 additional bytes (or more) to save its own armadillo tag.

We could define a new standard for merge-mining that enables publishing these additional bytes for each chain Armadillo needs.
Given a good standard and enough community feedback, I think RSK community would hardfork to adhere to it.

Quote from: domob on August 02, 2019, 05:13:49 AM

I also think that miners were concerned about coinbase size in the past. Do you think that could be a problem?

I don't think this is a problem now. Currently most coinbase transactions have several outputs containing OP_RETURN data that serves different purposes. The amount of space consumed is negligible. Anyway, miners are paying for it.