Merged Mining

Merged mining is the process that allows RSK blockchain to be mined simultaneously with Bitcoin blockchain. This can be done because both chains use the same PoW algorithm (double SHA-256).

How it works?

Bitcoin mining pools include a reference to RSK's block in every mining job they deliver to miners. Everytime miners find a solution, it is compared to both networks difficulties (Bitcoin and RSK) delivering three possible outcomes:

• Solution satisfies Bitcoin network difficulty. Hence, a block is assembled and sent to the network. RSK's merged mining reference will be included and ignored by Bitcoin network. Since RSK's network difficulty is lower than Bitcoin, this solution will also work for RSK and can be submitted to the network.
• Solution does not satisfies Bitcoin network difficulty but does satisfy RSK network difficulty. As a consequence, solution will be submitted to RSK network and not to Bitcoin network.
• Solution only satisfies pool difficulty (which is many times lower than Bitcoin or RSK network difficulty) and it is not submitted to any network.

Solution submitted to RSK allows the node to build an SPV proof. If the proof is valid, it is included as part of the block that will be sent to the network.

What are the benefits?

Miners earns a high percentage of transaction fees from the RSK block they mine. This mining process is done with the same hashing power used in Bitcoin mining and has no additional cost or impact.

What's the current RSK network hashing power?

You can see RSK network hashing power in our Stats Website.

Implementation details for mining software pools

RSK node provides a dedicated Mining JSON-RPC API that is exposed for interaction with mining pools. Methods from that API will be referenced in the next sections of this document.

RSK work retrieval

Mining pools can retrieve new work by using the mnr_getWork method.

RSK reference in Bitcoin blocks

Format

RSKBLOCK: (ascii string for 52 53 4b 42 4c 4f 43 4b 3a) + RskBlockHash (in binary format) that wants to be used for merged mining. For example: 52534b424c4f434b3ae5aad3b6b9dc71a3eb98a069bd29ca32211aee8b03fd462f4ffbbe97cc75a174 assuming the blockhash is e5aad3b6b9dc71a3eb98a069bd29ca32211aee8b03fd462f4ffbbe97cc75a174

Position

Include as the last output of Bitcoin coinbase transaction.

Restrictions

• The number of bytes immediately after RskBlockHash, up to the end of the coinbase transaction must be lower than or equal to 128 bytes.
• The trail raw bytes must not contain the binary string RSKBLOCK:
• The probability of the RSK tag to appear by chance is negligible, but pool servers must not rule out the possibility of a rogue Bitcoin address included in the coinbase transaction having this pattern, and being used as an attack to break the validity of merged mining header.
• The RSKBLOCK: tag may appear by chance or maliciously in the ExtraNonce2 data field that is provided by miners as part of the Stratum protocol. This is not a problem as long as the poolserver adds the RSKBLOCK: tag after the ExtraNonce2 chunk.

Note that Bitcoin network will only have this tiny information and does not gets junked up with merged mining stuff. Also, no changes are required on Bitcoin to support merged mining.

RSK solution submission

Mining pools can submit solutions using any of the available methods on the mining API. mnr_submitBitcoinBlockPartialMerkle is suggested to be used since is the optimal one. More information about the pros and cons between different solution submission methods can be found in the Mining API documentation.