TLDR
It’s a known vulnerability that Iron Fish allow blocks with timestamps that are earlier than timestamps from previous block. Miners are incentivized to exploit it by manipulating the block timestamps to consistently gain more mining rewards. I propose to update the block header verification in consensus layer to only allow blocks with timestamps that are greater than their previous block timestamp
Terminology
-
Block header timestamp: timestamp according to the miner who mined the block. The timestamp is in millisecond. Miners must verify that it is an appropriate distance to the previous blocks timestamp.
-
Block mine time: This is calculated by the interval of current block timestamp from the previous block timestamp. When the timestamp of the current block header is earlier than the timestamp of previous block, it will result in negative block mine time.
Problems
There are speculation among miners that negative block mine time can potentially manipulate the mining difficulty. People believe that the ability to create a block with negative mine time gives these miners an edge in a “tie-breaking” scenario since making the timestamp low enough might increase the block’s mining difficulty. Miners are incentivized to set the timestamp as early as possible to gain the system with possible more mining rewards.
This negative mine time in the block header causes confusing for users. For example, in Iron Fish block explorer, It will cause negative duration for ‘Mined In’ column in The Iron Fish block explorer. The same issue exists for the Oreoscan. In Iron Fish CLI, it also use the block timestamp to display the time a transaction occurred in wallet:transactions, this led to less reliable creation time for transaction.
Proposed Changes
I propose following changes in the consensus layer to address the problems
- Only allow block header with a timestamp greater than the timestamp of the previous block.
- The block header verification in the consensus will check if the block timestamp > the timestamp of the previous block.
- Support backward compatibility. For all the existing blocks with negative timestamp, they are still valid and not affected by the new rule.
- Enforce the new rule based on the block sequence to achieve backward compatible
Advantage
- Prevent mining pools to potentially cheat the system by manipulating the block timestamp
- Have reasonable values for block mine time
- Have more reliable creation times for transactions in a block
Potential Impact on Mining Manager
For mining pools that is not using the official mining manager, the logic that sets the timestamp in a new block template will need to be updated to comply the new consensus rule.
For the official mining manager in the SDK, it will change the way it sets the timestamp in a new block template before the new rule rolls out.
Hard Fork
This change would require hard fork since it change the consensus. A block with negative mine time that is considered valid before the soft fork activates will be considered invalid after the hard fork activates.
