Block Mining Fees Information Mechanism Discussion

[SergioDemianLerner]

SubmitBitcoinBlock method

Mining RPC interface exposes a method called "mnr_submitBitcoinBlock" which receives a Bitcoin block in hex and returns error only if there was an exception in processing the request. Having only that info in the response, miners do not know if the block was accepted or rejected by the RSK node. Note that we are talking about a block being accepted by the RSK node which says nothing about the block being accepted by the RSK network. That will depend on network consensus.

Therefore, there is a need for providing more information in "mnr_submitBitcoinBlock" response.

Information log

REMASC contract calculates the fees earned by the miner of every block and updates the miner balance. No transactions are made for this payment and that is why there is no record of this in the blockchain. With only that information it is not possible to deduce which fees were paid for a certain block.

Therefore, there is a need to log information to later determine the address and the amount of fees paid on every block.

Interface for miners

Miners need to know the reward they earn for each block they mine.

One possible solution (1) is to expose a method in the mnr interface named "getFeesInfoForMinedBlocks". The method will have no parameters and should return the fees information for all matured (NOTE: Maturity is defined as the number of blocks that should be mined in order to pay mining rewards. At the time of this writing, this value is set to 50 blocks in RSK mainnet and it’s supposed to be changed to 1000 before mainnet deploy.
) blocks since it was last called. Notice that this method will only return the fees information for a block only once. The idea behind this method is that it will be poll every “x” minutes by fee management software of the miners.

As a backup method for cases when an error occur in the "getFeesInfoForMinedBlocks" miners should also be able to ask for the fees of a certain block. A method called “addBlockForFeesInfo” will receive a blockhash and height and will add that block to the next query done by “getFeesInfoForMinedBlocks” method. This backup method will also be part of the mnr interface.

Another possible solution (2) is to create a dedicated software that will expose an API with two methods. One of them should be "getFeesInfoForMinedBlocks" (same as described in (1)) and the other should be a method called “getBlockFeesInfo” that will receive a list of pairs (blockhash, height) and will return the fees paid for each pair input. This second method will replace the backup method presented in proposal (1). This new piece of software will get the information from RSK node existing JSON-RPC methods.

After presenting proposals (1) and (2) it arise another possible solution (3) which basically is a merge of both. Methods exposed for retrieving fees information should be implemented as part of the mnr interface while the fees information can be obtained using the JSON-RPC methods as suggested in (2). In this case, JSON-RPC methods will be directly called from Java.

The benefit of proposal (2) is that code will not be added to the RSK node because it will use JSON-RPC methods that already exists to retrieve the required information. The problem with using this methods is that they will not have the best performance for the use case being attacked. That is because JSON-RPC methods iterate over all the transactions of a block when filtering while the only transaction that should be checked is the REMASC transaction and it’s located in a known index of the block’s transactions.

Benefits of proposal (1) is that miners will have to interact with only one piece of software, RSK node, which they already have set up. In proposal (2), miners will need to install the API in order to do the calls. Also proposal (1), if implemented as suggested in the next section of this document, can have the best performance for searching.

Proposal (3) reuses existing code while adding the minimum extra code to RSK node in order to provide the desired functionality. The only drawback is that it is still adding code to the RSK node that will not be used in most of the full node use cases.