Bitcoin Forum
September 20, 2020, 05:32:57 AM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Armadillo in RSK: placing merge-mining security on par with Bitcoin mining  (Read 142 times)
Sergio_Demian_Lerner
Hero Member
*****
expert
Offline Offline

Activity: 549
Merit: 544


View Profile WWW
August 01, 2019, 10:00:01 PM
Merited by DarkStar_ (4), ETFbitcoin (3), malevolent (1)
 #1

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 Smiley). 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.

1600579977
Hero Member
*
Offline Offline

Posts: 1600579977

View Profile Personal Message (Offline)

Ignore
1600579977
Reply with quote  #2

1600579977
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1600579977
Hero Member
*
Offline Offline

Posts: 1600579977

View Profile Personal Message (Offline)

Ignore
1600579977
Reply with quote  #2

1600579977
Report to moderator
domob
Legendary
*
Offline Offline

Activity: 1117
Merit: 1116


View Profile WWW
August 02, 2019, 05:13:49 AM
 #2

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?

Use your Namecoin identity as OpenID: https://nameid.org/
Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
Sergio_Demian_Lerner
Hero Member
*****
expert
Offline Offline

Activity: 549
Merit: 544


View Profile WWW
August 02, 2019, 10:22:10 PM
 #3

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
Legendary
*
Offline Offline

Activity: 1117
Merit: 1116


View Profile WWW
August 03, 2019, 06:57:40 AM
 #4

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.

Use your Namecoin identity as OpenID: https://nameid.org/
Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
Sergio_Demian_Lerner
Hero Member
*****
expert
Offline Offline

Activity: 549
Merit: 544


View Profile WWW
August 04, 2019, 03:13:26 AM
Last edit: August 04, 2019, 03:57:03 AM by Sergio_Demian_Lerner
 #5

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
Legendary
*
Offline Offline

Activity: 1117
Merit: 1116


View Profile WWW
August 04, 2019, 08:05:55 AM
 #6

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.)

Use your Namecoin identity as OpenID: https://nameid.org/
Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
Sergio_Demian_Lerner
Hero Member
*****
expert
Offline Offline

Activity: 549
Merit: 544


View Profile WWW
August 05, 2019, 03:50:55 AM
Last edit: August 05, 2019, 06:32:15 PM by Sergio_Demian_Lerner
 #7


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.
 

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!