Proof of work (PoW) is a fundamental part of Nakamoto Consensus. It has two functions: It is a Sybil resistance mechanism used to select block producers, and it also provides a baseline and always increasing cost for reverting the blockchain. That’s why it is said that PoW secures the Bitcoin blockchain.
Merged mining is a technique to re-use the work spent in securing one blockchain to simultaneously secure another blockchain. In the same way as PoW powers Nakamoto Consensus, merge-mining can power the consensus of different blockchain. The consensus protocol of the merged mined chain can also be Nakamoto, or it may be a variant of it, such as GHOST or DECOR. The action of applying the merged mining technique is often called “to merge-mine”. The only requirement to merge-mine two blockchains is that they use the same block header hashing function (and difficulty check) to obtain the PoW.
The way merged mining works is simple. First, let’s assume there is a primary blockchain (let it be Bitcoin) and a secondary blockchain S. Let hB and hS be two new block headers of Bitcoin and S respectively. Let H be an arbitrary cryptographic hash function. To start mining, the merged miner must build the template for hB such that it references H(hS) univocally. The mining process changes very little. When mining, miners try to find the nonce that results in the proof of work for hB that satisfies the difficulty established by the Bitcoin network as usual (i.e SHA256D(hB) < targetB). However, if the miner finds a Bitcoin block header with proof of work that matches the difficulty of the merge-mined chain (SHA256D(hB) < targetS), then hB, hS, together with some additional header linking information, becomes a valid proof of work of the merge-mined block. The full merge-mined block would contain the PoW and other remaining chain-specific data (i.e. the transactions referenced by hS). The block is sent to the secondary blockchain network to be appended to the secondary blockchain. With merged mining, two different proofs of work can be created for the price of one.
Merged mining is almost as old as Bitcoin. In 2010 Satoshi himself proposed the use of merged mining to secure an hypothetical BitDNS sidechain that would store decentralized domain names. The idea was soon implemented and launched as the Namecoin altcoin. Namecoin began merge-mining with Bitcoin in 2011 to achieve higher security.
During that period, other blockchains followed this trend and began merge-mining with Bitcoin. But it was not all roses. In 2012 LukeJr performed a 51% attack on Coiledcoin, which at that time was merge-mining with Bitcoin. That event showed that merge-mining is not the security panacea for every blockchain, and there must be a high incentive alignment between the new merged mined chain and the previous ones for this mechanism to be secure.
During 2014, another important event took place. Dogecoin and Litecoin where using the same mining function and miners started switching en mass between the two blockchains. When Dogecoin was more profitable, they would all switch to mine Dogecoin, accelerating block production. When the Dogecoin difficulty adjustment kicked in and made it too difficult to mine profitably, they would switch en mass to Litecoin to maximize profitability, and the cycle would repeat. This caused hashrate instability, erratic block rates and token issuance. Afterwards, Dogecoin hashrate became too low to be considered secure. Dogecoin community decided to begin accepting blocks merged mined with Litecoin. As of today, there was no attempt by any miner in one community to attack the other. There are several reasons why no attack was perpetrated: first, merge-mining was beneficial to both communities because with merged mining the block difficulty and block rates could stabilize again. Second, it was also beneficial for miners, who could temporarily double their revenue (until blockchain upward difficulty adjustments ended this grace period). Third, having comparable hashrates, no single miner could easily attack the other chain. Fourth, there was no ideological dispute between Litecoin and Dogecoin communities (we can ask ourselves if there was any sense of belonging in those communities). Miners would just mine the most profitable chain.
One of the reasons merged mining was historically preferred is that it enables the creation of fully independent blockchains. By independent we mean that those secondary chains can continue to live even if the primary chain pauses due to a technical problem or simply dies out without support by its community. The secondary chain can still continue getting work from the merge miners without a primary chain. In early years, not even Bitcoin had a future assured. One of the reasons the Rootstock sidechain chose merge mining for its consensus protocol (instead of a federated consensus like Liquid) is that Rootstock was created during the Block Size wars, and there was a real risk of Bitcoin being disrupted by attackers or torn apart by a divided community.
An important reason to prefer merged mining over other alternative ways to inherit Bitcoin security is that merged mining lets the secondary chain have a higher block rate.
After Bitcoin, all blockchains created were designed to support higher block rates (lower inter-block times). This is believed to negatively affect decentralization as it can lead to solo miners generating more orphan blocks, forcing them to join larger pools to stay competitive. High block rates have several benefits, the evident one being that user transactions are confirmed faster. A paradoxical benefit of higher block rates is that the reward payout variance is reduced: this in turn reduces the incentives to join large mining pools, which improves decentralization. The block rate represents a usability-decentralization tradeoff and the ideal rate is difficult to find.
Therefore, designers of merged mined blockchains that want to merge-mine with Bitcoin should be very careful with block rates. An average block interval below 10 seconds without adopting more inclusive consensus protocols can put an additional bandwidth stress on merged mining pools, increasing costs, which may put them in disadvantage with non-merged mined pools.
Contenders To Merged Mining
Similar to Nakamoto merged mining, there are other ways to inherit security from other chains. The first known method was implemented by the Mastercoin/OMNI protocol, and was followed by the Counterparty protocol. New projects such as RGB also adopted this method. The method is based on the embedding of the transaction data of an alternate ledger in Bitcoin transactions. In RGB, this embedding still exists, but it is completely hidden inside the Taproot tree. However, neither the Mastercoin/Counterparty/RGB ledger history forms a separate blockchain. The ledger history is simply the sequential list of special transactions embedded in Bitcoin blocks. There are other ways to create separate blockchains that inherit security from a primary chain, generally by trying to fully or partially synchronize the two blockchains. All are based on publishing data in OP_RETURN outputs. Some examples are Veriblock, PoX and Syncchains. With these “synchronized” chains, the reversal of a primary chain block automatically reverses the secondary chain blocks that came afterward. One disadvantage is that they force secondary blockchain nodes to run also primary chain nodes. While linked blockchains can provide shared security (and fast cross-chain transfers), synchronous consensus cannot provide faster block rates for the secondary blockchain without introducing another switched consensus protocol (i.e. Bitcoin NG‘s microblocks). On the contrary, a merged mined chain can use any block rate, although, as mentioned before, there is a threshold that if surpassed merged mining becomes uneconomical due to high bandwidth requirements.
Criticism and Evolution
Merged mined in Nakamoto consensus has been analyzed, and both supported and criticized in research papers. However, all existent research has focused on the practical effects of merged mining on decentralization while there is still a lack of formalization of the method. Academic research has not gone past the Namecoin merged mining method. But this method has been been vastly improved. The launch of the Rootstock Bitcoin merged mined sidechain in 2018 revived research, which led to the discovery of more secure merged mining protocols, such that the fork-aware variants. Some of these improvements were implemented in Rootstock in successive network upgrades. However, the new theoretical research is still scattered in online articles and RSKIPs (Rootstock improvement proposal) and it deserves better documentation. The new variants of merged mining, which will be discussed in a following article, can resist some known attacks. For example, it is generally believed that a merge-mined sidechain can’t be secure against double-spend attacks when the merge-mining hashrate is low (i.e. <10% of the primary chain hashrate), while with some new protocol variants it can (under slightly different security and liveness assumptions).
The Namecoin Merged mining Design
The way Namecoin merge-mines with Bitcoin is simple. At the end of the coinbase field of the generation transaction the miner writes 4 bytes that indicate that an AuxPow record follows. These 4 bytes are called magic bytes and are used by Namecoin to find the AuxPow record easily. Next we find the AuxPow record where the miners must store the root hash digest of a Merkle tree containing the block hashes of the different blockchains that are being merge-mined. Then the treeSize field follows, which specifies the number of merge-mined blocks of distinct blockchains included in the tree, and a treeNonce field that is supposed to help avoid collisions of chain ids, but the design is flawed and this value is unused. The following diagram depicts a Bitcoin block carrying an AuxPow record linking to 4 blocks (W,X,Y, and Z) from 4 different merge-mined blockchains:
For Namecoin nodes to verify the proof of work of a Namecoin block, the block must include data fields containing:
- A Merkle path to prove the inclusion of the Coinbase transaction in the Bitcoin block transaction tree
- The coinbase transaction itself, containing the AuxPow tree root.
- A Merkle path to find the Namecoin block hash in the AuxPow tree.
Namecoin consensus has a rule to verify the merge-mining proof, and the proof of work of the Bitcoin header (ignoring all other fields).
Primary/Secondary Chain Distinction
We generally distinguish a single primary blockchain from all merge-mined secondary blockchains because the secondary blockchains blocks need an additional Merkle proof to allow the verification of the proof-of-work. But from a game theoretic perspective, there is no primary blockchain. All of them contribute to the security budget. If the primary blockchain hashrate went down to 10% of the total merge-mined hashrate, one would be tempted to say that the secondary blockchain has become the primary one, because now that blockchain will probably be the one that paying for most of the security budget. The distinction can be even more confusing because a merge-mined “secondary” blockchain can grab work from more than one “primary” chain, as is the case of Rootstock. While most of the Rootstock hashrate comes from Bitcoin miners, there were times where a small portion of the hashrate came from Bitcoin Cash miners, therefore Rootstock inherited hashrate from two primary chains.
Even if for philosophical reasons one would not want getting hashrate from, for example, Bitcoin SV, this cannot be easily prevented. From the Rootstock consensus perspective Bitcoin and Bitcoin SV block headers look identical (the parent block or difficulty fields could be used to heuristically distinguish them based on the block difficulty, but this wouldn’t be precise). It is therefore possible for Rootstock to have a higher hashrate than Bitcoin by combining the hashrate of all SHA256D based blockchains, including Bitcoin.
Therefore, we stick to a syntactical definition: the primary chains are the ones with shorter merged mining proofs normally having a single block header, and the secondary chains are those requiring an additional block header and its hash embedded in the first.
During the 2011–2013 period there were several proposals published in bitcointalk.org forum to perform a Bitcoin hard-fork to abstract out the Bitcoin proof of work in a separate “master” header-chain, and make all merge-mined blockchains’ blocks (including Bitcoin’s) derive from this master header-chain. All blockchains blocks hashes would be part of a single Pow Merkle Tree. However, these proposals didn’t get traction (in general, no Bitcoin hard-forking proposal ever got traction).
In fact, the master header does not need to be part of a chain at all. The header can be tiny and simply specify a Merkle tree root of chain block hashes and the nonce required to mutate the header to find the PoW. As we’ll see in a follow up article, having a timestamp field in this tiny header can improve the security of all merge-mined chains, This imaginary tiny header is depicted in the following figure where X and Y refer to some other merge-mined blockchains:
If this data structure had been adopted, there wouldn’t be any primary blockchain in Bitcoin merged mining.
When we analyze the incentives for miners to secure more than one blockchain with the same proof of work, we must analyze all of them as equal chains. To analyze merge-mining incentives we should think about SHA256D miners (the actual hash function used) instead of Bitcoin miners. We must analyze all merge-mined blockchains and the incentives that blockchains provide to miners.
Bitcoin sidechains increase Bitcoin’s utility and therefore they contribute to Bitcoin’s value. Using sidechains, bitcoiners can perform private payments, create DAOs, and explore innovative use cases without trading their bitcoins for other more volatile coins (sometimes called shitcoins by Bitcoin maximalists). There are currently two Bitcoin sidechains in existence: Liquid (federated consensus) and Rootstock (merged mined).
The Rootstock sidechain offers cheaper payments and Decentralized Finance (DeFi) applications. One of the useful decentralized applications for bitcoiners is self-loans in stablecoin collateralized by rBTC. This solution allows bitcoiners to use fiat denominated tokens and not be forced to sell their bitcoins for their everyday spendings.
It is widely believed that DeFi on Bitcoin will grow significantly in the upcoming years, and new unforeseen use cases will be unraveled in the future. That’s why the majority of bitcoiners support Rootstock and are eager to see it grow faster.
The Rootstock sidechain was specially designed to provide incentives to the Bitcoin community. It incentivizes the participation of bitcoiners, and specially Bitcoin miners by using a merged mining consensus protocol. Bitcoin and Rootstock can successfully be merged mined because of the shared incentives and shared communities.
In the following article I’ll present the Rootstock merge-mining consensus model and I’ll also show several innovations created by the Rootstock community that substantially increase the security of merged mining. I’ll also show how merged mining can benefit Bitcoin by increasing its security budget in the long term.
Merged mining is a key part of a PoW based consensus protocol that enables a blockchain to inherit security from a primary chain without duplicating the mining costs. Nakamoto consensus using merged mining can lead to a higher decentralization than consensus protocols based on proof-of-authority or proof-of-stake. However, the primary chain security will only be shared with merged mined chains if the association is mutually beneficial. Therefore, merged mining is ideal for Bitcoin sidechains that can add tremendous value to the Bitcoin network. Rootstock, the first Turing complete Bitcoin smart contract sidechain, is merged mined by more than 50% of the current Bitcoin hashrate, and its hashrate grows every year, making it one of the most secure smart contract networks in existence. Rootstock uses a fork-aware variant of the protocol, which will be discussed in the next article.