Merge mining or merged mining is the process of mining more than one blockchain simultaneously. This is possible for some proof-of-work (POW) chains, where a miner puts the same hash power to work creating blocks on multiple chains and earns the associated rewards on each of them, without having to pay separate energy costs for each. Here, I explain the ideas behind merge mining.
For a blockchain incorporating the proof-of-work protocol, miners use hash power in order to win the chance of appending their block. For leading chains such as Bitcoin, this is an energy intensive process where each individual hash has a minuscule chance of winning. They need to perform a huge number of hashes to be in with any chance. Where there are multiple proof-of-work chains available, the miner needs to choose which one to contribute his hash rate towards. So long as his hardware is compatible with the specific hashing algorithms used (such as SHA256), he is free to mine on either chain, and switch between them as desired. Usually, it is not possible employ the same hash power simultaneously on both chains. This is because each hash is applied to the block header for the chain in question, so can only be used for solving the POW problem for that specific blockchain. However, if the protocol for all (or, all but one) of the blockchains in question have been designed to specifically to allow for it, then it can be possible for each hash function application to contribute to the proof of work on each chain simultaneously. This is known as auxiliary proof-of-work (AuxPOW).
There are several blockchains that can be merge mined along with Bitcoin. The first such case was Namecoin (NMC), which was created in April 2011 and upgraded in October 2011 to support merge mining. Another example is Rootstock (RSK), which was created in January 2018 and is a sidechain of Bitcoin supporting smart contracts. According to the article The Growth of Bitcoin Merge Mining from October 2020, over 90% of the Bitcoin hashrate is involved in merge mining. This is shown in figure 2 below, borrowed from the same article and showing the proportion of Bitcoin blocks which contain an auxiliary proof-of-work in the coinbase transaction, indicating that it was merge mined along with another blockchain. One notable example not involving Bitcoin is Dogecoin, which is merge mined along with Litecoin, using the scrypt hash function.
By construction, if two blockchains can be merge mined, then they necessarily use the same POW hash function. However, it should be understood that they can be completely independent of each other. While it will depend on the specific set-up of the chains in question, they can have different rates of block production, different rewards and different difficulty levels. This is as in Figure 1 above, with a hypothetical blockchain ‘X’ being mined along with Bitcoin. Both blockchains have different block production times, and the miner occasionally succeeds in producing blocks on each of the chains at different rates. Merge mined blockchains do not have to be mined together and can in theory exist independently of each other. There is not generally any link between blocks on the separate chains, and each chain can have its own network of nodes independently performing validation without reference to the other.
Interestingly, the idea of merge mining was suggested by Satoshi himself back in December 2010 in the Bitcointalk forum. To quote him directly:
I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.
The networks wouldn’t need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty.
I think an external miner could call getwork on both programs and combine the work. Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.
Instead of fragmentation, networks share and augment each other’s total CPU power. This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one. Instead, all networks in the world would share combined CPU power, increasing the total strength. It would make it easier for small networks to get started by tapping into a ready base of miners.
Satoshi seems to be envisaging merge mining all POW chains in a single combined POW effort, although that currently does not seem to be a likely scenario.
When multiple blockchains are merge mined together then, in theory, there does not have to be any special ordering between them. In practice though, there tends to be one which is more established with a significantly higher hashrate, miner rewards, and total secured value. This is referred to as the parent (or main, or primary) blockchain, with the remaining ones being the child (or auxiliary, or secondary) chains. Also, as I will explain below, the protocol usually makes a distinction between the parent chain whose protocol uses regular POW with no awareness of merge mining, and the child chains using AuxPOW in an attempt to benefit from the parent’s hash power. In the examples of NMC and RSK mentioned above, these are children to the Bitcoin blockchain. More interestingly, according to the protocol, Dogecoin is merge mined as a child of Litecoin although, due to major price increases, the rewards for mining Dogecoin are currently more than twice that of Litecoin.
As mentioned above, when multiple blockchains are merge mined, their difficulty levels and average block production times can be completely independent. However, with the standard AuxPOW algorithms, if the miner does solve the POW for one block, then he simultaneously solves it for all merge mined chains with a lower difficulty. This is because the generated hash value will be below the threshold required for that block, so will also be below the larger threshold of all blocks of lower difficulty. For example, if he is merge mining RSK along with Bitcoin then, whenever a valid Bitcoin block is produced, an RSK one will also be created. On the other hand, he will likely generate RSK blocks without an accompanying valid Bitcoin one.
Pros and Cons of Merge Mining
The aim of this post is to explain auxiliary proof-of-work and how merge mining is possible, rather than to evaluate a list of all the benefits and drawbacks. It is good, however, to have an idea of some of the main points before going into the technical details. Starting with the benefits:
- Where there are multiple proof-of-work blockchains in existence, then usually each available bit of miner hash power would be assigned to only one of these. This could make it more difficult for some chains to be able to attract enough hashrate to be sufficiently secure. With merge mining the POW chains do not need to compete and, instead, can work cooperatively by sharing hash power. Specifically, a low value blockchain can gain security benefits from merge mining with a high hashrate blockchain such as Bitcoin.
- Where multiple proof-of-work blockchains exist employing the same hash function, it can be easy for miners to switch between one or the other at will. This can cause swings in hash rate between the different chains as miners keep switching to the most profitable opportunity. This effect was seen with miners switching between Litecoin and Dogecoin in 2014 prior to the implementation of merge mining for these blockchains, and described in the article The Litecoin vs. Dogecoin hash-rate wars of 2014 and implications for Bitcoin vs. Bitcoin Cash.
- It is in miners’ economic interest to merge mine where available, since they gain the economic benefits from the block rewards of the additional chains without having to use any significant additional hashpower.
- Merge mining is publicly visible, since it can often be seen which chains have been mined along with any given block (as used in the construction of figure 2). This can be used to provide data on hidden forks, total mining power, and possible 51% attacks, improving security.
- Although merge mined chains can be entirely separate from each other in all but the way in which they were mined, it is possible to set up the protocol to include cross-chain consensus rules. This can be useful if we want some interaction between them, such as with sidechains.
Unsurprisingly, there are also drawbacks to merge mining and, in some cases, it can be controversial.
- If a relatively low value blockchain is set up for merge mining with a much larger one with a high hashrate, such as Bitcoin, then there are possible problems if it does not gain significant adoption. Suppose that only a minority of Bitcoin miners decided to engage with this merge mined chain, leaving the majority of the Bitcoin hashrate not involved. Just as those uninvolved miners can decide to put their hashrate towards mining the new blockchain with little cost, they can also choose to attack it. This has actually happened, with the Eligius mining pool attacking fledging cryptocurrency CoiledCoin in 2012. Fortunately, there are methods which may guard against such attacks, such as making use of the visibility of merge mining activity and applying cross-chain consensus rules to try and add some economic cost to such activity. This problem, along with ways to guard against it, are explained in the article Modern merge mining, in the context of the RSK sidechain.
- Although merge mining allows a miner to create blocks for additional chains by reusing the same hashrate at little cost, there are still some costs involved. They would need to install and run the software for constructing blocks in the new chain, which they may not be familiar with. They would also need to maintain a node for this new chain, which could come with significant bandwidth requirements if it has particularly large or frequent blocks. As such, it could be difficult for a small-scale miner to do, and has been argued that it can increase centralization in the parent chain.
Blind merge mining (BMM) has been suggested as an alternative approach which avoids these issues, although it currently does not seem to have gained much traction in real-world use cases. In BMM, the blocks of the child chain are not constructed by the miner of the parent chain. Instead, they are built by a separate party, who pays a miner to include the child hash in his blocks for the parent chain. Then, the miner does not need to know anything about the child chain. He simply accepts payment for including some additional data in his blocks. In this post I will concentrate on regular old common or garden merge mining, rather than BMM.
- A Bitcoin miner who decides to merge mine will receive those rewards in the child blockchain tokens, and not in Bitcoin. Quite likely, they will not be interested in holding such assets, so are motivated to sell as soon as possible. They will also need access to an exchange or marketplace where they can do this easily.
- It is possible for a child chain to incentivise miner behaviour in the parent chain which may not be welcomed. For example, maybe a Bitcoin miner obtains a higher block reward in the child chain if he mines empty Bitcoin blocks. This would be an example of an unwelcome side-effect of merge mining, and could be due to badly designed cross-chain consensus rules, or an intentional attack on the parent chain. It is possible to imagine a blockchain set up so that it can only be merge mined with Bitcoin blocks which do not contain transactions spending from certain addresses. Maybe, for example, these addresses are linked to individuals who are being sanctioned by certain governments and the designers of the child chain are wanting adoption by these government bodies.
Merge Mining in Theory
I now go into the theory and some technical detail of how merge mining is possible. To start, consider the usual POW algorithm for mining a Bitcoin block.
The miner collects together the sequence of transactions to be used in the block. Then, a hash root (Merkle root) of these is computed. The block header is constructed containing this hash, together with other required fields such as a version number, previous block hash, timestamp, difficulty level and the nonce. The hash of this block header is computed (a double SHA256 hash, in the case of Bitcoin). If it is below the threshold for the required difficulty level, then the block is valid. Almost certainly, the hash will not satisfy the difficulty requirement. So, the miner must repeatedly modify the block header and recompute its hash until, eventually, it does satisfy the requirement and can be published. The nonce field is provided for this purpose, since it impacts nothing but the hash value. The miner can keep modifying the nonce and recomputing the hash until, he either wins the race and produces a block hash satisfying the requirement, or another miner finds a block and he needs to start over. This is shown in figure 3 below, with the Merkle root of the transactions denoted by h.
As described above, POW involves repeatedly computing the hash of the block header. So, it can only apply to the chain for which this block is intended. It is not possible for a single hash computation to be valid for two separate blocks in two distinct blockchains.
What can be done? How is it possible for a single hash computation be valid for the POW requirement simultaneously in two blocks in different chains? To answer this, note that the use of the hash of the block header for the POW condition is due to the protocol defined for the chain. If we were to design our own blockchain from scratch, we do not have to set it up in exactly this way. All that is really necessary, is that the POW hash function involves the header in an essential way, so cannot be computed before the block has been constructed. We could take the block and combine with any arbitrary additional data before taking the hash. Or, we can take its hash, combine with additional data and then take the hash again. In fact, we do exactly this in auxiliary proof-of-work.
Consider four hypothetical blockchains W, X, Y, and Z, and suppose that we have constructed a block for each of them. Suppose that we compute their hash values, denoted by hW, hX, hY and hZ respectively. If the POW difficulty condition was applied separately to all of these, then we would need to keep recomputing all four of these hashes (with modified nonces in their block headers) until the conditions are satisfied. This is just performing proof of work separately for each of the blocks.
We can propose the following alternative approach. Simply concatenate the block hashes into a single block of data hWhXhYhZ and compute its hash. In fact, since we are doing this, we may as will include the nonce n, rather than including it in each individual block header. So, we compute the hash h of the concatenated data hWhXhYhZn. If it meets the proof of work condition for any one of the blocks W,X,Y,Z, then it can be submitted for inclusion in the blockchain. Otherwise, we keep updating the nonce and recomputing the hash h until, eventually, it does satisfy the POW condition for one of the blocks. This is as in figure 4 below.
In this setup, once the hashes of the individual blocks have been computed, we only need to apply the hash function once for each iteration of updating the nonce and recomputing h. Even so, the computed hash applies to the proof-of-work condition for all four underlying blocks.
This describes a proposed method of mining all four chains simultaneously. However, we still need to describe the protocol for each of these chains in such a way as to be able to recognise such a block as valid. Suppose, for example, that the hash h satisfies the necessary difficulty level for block X. We cannot simply append this block on its own to the blockchain, since it is impossible for a validator to recompute h without knowing the other blocks and the nonce. The blocks in chain X need to be bundled with some additional data for validating the POW condition. For the procedure outlined above, block X should be packaged along with the prefix hW and suffix hYhZn. Then, the protocol for blockchain X can be defined so that we first compute the hash hX of the block header, then concatenate this with the supplied prefix and suffix to obtain (hW)hX(hYhZn). Finally, the hash of this is taken and the POW condition is declared to be satisfied if it is below the threshold of the block’s difficulty level.
The described protocol is a version of auxiliary proof-of-work. Comparing with regular proof-of-work used by Bitcoin:
- POW: The hash of the block header is compared with the difficulty threshold.
- AuxPOW: The hash of the block header is combined with other data (such as concatenated with a provided prefix and suffix). The hash of this is taken, and compared with the difficulty threshold.
So, if there are multiple blockchains all defined with such an AuxPOW protocol, and using the same hash function for computing h, then they can be merge mined with the procedure above. There are some technical details which would need to be looked at, such as ensuring that miners cannot simultaneously create multiple blocks on the same chain (which I discuss more below), but these are easily addressed. Also, if we wanted to mine a large number of blockchains simultaneously, then organising the block hashes into a Merkle tree would be more efficient than simply concatenating them. This is all well and good, but what if we want to merge mine with Bitcoin? It is likely to be our preferred choice, so that the other chains inherit the benefit of Bitcoin’s huge hash rate. It would be nice if Bitcoin employed such an AuxPOW protocol, but it doesn’t, and this situation is unlikely to change any time soon.
Merge Mining in Practice
Now let’s consider how we can merge mine a child blockchain along with something like Bitcoin which uses a standard POW algorithm using the block header hash, rather than auxiliary proof-of-work of the form described above. This is the situation encountered in practice. First, since we use the Bitcoin block hash, to make this also depend on the child block hashes they must be included somewhere inside the Bitcoin block. Really, it must be included in one of the transactions and, since this procedure is performed by the miner, it is included in the coinbase transaction created by the miner to pay their rewards.
Consider, again, figure 3 above. This shows the construction of a Bitcoin block and the calculation of its hash. As the coinbase transaction is the first one of the block then, if we are to insert the child block hash into it, we obtain something like figure 5 below. Since we do not want to have to distribute the entire Bitcoin block along with the child blocks for the AuxPOW, all transactions are stripped out other than the coinbase and its Merkle proof consisting of the hash values h001, h01, h1 in figures 3 and 5.
There are two places in the coinbase transaction where we can conveniently include arbitrary data such as a child block hash:
- The inputs of a Bitcoin transaction contain some script (called the scriptSig) used to verify that it is allowed to spend the previous unspent transaction output (or, utxo) to which it refers. Coinbase transactions have a single input (called, simply, the coinbase), but this is just a dummy since they only create coins rather than spend any. This leaves its input scriptSig available for storing arbitrary data. Namecoin uses this method, with the scriptSig containing a block of 44 bytes. These consist of the following data:
- magic: 4 bytes equal to fabe6d6d (in hex) indicating that this represents a Namecoin hash.
- hash: 32 bytes for the child block hash (or merkle root, which I will describe below).
- merkle size: 4 bytes, which I describe below.
- merkle nonce: 4 bytes, which I explain below.
- OP_RETURN bitcoin outputs can be used for storing arbitrary data. This is used by RSK, with the child block referenced by 41 bytes of data consisting of the following:
- 9 bytes consisting of the string ‘RSKBLOCK:’, or 52534b424c4f434b3a in hex.
- 32 bytes consisting of the child block hash.
Actually, the RSK specification allows this data to appear anywhere in the coinbase transaction, although in an OP_RETURN output is usual.
With the method described here, there is no real need for the child blocks to contain a nonce, since that is already taken care of by the Bitcoin header. Regardless of the precise format and whether the data is stored in the scriptSig or an OP_RETURN output, if the Bitcoin block is below the child difficulty threshold, the child block is valid and can be appended to its blockchain. The following needs to be distributed alongside the child block:
- The Bitcoin coinbase transaction.
- The coinbase Merkle proof (hashes h001, h01, h1 in figure 5).
- The Bitcoin block header.
This is sufficient data for a network node to be able to determine if a child block satisfies the AuxPOW condition. Any such validator should perform the following steps:
- Compute the child block hash, and check that it is correctly included in the coinbase transaction.
- Back out the Merkle root h of the Bitcoin transactions from the coinbase transaction and its Merkle proof. Using H to denote the hash function (double SHA256), this consists of the following steps (in the case of figure 5, for a Merkle tree of depth 3),
h000 = H(t1), h00 = H(h000h001), h0 = H(h00h01), h = H(h0h1). - Check that the value h computed in the previous step matches the Merkle root in the supplied Bitcoin header.
- Compute the hash of the Bitcoin header and check that it is below the proof-of-work threshold of the child block.
If these checks succeed, the child block is valid! I stress that the AuxPOW validator need not know anything about the Bitcoin blockchain itself, and the supplied Bitcoin header need not be an actual block in the canonical chain. Typically, if the child chain has a lower difficulty level, then this will not satisfy the correct POW threshold for Bitcoin anyway. Also, the validator may not know the difference between Bitcoin headers and headers of very similar blockchains such as Bitcoin Cash, so it could also be merge mined with these and the child network would be none the wiser.
Mining Multiple Children
So far, I described how auxiliary proof-of-work can be used to merge mine a child blockchain along with Bitcoin, or other POW chain. But what happens if we want to mine more than two once, so that there are multiple children? This is not particularly difficult, although there are a couple of ways of going about it. One method is to include multiple block hashes in the coinbase transaction, one for each of the child blocks that we want to mine. For example, using the RSK method of putting the hash into an OP_RETURN output, we can simply use multiple OP_RETURN outputs, one for each child block that we wish to mine.
Another approach is to merge multiple child block hashes into one, and just include this in the coinbase transaction. While this saves some space in the Bitcoin block, it does require additional information to be packaged in the AuxPOW data stored along with the child block. For hypothetical child chains W, X, Y, and Z, this could work similar to figure 4 above (but without the nonce). We just concatenate the child hashes together and take the hash of this to be included in the Bitcoin block. Then, the AuxPOW information should include the prefix and suffix data, so that these can be concatenated with the child hash to verify that it does indeed have the correct hash value.
Alternatively, the child hashes can be combined in a Merkle tree. This would be more efficient if many children are being mined together, since the AuxPOW would only need to include the Merkle proof in order to recompute the Merkle root h. This is as in figure 6 below, where the Merkle root h is put in the Bitcoin block in place of the individual child hashes. If the miner solves the POW difficulty condition for block X, for example, then its AuxPOW information would include the proof consisting of hashes hW and hYZ.
This is the approach used by Namecoin, so that the 32 byte hash can represent either a single child block hash, or a Merkle root of several children. Whichever is the case can be determined by the 4 byte ‘merkle size’ field, which must be a power of 2 (for a nicely balanced tree). This represents the number of leaves of the tree, so if it is equal to 1 then it is just the hash of a single child block. On the other hand, if it is greater than 1, then it is the Merkle root of an array of multiple block hashes for several child chains (the number of children can be less than merkle size, since the tree can be padded out with dummy hashes not corresponding to any child).
So, all child blockchains whose protocols implement the Namecoin AuxPOW specification can be mined simultaneously with Bitcoin while sharing the same Merkle root in the coinbase. This includes Namecoin, of course, but also various other chains such as Syscoin (SYS)
There is one drawback to combining child hashes, such as is done for the Namecoin specification. It is rather opaque. If we see that the coinbase of a Bitcoin block contains a 44 byte block of data starting with the ‘magic’ code fabe6d6d then we know that it has probably been merge mined along with some child chains. However, it can be difficult, or even impossible, to say what they are. It could include a Namecoin block, a Syscoin block, or any of the other blockchains which adhere to this specification. On the other hand, we can easily tell if it was mined along with Rootstock, since there will be an OP_RETURN output containing a 41 byte block of data with the prefix ‘RSKBLOCK:’.
There is a very important point which should be considered when looking at protocols for merge mining with multiple child blocks: it must not be possible to mine more than one block from the same chain at the same time. If this was possible, then we could mine a whole string of blocks in the chain while only paying the POW required for a single one. This would make a mockery of the idea of the chain POW, and make it very easy to perform 51% attacks without having close to 51% of the actual hash rate. Even simultaneously mining blocks in different branches of the same blockchain would be a big problem. This is because, in the event of a fork, miners would be incentivised to mine blocks in all branches at once. That way, they would get to keep any block reward regardless of which one wins out while only paying the POW to mine a single one. This would absolve miners of the responsibility of choosing the branch to build on, which is a vital part of the Nakamoto consensus since it allows the network to settle on one single canonical blockchain branch.
For a protocol such as that used by RSK, it is straightforward to ensure that multiple blocks from the chain cannot be simulteneously mined. The AuxPOW protocol only needs to include the condition that the coinbase transaction only includes a single valid substring consistent with the RSKBLOCK fields.
For protocols such as that used by NMC, where multiple block hashes are combined into a single Merkle root, it is more difficult. Even if the AuxPOW information contains a Merkle proof showing that a given NMC block hash is contained in the Merkle tree, it is impossible to say in general what other blocks may be included in the other leaves. It is for this reason that the protocol requires each blockchain to assign a unique hardcoded number (the chain ID) which maps to the index for the block hash position in the tree. So, all block hashes corresponding to the same blockchain would have to be put in the same slot, meaning that there can be no more than one of them. The ‘merkle nonce’ field mentioned above is intended to scramble the map from chain ID to index to avoid clashes between different blockchains but, due to a bug in the protocol, this is completely useless and only applies a shift to the index. Instead, the merkle size field should be chosen large enough to avoid such clashes, and the nonce is usually just set to 0.
Example
As an example, I randomly picked a recent Bitcoin block (height 733,528, mined 25 April 2022 by ViaBTC pool) and looked at its coinbase transaction. This contains a single input (the coinbase) as standard, but also 4 outputs. The first of these outputs is paying the mining reward of 6.43 bitcoins, and the remaining 3 outputs are all of type OP_RETURN containing some data.
The input scriptsig pushes some values onto the stack, including the following 44 bytes (in hex). I split them up according to the description of Namecoin merge mining given in the Bitcoin wiki.
| Namecoin merge mining data | |
| magic | fabe6d6d |
| merkle root | 250978ac44fd7d6e0e837ee74d4d786d 7869991ffae36d593045ffd612f988af |
| merkle size | 10000000 |
| merkle nonce | 00000000 |
This shows that the Bitcoin block was mined along with child blocks whose hashes have the given Merkle root. While it is impossible, in general, to back out from this what the child blocks are, we can check a Namecoin explorer to see if any blocks have an AuxPOW information corresponding to it. In particular, we see that it corresponds to Namecoin block of height 609,282. The explorer linked to shows the AuxPOW information in the ‘Raw Block’ tab. It could also include other merge mined blocks of additional child chains, but these are not easily visible from the Merkle root alone.
The first OP_RETURN output contains the following 41 bytes of data fitting the format for RSK blocks.
| Rootstock merge mining data | |
| RSKBLOCK: | 52534b424c4f434b3a |
| RskBlockInfo | 2b7125dd7547680378797d8e831e2214 1287ac1749f4826870900f3800410bd2 |
So, it was also merge mined along with RSK and, from an RSK explorer, can be seen to correspond with block 4,262,866 (RskBlockInfo corresponds to Hash For Merged Mining in the explorer).
The second OP_RETURN output contains 36 bytes of data fitting the template for merge mining Vcash.
| Vcash merge mining data | |
| magic | b9e11b6d |
| hash | 4869fa8eeb9618a6791a4000a6487ca1 f0a4dc277b48051563ac656dd228a044 |
See the merge mining info on github for details. Thanks to Murch for identifying the Vcash merge mined data in a bitcoin.stackexchange answer. Again, checking a block explorer, we see that this corresponds to Vcash block 525,469.
The final OP_RETURN output contains the Merkle root of the block’s witness data, indicated by the first four bytes of data being ‘aa21a9ed’, so is nothing to do with merge mining. We have seen that Bitcoin block 733,528 was merge mined along with NMC, RSK, and Vcash. Also, the NMC merge mining info is a Merkle tree possibly containing further merge mined chains.
Cross-Chain Consensus Rules
One interesting aspect of merge mining, which can be considered as either a benefit or — in some cases — a problem, is the possibility for cross-chain consensus conditions. For example, if a child blockchain X is merge mined along with Bitcoin, then it is possible for the child to force rules on the parent. This could be useful if the child is used as a side-chain, which is supposed to interact with Bitcoin in some way, although it could also be useful for the mining process. This is explained in the article Modern merge mining, but I also give a brief description here.
As a purely hypothetical example of such a rule, suppose that the blocks of chain X are only valid if the parent (Bitcoin) block pays 0.1 BTC to some address specified by the child blockchain state. This could be to impose some additional cost to the mining process and pay income to stakers of token X, with the miner receiving compensation in the child chain. The condition could be enforced by the protocol of X requiring an SPV proof (i.e., Merkle proof) of the payment in the parent block, which should be stored along with the AuxPOW data. This means that the information used in the AuxPOW as described in figure 5 above would be updated to something like figure 7 below. The hash values shaded yellow represent the SPV proof of the 0.1 BTC payment.
Consider the effect on the mining process. If the miner did not include such a payment in his Bitcoin block, then any child block that he produces would not be accepted by the validators of chain X. So, he needs to include this payment. However, even if he does this, it is not necessarily true that any such payment is actually made in reality. If the miner solves the POW problem for the child block then, if it has a significantly lower difficulty level than Bitcoin, it is likely that the hash will not be below Bitcoin’s difficulty threshold. Hence, he can transmit the X block to be added to the chain but, as he has not also produced a valid Bitcoin block, the 0.1 BTC payment is not made. On the other hand, if the miner does produce a hash below Bitcoin’s difficulty threshold, and he transmits this for inclusion in the Bitcoin blockchain, then the payment is made. Of course, the miner could opt to avoid the payment by not transmitting the Bitcoin block but, if he did this, then he would be giving up the block reward and would, effectively, not be mining Bitcoin at all.
We can see from the argument above, that such a cross-chain rule would not cause the 0.1 BTC payments to be made in a way corresponding deterministically to the production of blocks of chain X. Rather, payments would be made whenever Bitcoin blocks are produced by miners who are also merge mining with chain X. This is a random process, with the rate of such payments being, on average, proportional to the fraction of the Bitcoin mining hashrate which is being used to merge mine with X.
While this example is entirely hypothetical, and I am not aware of a merge mined chain using such a consensus rule, it is not difficult to imagine use cases such as allowing transactions in the child chain to trigger events on Bitcoin, effectively introducing a communication channel between the two blockchains. The article Modern merge mining does describe a very mild cross-chain rule for RSK only involving the block timestamps. See that article also for further discussion of cross-chain consensus rules and merge mining in general.
Zero Knowledge 
5 thoughts on “Merge Mining and Auxiliary Proof of Work”