In case of the mineable transactions in tx_pool increased, and if we're resending a updated block to miner, and if a handle_submit just found the share is a new block, there's a race condition here to use the obsoleted self.current_state.current_key_id (which was used in previous block and should be reset for next mining block).
The consequence of this bug is there's possible to update a wrong coinbase output info in miner's wallet, with wrong block rewards (different fees).
For example, I saw a happening here:
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
Output Commitment MMR Index Block Height Locked Until Status Coinbase? Change? # Confirms Value Tx
=================================================================================================================================================================
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
090eb8b3fe42bd0c407f5bddd9c786523f6b7fc1589d6fe5cf1e819a9164d90f2d None 1069 1129 Mining true false 0 60.015
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
And this coinbase output in wallet suddenly change to a wrong one:
In case of the mineable transactions in
tx_pool
increased, and if we're resending a updated block to miner, and if ahandle_submit
just found the share is a new block, there's a race condition here to use the obsoletedself.current_state.current_key_id
(which was used in previous block and should be reset for next mining block).The consequence of this bug is there's possible to update a wrong coinbase output info in miner's wallet, with wrong block rewards (different fees).
For example, I saw a happening here:
And this coinbase output in wallet suddenly change to a wrong one: