Here are the steps needed to add RSK merged mining capabilities to mining pool software.
Add the RSK merged mining information in Bitcoin block as a commitment, the complete steps are as follow:
Use the mnr_getWork method from the RSK node’s JSON-RPC API. This method returns the information of the current block for merged mining, the boundary condition to be met (“target”), and some other data.
0x29and represents the length of the information included after the
RSKBLOCK:is the ascii string for
RskBlockInfois the block information in binary format.
For example, if
the merged mining information is
Include as the last output of Bitcoin coinbase transaction.
RskBlockInfo, up to the end of the coinbase transaction must be lower than or equal to 128 bytes.
RSKBLOCK:tag may appear by chance or maliciously in the
ExtraNonce2data 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
RSK average block time is 30 seconds which is faster than Bitcoin 10 minutes. This fact triggers the following implementation changes:
mining.notifymessage, from stratum protocol, every time new RSK work is received.
Use the mnr_submitBitcoinBlockPartialMerkle method from RSK node’s JSON-RPC API. That method is the optimal in performance and preferred among others available. Other submission methods and information about the pros and cons between them can be found in the Mining JSON-RPC API documentation.
As a result of RSK’s implementation of merged mining, the Bitcoin network does not get filled up with merged mining information. Only a minimal amount of information is stored: An extra output on the coinbase transaction.
Furthermore, no changes are required on Bitcoin node to support merged mining with RSK.