eth_estimateGas - Requires higher than upper limit of X

[edevil]

Before filing a new issue, please provide the following information.

I'm running:

• Which Parity version?: 1.9.7 AND 1.10.4
• Which operating system?: Linux
• How installed?: Docker
• Are you fully synchronized?: yes (private chain from scratch)
• Which network are you connected to?: private PoA chain
• Did you try to restart the node?: yes

Your issue description goes here below. Try to include actual vs. expected behavior and steps to reproduce the issue.

I have deployed a contract based on OpenZeppelin's MintableToken and HasNoEther, and I can mint tokens with no problems using a Ganache test node. However, when I do the same against a parity node I get an error when calling eth_estimateGas for a simple mint operation:

actual

POST / HTTP/1.1
Host: 127.0.0.1:8545
User-Agent: Web3.py/4.2.1/<class 'web3.providers.rpc.HTTPProvider'>
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Type: application/json
Content-Length: 273

{"jsonrpc": "2.0", "method": "eth_estimateGas", "params": [{"to": "0xafF2e125054693758CB14fD7Ee03c4a8800aaAAA", "data": "0x40c10f19000000000000000000000000c33ced9f1d89e51abee70840303c403e5950925b000000000000000000000000000000000000000000000000000000000000000a"}], "id": 19}

HTTP/1.1 200 OK
Content-Type: application/json
Transfer-Encoding: chunked
Date: Mon, 21 May 2018 15:37:34 GMT

A2
{"jsonrpc":"2.0","error":{"code":-32015,"message":"Transaction execution error.","data":"Internal(\"Requires higher than upper limit of 59591043530\")"},"id":19}

0

expected (Ganache)

POST / HTTP/1.1
Host: 127.0.0.1:7545
User-Agent: Web3.py/4.2.1/<class 'web3.providers.rpc.HTTPProvider'>
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Type: application/json
Content-Length: 272

{"jsonrpc": "2.0", "method": "eth_estimateGas", "params": [{"to": "0xb376b6E94a88A1138876F8D497329655B0e04DAc", "data": "0x40c10f19000000000000000000000000bc2f1789c954d9c27201af56090ca934688fdc440000000000000000000000000000000000000000000000000000000000000001"}], "id": 4}

HTTP/1.1 200 OK
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: *
Content-Type: application/json
Date: Mon, 21 May 2018 16:20:29 GMT
Connection: keep-alive
Transfer-Encoding: chunked

2a
{"id":4,"jsonrpc":"2.0","result":"0x9472"}
0

notes

If I issue a transaction for the mint operation and send gas value of "4700000", the transaction is mined, so the problem only happens when calling eth_estimateGas.

POST / HTTP/1.1
Host: 127.0.0.1:8545
User-Agent: Web3.py/4.2.1/<class 'web3.providers.rpc.HTTPProvider'>
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Type: application/json
Content-Length: 415

{"jsonrpc": "2.0", "method": "eth_sendRawTransaction", "params": ["0xf8a501808347b76094aff2e125054693758cb14fd7ee03c4a8800aaaaa80b84440c10f19000000000000000000000000bc2f1789c954d9c27201af56090ca934688fdc4400000000000000000000000000000000000000000000000000000000000000011ca04cb8f23bf613037b3ff945b97189a0884be48fb5f491344e734a26d0400874f3a053a2aae872b62beb1687afd1f9fd8cab591c8ba849c5dae43149b859349c5b28"], "id": 7}

HTTP/1.1 200 OK
Content-Type: application/json
Transfer-Encoding: chunked
Date: Mon, 21 May 2018 15:42:54 GMT

67
{"jsonrpc":"2.0","result":"0xd6d6acaec97a751be7cb00ad460a39d85b2e78643f88d4c8b5952378def54bba","id":7}

0

[iFA88]

I have Parity/v1.11.1-beta-6654d0216-20180515/x86_64-linux-gnu/rustc1.25.0 and Parity/v1.9.5-stable-ff821daf1-20180321/x86_64-linux-gnu/rustc1.24.1, my results are twice:

eth_estimateGas({"to": "0xafF2e125054693758CB14fD7Ee03c4a8800aaAAA", "data": "0x40c10f19000000000000000000000000c33ced9f1d89e51abee70840303c403e5950925b000000000000000000000000000000000000000000000000000000000000000a"})
"0x5958"

[edevil]

@iFA88 I just tried with the v1.11.1 docker image and got:

ValueError: {'code': -32015, 'message': 'Transaction execution error.', 'data': 'Internal("Requires higher than upper limit of 13708807590")'}

[dvdplm]

@edevil Can you try the same RPC call against parity running against a different chain, e.g. parity --chain testnet? Also, can you post the full command line invocation you use to start parity on your private chain? Thanks!

[edevil]

Sorry guys, forgot about this issue.

So I tried in Kovan, the contract has address 0xafF2e125054693758CB14fD7Ee03c4a8800aaAAA and got the same error:
ValueError: {'code': -32015, 'message': 'Transaction execution error.', 'data': 'Internal("Requires higher than upper limit of 79921890")'}

I used parity 1.10.7 and started it with parity --chain testnet. @dvdplm

[ferrouswheel]

Not sure if it's relevant or helps investigation, but I ended up getting the same error:

