Gas estimation fails in MineMeToken when a transfer to involved address just happened

[3esmit]

Bug Report

I have several transaction using MiniMeToken which were gas estimated by Status but failed.

E.g.:
0x906bc15d36eeb9c82336ac5d3b1ae0a98d0dc718251a5416b3caac4c852c78ef
0x4965695158928364417cdf4f3383375d7dddf04ba665297a2a8f24ff1ed56c9e
0xf14fd7c3de48d47b2c8e25e60c12d10afb99077e28bee47f53ffdc3c5b6617fd

Problem

The correct gas estimation should have been 133404 for those transactions.

They are all failing with a gas estimation of 80882, and they only happen when I am making another transaction to same address while other transaction is pending (or just have been included).

The value 80882 didn't came from nether, it was estimated correctly based on the state at time.

Looking on MiniMeToken.sol contract, when the first transaction is submitted for gas estimation, the block number is not the current one, and at estimation this line returns true, leading to a logic that makes a new entry in the array of Balance History (more expansive).
The gas estimate returns the lower value when the latest block number touched an account involved in the transaction being estimated, in past this was not great difference, but with inclusion of EIP-1283 ethereum/EIPs#1283 this difference cause the the estimation to fail, because the line now returned false, however it will be included in a future block, so when it gets included in a block the execution will return true

When multiple transactions are done gas estimation don't fail, because the getBlockNumber will return for all the same value, the error only happens when the latest block touched a transaction and this state is used on estimation.

Example of 4 transactions in the same block, which 3 uses reduced gas:
0xcf2214474ede2b4b5ecad5ead97687777eaa97dfb6f9998c8dd1565adc54b9e3 - 1st: 111,170 gas used
0xecd768cf40dd9561010dfd05f85b3b804cda71f7dbe575f49f8f6e6c21a6528b 2nd: 67,402 gas used
0x4392d6cc1423a815747b364f93262c655797fe9e3217ca3ce79206984ce4be8b - 3rd: 67,402 gas used
0xbf0e43539b7edfc2a4454ff622e18324ae3f9a7c78cac790d305e551de72adb5 - 4th: 67,402 gas used

There is no guarantee that two transactions will happen in same block, so the reduced gas use case should never be considered for gas estimation.

Expected behavior

Gas estimation should use the future block.number (latestBlock+1). Transaction estimation ignores transactions in pending pool.

Actual behavior

Gas estimation it's using the current block number in the estimation, this is wrong, as a transaction included will always use a future block number.

Notes

This bug seems that is caused by ethereum-go, and is reported here ethereum/go-ethereum#20649.

Other wallets might be affected and should be warned about this bug on eth_estimateGas.

Acceptance Criteria

Estimate gas returns latestBlockNumber+1 at block.number OPCODE.

Reproduction

1. Create a contract which check if last changed block is current block number, if no, do a very expansive operation, if yes, do a very cheap operation & deploy it.
2. Estimate at first block & submit: success transaction/estimation
3. Estimate while the latest block is still the last change block in the contract & submit: failed transaction/estimation.

[status-github-bot]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.