Description

Currently, the out of gas error displays a slightly higher number than what the user inputted for -gas-wanted. Logically, the user then bumps the gas to a number somewhat above what the error gave back, having the transaction fail once again.

This happens because the amount of ugnot given by this error is not "how much this tx should cost", it's "how much gas was used before it ran out" - which makes zero sense from a UX standpoint. h/t to @thehowl for explaining this.

Ideally, we should estimate gas for the user up front, prompting the user a slow, normal, and fast option, which would suggest values that the user can choose for gas. Then, if an out of gas error happens, the user should get an estimate of how much gas should be given to the transaction in the next try (+5%, say).

Related: #3330