ValueError: {'code': -32015, 'message': 'Transaction execution error.', 'data': 'Internal("Requires higher than upper limit of 79921890")'}

when using the wrong identity to call a smart contract.

As I understand it, for the contract I was working with, this would cause a VM exception. Perhaps this is a misreporting of VM exceptions while estimating gas? (I don't really know how that process works, so sorry if that suggestion doesn't make sense)

After switching to the correct identity I no longer got the error.

[comodoro]

I have encountered probably this, Transaction execution error on estimateGas(), with parity --mode offline --config dev --gasprice 0 --force-sealing --reseal-min-period 3000 -l DEBUG --unlock 0x00a329c0648769a73afac7f9381e08fb43dbea72 --password pwd there is quite a lot of logs, but relevant seems to be this:

2018-07-10 20:57:13   DEBUG trace  Traced failed call FlatTrace { action: Call(Call { from: 0000000000000000000000000000000000000000, to: bb0eaa2ac4753b686c399706e4752829a5124073, value: 0, gas: 5309445, input: [218, 155, 198, 236, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 64, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], call_type: Call }), result: FailedCall(Reverted), subtraces: 0, trace_address: [] }
2018-07-10 20:57:13   DEBUG trace  Traced failed call FlatTrace { action: Call(Call { from: 0000000000000000000000000000000000000000, to: bb0eaa2ac4753b686c399706e4752829a5124073, value: 0, gas: 5309445, input: [218, 155, 198, 236, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 64, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], call_type: Call }), result: FailedCall(Reverted), subtraces: 0, trace_address: [] }
2018-07-10 20:57:13   DEBUG rpc  Response: {"jsonrpc":"2.0","result":true,"id":39}.
2018-07-10 20:57:13   DEBUG pubsub  Adding subscription id=Id(04c801ee57537930)
2018-07-10 20:57:13   DEBUG trace  Traced failed call FlatTrace { action: Call(Call { from: 0000000000000000000000000000000000000000, to: bb0eaa2ac4753b686c399706e4752829a5124073, value: 0, gas: 53289930, input: [218, 155, 198, 236, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 64, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], call_type: Call }), result: FailedCall(Reverted), subtraces: 0, trace_address: [] }
2018-07-10 20:57:13   DEBUG trace  Traced failed call FlatTrace { action: Call(Call { from: 0000000000000000000000000000000000000000, to: bb0eaa2ac4753b686c399706e4752829a5124073, value: 0, gas: 53289930, input: [218, 155, 198, 236, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 64, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], call_type: Call }), result: FailedCall(Reverted), subtraces: 0, trace_address: [] }
2018-07-10 20:57:13   DEBUG tokio_core::reactor  loop process - 4 events, Duration { secs: 0, nanos: 20505530 }
2018-07-10 20:57:13   DEBUG pubsub  Adding subscription id=Id(37a26954726e357f)
2018-07-10 20:57:13   DEBUG rpc  [Some(Num(40))] Took 16ms
2018-07-10 20:57:13   DEBUG rpc  [Some(Num(41))] Took 15ms
2018-07-10 20:57:13   DEBUG tokio_core::reactor  loop poll - Duration { secs: 0, nanos: 5470 }
2018-07-10 20:57:13   DEBUG tokio_core::reactor  loop time - Instant { t: 1532749707594 }
2018-07-10 20:57:13   DEBUG tokio_core::reactor  consuming notification queue
2018-07-10 20:57:13   DEBUG tokio_core::reactor  loop process - 1 events, Duration { secs: 0, nanos: 2977915 }
2018-07-10 20:57:13   DEBUG tokio_core::reactor  loop poll - Duration { secs: 0, nanos: 9846 }
2018-07-10 20:57:13   DEBUG tokio_core::reactor  loop time - Instant { t: 1532749735867 }
2018-07-10 20:57:13   DEBUG rpc  Response: {"jsonrpc":"2.0","error":{"code":-32015,"message":"Transaction execution error.","data":"Internal(\"Requires higher than upper limit of 53311650\")"},"id":40}.
2018-07-10 20:57:13   DEBUG rpc  Response: {"jsonrpc":"2.0","error":{"code":-32015,"message":"Transaction execution error.","data":"Internal(\"Requires higher than upper limit of 53311650\")"},"id":41}.
2018-07-10 20:57:13   DEBUG rpc  Response: {"jsonrpc":"2.0","result":[],"id":42}.
2018-07-10 20:57:13   DEBUG rpc  Response: {"jsonrpc":"2.0","result":"0x04c801ee57537930","id":43}.
2018-07-10 20:57:13   DEBUG rpc  Response: {"jsonrpc":"2.0","result":[],"id":44}.
2018-07-10 20:57:13   DEBUG rpc  Response: {"jsonrpc":"2.0","result":"0x37a26954726e357f","id":45}.

In web3.js there is gas estimation before calling the particular contract, which fails with Parity. Note that the code works with Geth 1.8.11 started as geth --dev --nodiscover --maxpeers 0 --ws --wsorigins="*". The options --force-sealing --reseal-min-period 3000 actually do not matter, they were attempts to debug the issue.

[vn-linescode]

In which version was this issue fixed?

[debris]

only master

[vn-linescode]

I still have the issue.