1

I'm working on a more robust implemenatation for a mining pool to figure out what the actual amount was it received from a block's reward. Retrieving a block using getblock includes the miner_tx element which includes the transaction outputs. I'd like to check which if the output's key fields corresponds to the pool's wallet address but I'm a bit stuck on how to correlate the key field to the address. I realize that no correlation can be made from the address alone, but the code has access to the wallet-rpc daemon and the private view_key.

1

... actual amount was it received from a block's reward

getblock's response has the reward for the block in the responses block_header->reward field.

Pools tend to just keep track of submitted block at height and its hash. So when new blocks appear on the chain, and after 60 blocks have passed, you check to see if the block you submitted is still on the chain at the submitted height with same hash. If it is, you will have have the unlocked block reward. If it is not, some other miner/pool will have received the reward. This can happen because of a reorg (consensus leaning towards some other submitted block).

  • Well, it used to be that easy yes. But now we have Monero-derived currencies like Bittube which report one value as block-reward but split it between multiple parties (30% go to the artists). That's why a pool needs to figure the amount it wil actually receive from the coinbase outputs. – Oliver Weichhold Oct 5 '18 at 16:01
  • Before submitting, get_block_template has the expected_reward which will be the reward received if the submitted block get accepted and is not reorg'ed. I can't speak to other forks and how they may change the block/tx format. – jtgrassie Oct 5 '18 at 16:09
  • True, but this value equals the one returned from <code>getblock<code> so that doesn't help either. – Oliver Weichhold Oct 5 '18 at 17:44
  • You can know the expected reward before submitting a block from a call to get_block_template and can get the actual reward (if your block ends up on the main chain) via get_block. In Monero, you only ever have a single output (vout) for the coinbase transaction, so that vout will have the reward. A fork, could in theory create a custom miner tx that splits the reward over 2 or more vouts of the coinbase tx, but a miner/pool would also have to have a way of getting a custom block template, as the Monero daemon get_block_template only accepts one wallet as the destination for the reward. – jtgrassie Oct 5 '18 at 18:20
  • Compare this Monero Coinbase Tx with this Bittube Coinbase Tx and you will understand. You can replicate this for all blocks on both chains and the pattern will always be the same. Monero one output, Bittube has four. – Oliver Weichhold Oct 6 '18 at 6:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.