Transaction dict key for data differs between getTransaction() and sendTransaction()

[veox]

• Version: 3.8.1
• Python: 3.5
• OS: Ubuntu 16.04.2 LTS

What seems wrong?

When getting a transaction that has data attached with tx = web3.eth.getTransaction(txhash), the data will be accessible via tx['input'].

When sending a transaction with data, the expected key for data is data.

So, to re-send the same transaction with an increased gas price, something like the following has to be done (in REPL):

tx = web3.eth.getTransaction(txhash)
tx['gasPrice'] = int(tx['gasPrice'] * 1.11)
tx['data'] = tx['input'] # <--------------- somewhat unexpected
web3.eth.sendTransaction(tx)

Otherwise, the transaction will have been re-created without data at all.

Many of the other keys are quite similar - is there a reason for this "mismatch"?

A solemn monkey

Source: /u/squamuglia @ /r/aww

[carver]

Note that this same problem exists directly in geth attach, so this would be papering over geth's issue. I haven't tested if it also happens in parity, etc.

[veox]

Ah!

@pipermerriam: If this should be taken upstream, perhaps you know where "upstream" is? go-ethereum? Both that and parity? The EIP community?..

[pipermerriam]

Yes, I would consider this an upstream bug as both of these methods conform to the JSON-RPC spec.

[pipermerriam]

It's not a trivial EIP to create, but having a formal agreed upon RPC spec that the clients could test against would be really powerful. I know @FlySwatter (Dan Finlay) was working on something like this at one point but I don't know what the progress was.

[danfinlay]

You refer to EipSignal, which proposes using a DAO to manage a public compatibility table whose test spec format is up for discussion in eip 217.

I largely passed off the creation of that DAO to the Boardroom team for the moment, because they had some of the required pieces in place, but will hopefully have some fresh time to get back on that soon, because I see a lot of these incompatibilities popping up.

In the meanwhile, feel free to chime in on that spec format, it hasn't gotten much actionable response.