Since the day Satoshi mentioned the possibility of merged mining in 2010, several techniques have been devised to take advantage of the Bitcoin hashrate to secure a sidechain or a remorachain. In this article, we analyze five variants of merged mining (one new introduced here) and compare their pros and cons.
The basic merge-mining protocol is to store in a unique position in a Bitcoin block a hash of a sidechain block, creating a unique link. While mining the Bitcoin block looks for a Bitcoin block hash lower than the target Bitcoin’s network difficulty at that block, mining a sidechain block involves the same process but targets the sidechain difficulty corresponding to the linked sidechain block. The mining loop is still the same. In normal mining, each loop iteration ends with a hash comparison against a target. Conceptually, what is added in merge-mining is a second comparison prior to the Bitcoin target comparison, although this is a simplification that applies only to solo mining.
Blind merge-mining (BMM) is a merged mining variant where the BMM miners perform per-block auctions of a scarce block space that is used to publish sidechain block hashes, but they are relieved from the responsibility of validating sidechain blocks. New actors, that we can call sidechain virtual miners, take the responsibility of creating sidechain blocks and compete in the auctions to get them referenced by BMM miners in their Bitcoin blocks. Sidechain virtual miners collect revenue from transaction fees, and if the sidechain mining market is efficient, they will spend most of it to buy the scarce BMM space offered by BMM miners.
BMM resembles a timestamping service but with two important differences: BMM guarantees the availability of the sidechain hash (it does not hide it under a Merkle tree), and also guarantees that two block hashes for the same sidechain cannot be time-stamped together.
Compared with standard merged mining, BMM is a simplification that assumes that the sidechain difficulty and Bitcoin difficulty are always the same, and therefore the sidechain block production rate cannot outpace Bitcoin’s rate. This means that there is no need for an additional difficulty check in the mining loop. Additionally, BMM publishes block parent links together with the sidechain block hashes to establish a virtual DAG of sidechain forks within the Bitcoin blockchain. The existence of sidechain block hashes does not guarantee that those blocks will be part of the sidechain honest fork: The sidechain can skip block links with unavailable payload, or links to blocks that execute invalid state transitions. However, since parent links are validated by sidechain consensus, a malicious miner cannot create a fully hidden fork (at least the fork linkage must be public). Last, as mentioned before, BMM releases the miner from the responsibility of running a sidechain node. A BMM miner’s responsibility is only to coordinate a per-block auction, where only the winner pays his highest bid. The auction is performed using a new type of Bitcoin transaction called BMM request. Miners can only accept one BMM request for each sidechain. To guarantee uniqueness, each sidechain has a distinct id. As a result, the auction winner is given a unique space in the Bitcoin block to store the sidechain block hash. As a counterbalance to this benefit, sidechain full nodes must also run Bitcoin nodes to discover the honest sidechain fork, which is the heaviest virtual fork involving the unique sidechain block hashes. BMM was created to support drivechains: a special type of sidechain having a two-way-peg with Bitcoin that is practically secured by Bitcoin miners but with carefully designed incentives to keep miners honest. You can find an excellent analysis of drivechains incentives here. While BMM miners do not need to run sidechain full nodes, miners managing a drivechain two-way-peg are require to. Therefore one of the selling points of Drivechain+BMM is overrated.
The Inclusive Fork-aware Merged-mining (IFAMM) protocol adds to the basic merge-mining protocol two important qualities: it establishes a cryptoeconomic base cost for miners to hide blocks and it also adds an additional cost for miners to revert the blockchain starting from a past block height. The inclusive rule states that blocks that are not merge-mined (they do not have any pointer to a specific sidechain hash) are counted as confirmation hashrate for the last block that did have a pointer. These blocks are called neutral, as they confirm whatever chain was last linked. Absent an ongoing attack neutral hashrate is counted towards the honest chain, preventing future attackers from doing long organizations involving current blocks. The IFA rule adds information in Bitcoin blocks regarding parent-child relations of sidechain blocks. This rule also builds a DAG where concurrent forks can be computed only by looking at Bitcoin blocks, similar to BMM. However, in the case of IFA merged-mining, this DAG is cryptoeconomic (the attacker can hide blocks from the DAG at a certain cost) while, as we’ll see later, the DAG in IFA BMM, the attacker can’t hide blocks.
RSK currently uses Fork-Aware Merged Mining, and there is a proposal to add inclusiveness to it. Real time fork alerts are provided by the Armadillo system.
A Syncchain is a merge-mined chain that is synchronized with Bitcoin at higher intervals, 60 minutes for example, but is synchronic to Bitcoin for shorter intervals. In other words, it uses merge-mining to produce blocks at a higher rate than Bitcoin, but at certain periodic checkpoints, it synchronizes with the bitcoin chain in a loose or delayed way. This loose synchronization prevents reorganizations of the Bitcoin blockchain to affect the sidechain blocks. In a way, a Syncchain captures many of the benefits of a merge-mined chain (higher block rate) while keeping a synchronization property that aids moving bitcoins to and from the sidechain securely with a low number of block confirmations.
BMM could also benefit from the inclusiveness of IFAMM: blocks that do not have any pointer to a specific drivechain can be counted as confirmation hashrate for the last drivechain block. As BMM provides fork-awareness natively, an IFA variation of BMM would be better than BMM alone. To create fork-awareness for BMM, a new rule must be added to Bitcoin so that if a block does not contain an accepted BIP300 BMM request for a specific sidechain, then the Bitcoin block should be able to indicate this succinctly. One possibility is that all accepted BMM requests transactions are packed immediately past the coinbase transaction, and sorted by sidechain id. A dummy BMM request with the highest id is stored at the end. Therefore anyone can create a Merkle exclusion proof by showing two contiguous DMM request transactions that correspond to lower and upper bounds of the missing sidechain id. Another way is to use a bitmap, as specified in my previous article about merged mining.
In the following table, we compare the variants of merged mining:
In this article, we compared several variations of merge-mining: Standard, IFA, Blind, IFA Blind and IFA Syncchain. We showed that IFA is superior to standard merged mining, IFA Blind is superior to Blind, and IFA Syncchain is superior to IFA Blind. However, both IFA BMM and IFA Syncchain require sidechain participants to run both a sidechain and a Bitcoin full node, while standard and IFA do not. Fork-aware merged mining (IFA) stands out from all variants because it is the only protocol that provides all the security benefits, but does not require a soft fork of the Bitcoin protocol. This is the reason why RSK uses IFA to secure its sidechain.
Coinsmart. Beste Bitcoin-Börse in Europa
Source: https://medium.com/iovlabs-innovation-stories/merged-mining-variants-67848d0e4cf8?source=rss——-8—————–cryptocurrency
