# Merge-Mining Feasiblity **URL:** https://forum.hypercore.one/t/merge-mining-feasiblity/381 **Category:** Development **Created:** [February 26, 2024, 12:51pm UTC](https://forum.hypercore.one/t/merge-mining-feasiblity/381 "2024-02-26T12:51:05Z") **Posts on this page:** 1 **Showing post:** 1
### Author: ![MoonBaze](https://forum.hypercore.one/letter_avatar_proxy/v4/letter/m/f04885/32.png) [@MoonBaze](https://forum.hypercore.one/u/MoonBaze) #### Post date: [February 26, 2024, 12:51pm UTC](https://forum.hypercore.one/t/merge-mining-feasiblity/381/1 "2024-02-26T12:51:05Z")
To delve right into the topic, merge mining is the concept of mining 2 different chains at once, without splitting the processing power, while only looking for one nonce because the block templates are the same. The only difference is the difficulty. The main blockchain, in our case Bitcoin, will have the main net difficulty and the other chain (share chain) that will be implemented into an embedded will have a lower difficulty. Once in a while, when a miner finds a good nonce ( solution / share ) for the share chain, the resulting hash will also be good for the Bitcoin main net, that block will be broadcasted and accepted by the network. And so, we mined 2 blocks for 2 networks in the same time. How can this concept be implemented on Zenon Network? We will need 3 main components: Embedded Contract, Miners, Hauler ( Proxy between them ) 1. Embedded Contract with the following roles: - Maintain a list of Bitcoin block headers. This is needed so that the hauler can use this as source of reference when creating the block template. Creating a block template requires the following fields: 1. **version** - This 4-byte little endian field indicates the version of the Bitcoin protocol under which the node is publishing the block. 2. **hashPrevBlock** - This 32-byte little endian field is the double SHA256 hash of the previous block header. This forms the edge of the previous block that joins it to the blockchain DAG. 3. **hashMerkleRoot** - This 32-byte little endian field represents the Merkle root of the Merkle tree that contains the transactions which are timestamped in the block. 4. **time** - This 4-byte field is the Unix epoch timestamp that is applied to all transactions in the block. Current network policy only requires this value to be accurate within 2 hours of the validating nodes’ local timestamp. The timestamp has 1-second precision. 5. **bits** - This 4-byte field yields the difficulty target value of the proof-of-work) puzzle, as determined by the network rules. 6. **nonce** - This stands for ‘number used once’. The values of this 4-byte field are cycled through to modulate the block header. The hash of the header is then checked against the difficulty target. Nodes provide adequate information such that when all 4.3 billion values of a nonce have been tried, they can modulate the input field in the block’s coinbase transaction and recalculate the Merkle root. This changes the serialized string of the block header, giving another 4.3 billion unique nonce values to iterate in their search for a hash puzzle solution under the difficulty target. Knowing this, the constant values will be version, hashPrevBlock, bits, time and can be fetched from the embedded. The variable ones are nonce ( which will be submitted when providing the share) and the merkle root hash. Here it is a little bit tricky. This hash can be constructed from the hashes of all the transactions that will be included in the block, in a particular order, including the coinbase one ( in our case it need to have the destination address the TSS address, or whatever we use to hold the coins ). When a miner is submitting a share, we need to prove that the merkle root hash is constructed from a list of transactions that contains the correct coinbase transaction ( that has TSS address as destination ). The only way to prove this is to reconstruct all the hashes that lead to the merkle root. The most trivial way is to send all transactions when sending the share so the embedded can reconstruct and check it. We cannot do that as that would mean each miner would send every few minutes ( 2500 hashes \* 32 bytes ). What we could do, as we only care about the coinbase transaction is this: send only the hashes needed (the ones in red squares) to reconstruct the root using only the coinbase transaction ( which must be known by the embedded ) . ![image](https://hypercore.nyc3.digitaloceanspaces.com/original/1X/62f0b1d6dbca685fe8513c09af4f35d5614bd7e6.jpeg) This way each share would contain log 2 of n hashes, where n is the number of transactions in a Bitcoin block. log 2 of 4096 is 12. Let’s upper bound this to 13 maybe, we would have 13 \* 32 bytes which is a lot less for now. I will think of other ways we could still optimize this in terms of chain space and I also ask you to come with new ideas on how to validate that a share ( constant values + nonce + merkle root) contains the correct coinbase transaction. Also, the randomness space comes from nonce, and the input field of the coinbase transaction (4 more bytes). So we could accept every coinbase transaction as long as the destination address and amount is correct. Maybe we could have more TSS addresses, so more randomness space for miners and accept any (just an idea). Here we also need a mechanism on the correctness of the Bitcoin header blockchain. We could have a committee where every member would send a transaction specifying which one is the next block header ( when a new Bitcoin block is mined ) and the one with a majority is cemented. This leads to space overhead in time. One other option would be to have an algorithm that decides which member should post the next header and if others believe it is wrong or he does not post, they could intervene. - Maintain a database of each share submitted for the share chain We need to track how many correct shares each miner sent so that we could incentivize them. - Maintain a difficulty and block time logic The same mechanism as Bitcoin’s so share chain has a block time of 2-3 minutes. This is just an example, the topic open for debate, higher time means lower space for our chain as less shares would be sent. - Algorithm to pay the miners Each miner would be paid based on how many shares he sent in an epoch and the total number of shares from that epoch. They will be paid in ZNN and (why not ?) BTC ( as ZTS or some way, after we actually mine a block, just an idea for now). Here we need to discuss where to get the ZNN from. We could decrease the percentages of rewards from other contracts (Pillars, Sentinels, LP providers) - In the future we could have 2 share chains, one for small miners like CPU and one for ASICs or Graphics Card. 1. Hauler ( I came up with this name as it is a very important component on actual physical mining and it is used to transport almost everything to and from the mine ) Its role is to gather information about Bitcoin mempool, Embedded latest block header and coinbase transaction template, send jobs to the miner, send shares to the Embedded and broadcast a valid Bitcoin block if found. It needs a connection a Zenon node, it needs a connection to a Bitcoin full node so he knows the mempool and can construct a valid mining job (using the transactions) for the miner. It needs to handle multiple miners and know how to distribute jobs so that no redundant work is done ( a nonce is not tried twice by two different miners ) **Very important note** , every hardware owner should run its own hauler as connecting to any other ones, means that the jobs received could be tampered with and the coinbase transaction would be different. ( You could mine for them actually, even if only a percent of the jobs are tampered ) 2. Miner Every miner that is compatible with the Stratum protocol can merge mine! ⛏⚒⛏ It just needs a connection to a Hauler. This post shows that implementing merge mining on the Zenon Network is feasible, we still need to discuss the details on the topics that I’ve mentioned. Also, any other ideas, complaints, optimizations about my view are very welcomed! I hope I did not miss any information, but will edit the post if so, and will gladly answer questions. --- _[View the full topic](https://forum.hypercore.one/t/merge-mining-feasiblity/381)._