Armadillo in RSK: placing merge-mining security on par with Bitcoin mining

[Sergio_Demian_Lerner]

Recently RSK (the first merge-mined Bitcoin sidechain) hard-forked to add a feature to increase the security of merge-mining. The new security protection, called Armadillo, is quite simple to understand.

The idea is to add to the RSK merge-mining tags additional information that enable the reconstruction of the RSK fork graph even if the actual RSK blocks are hidden from the RSK network.

Then, any node can monitor the Bitcoin blockchain and, in case of detecting a malicious hidden fork, emit alerts that flood the RSK network. These alerts are decentralized and Sybil-attack protected. Nodes can choose to enter a temporary "Safe Safe Mode" (to differentiate it from Bitcoin's old Safe Mode ). In this mode they do not confirm transactions, so high-stake economic nodes, such as Exchanges, won't accept deposits.

I wrote an article about how it works and the security it brings here:

https://bitslog.com/2019/08/01/armadillo-more-consensus-security-for-rsk/

Happy to receive feedback and hear other ideas.

[domob]

Thanks for that article, this is an interesting new spin on merge mining!  The difference between thermodynamic and economic security is something that comes up repeatedly in people's critic of merge mining (and in my case Namecoin).  Armadillo is an interesting idea to increase security on shorter time frames (i.e. preventing double-spending attacks against an exchange like you describe in the article).

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.  I also think that miners were concerned about coinbase size in the past.  Do you think that could be a problem?

[Sergio_Demian_Lerner]

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.

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.

[domob]

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

While this is not exactly on topic, I'm curious.  Why do you think that the Namecoin scheme does not work and that no other coins would adhere to that scheme?  I'm at least aware of three other chains (Namecoin, Huntercoin and Xaya) that all follow that scheme and at least one pool (F2pool) that mines more than one together.

[Sergio_Demian_Lerner]

While this is not exactly on topic, I'm curious.  Why do you think that the Namecoin scheme does not work and that no other coins would adhere to that scheme?  I'm at least aware of three other chains (Namecoin, Huntercoin and Xaya) that all follow that scheme and at least one pool (F2pool) that mines more than one together.

Check it yourself from the algorithm given in the wiki. Also the wiki states this. If merkle_size is a power of 2, when there is a slot collision of slots for some chain ids, then the collision will persist no matter what merkle_nonce you use. I can sent you a code function that checks this by scanning but it's clear from the equations this is true.

So I don't know how f2pool is doing it, it will work if it's merging 3 chains, but not for merging 4.

[domob]

While this is not exactly on topic, I'm curious.  Why do you think that the Namecoin scheme does not work and that no other coins would adhere to that scheme?  I'm at least aware of three other chains (Namecoin, Huntercoin and Xaya) that all follow that scheme and at least one pool (F2pool) that mines more than one together.

Check it yourself from the algorithm given in the wiki. Also the wiki states this. If merkle_size is a power of 2, when there is a slot collision of slots for some chain ids, then the collision will persist no matter what merkle_nonce you use. I can sent you a code function that checks this by scanning but it's clear from the equations this is true.

So I don't know how f2pool is doing it, it will work if it's merging 3 chains, but not for merging 4.

Ah yes, I've heard of that before.  But if that happens, you can still make your Merkle tree larger and most likely not have collisions anymore, right?  So this is clearly a bug in the original implementation, but no deal stopper.  (And in theory this could be fixed by using a different way to assign slots.)

With Armadillo, you will never be able to put an arbitrary number of merge-mined chains into a fixed amount of coinbase space.

(Note that I'm not saying Armadillo is a bad idea, I just previously had the impression when talking to miners that coinbase space is a concern for them or for some of them.)

[Sergio_Demian_Lerner]

Ah yes, I've heard of that before.  But if that happens, you can still make your Merkle tree larger and most likely not have collisions anymore, right?  So this is clearly a bug in the original implementation, but no deal stopper.  (And in theory this could be fixed by using a different way to assign slots.)

I agree. You can always use a higher number of slots, with little space wasted for the merge-mining proofs.

With Armadillo, you will never be able to put an arbitrary number of merge-mined chains into a fixed amount of coinbase space.

(Note that I'm not saying Armadillo is a bad idea, I just previously had the impression when talking to miners that coinbase space is a concern for them or for some of them.)

Yes. The space could be a concern, but the monetary incentive to merge-mine is higher than the cost of the extra bytes.
I think the major problem for miners to add new merge-mined sidechains is not the space, but the one-time integration cost with a new full node. And the periodic maintenance cost to upgrade it.