Gas limit intermittently set too high

[danfinlay]

Josh from FunFair writes:

not sure what's happened on your latest release but we currently do not send gas estimates to you and you guys normally work it out. We seen today Gas limit are intermittently getting set much too high then they should by you guys. Gas limit should of been around 350,000 for that transaction... not sure if you know any issues on the latest release for you guys?

this shows its getting it correct and then wrong at the same time as well.

We estimate our gas limit from a combination of sources:

• We call eth_estimateGas for the currently connected RPC
• We fudge the number up 10% to account for gas refunds mid-transaction.

The first question I have here is: Is this inaccuracy coming from Geth or our own internal 10% addition? (Guide to opening the background inspector here should make it easy to view Network and see if the RPC node is returning a bad number).

Did we recently adjust gas estimation?

What RPC node is Josh connected to?

[danfinlay]

Would also help to know the transaction that Josh is attempting (this could come from a contract whose internal state is changing often, affecting the actual gas price). If the bad estimateGas call can be found in the background Network tab, you can right-click it and "Copy as cURL", which is the perfect content for helping debug geth issues.

[joshstevens19]

Answering a few questions to add some more context to this:

• Network tested was on Rinkeby and Mainnet default MM nodes so infura nodes which means Geth nodes, this happened on both but as I said it's a intermittent issue.
• If we estimate the gas using web3 (web3.eth.estimateGas) which hits the node and does a JSONRPC call to get the gas estimates it returns the correct estimate gas prices and is not returning any errors, If we then push the estimates through (contract calls we add 10% onto the gas number from the nodes) when sending the transaction MM works fine and everything is good.
• This happened on a contract call for us when we open a fate channel (start a game), this can be recreated if you go to https://showcase.funfair.io/ and play with Rinkeby which would allow you to debug the background for MetaMask to see all the information you need.

[joshstevens19]

i also see other gas related issues reported a few days ago - #6772 - so i'm guessing something has changed your end around gas estimates.

[ohopton]

You can also check some historical transactions here:

https://etherscan.io/address/0x8f19f89675422fa420a56a3e20b2e8c8cb295c71

These are transactions which open a fate channel (our state channels). You can see our users are hitting the same issue where transactions are being submitted with a very high gas limit which makes it unlikely they will get mined. The failed transactions are where they have been mined, but it took too long (we have an expiry in the transaction).

Those transactions normally uses around 220,000 gas, certainly never as much as 6.5m.

[ohopton]

Here's a quick screen grab showing the result of the eth_estimateGas call. The result looks right at 206,006.

[danfinlay]

Thanks for the reports, we've been investigating this, and we were unable to reproduce the issue once we tested on our latest develop build.

This build includes an improvement to how we validate and normalize transaction parameters, and it seems it may have fixed this issue.

Could someone experiencing this problem please try downloading one of our automated builds of this new release candidate, and see if you still experience the issue?

[joshstevens19]

@danfinlay Thanks for being so responsive to this. We had to fix this as a critical bug and deploy it to live yesterday, so we now pass our gas limits estimates within the transactions and works fine. That means I can't really test if your new build works or not anymore without reverting the commits in our dev environment which i don't fancy doing, I guess if you could repeat this bug on the old release and then not repeat it in the latest develop builds then that's enough for me to think it has been solved. 👍

[danfinlay]

We have a new build that we're more confident fixes this issue, we'll be deploying it soon, anyone who'd like to check if they can repeat the issue can try it here:
#6786 (comment)

[danfinlay]

Should be fixed in 6.7.2, which is rolling out via auto-update to all Chrome and Firefox users now.

[Gudahtt]

Closing, as this should be fixed by #6786