RPC sendTransaction (without specified from address): could not unlock sender account

[jorisbontje]

Running ethereum develop 0b8f66e with:

ethereum -mine=true -rpc=true -rpcport=8080 --unlock=0x0b30af04d96bfb672de96d3b25e30b4eb9ff3ed0:bla

When calling web.eth.sendTransaction without specifying a from address:

{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{"gas":"0x30d40","value":"0x4563918244f40000","to":"0xa4a32f03650491ab977b6923864be50efc242a20","data":"0x26638a380000000000000000000000000000000000000000000000000000000000000005","gasPrice":"0x0"}],"id":22}

This results in the following RPC error:

{
    "id": 22,
    "jsonrpc": "2.0",
    "error": {
        "code": -32603,
        "message": "could not unlock sender account"
    }
}

Error in CLI console:

err: could not unlock sender account

I would expect that sendTransaction would have access to the unlocked account 0x0b30af04d96bfb672de96d3b25e30b4eb9ff3ed0 and use that by default. Or that the from address for sendTransaction would be mandatory.

[fjl]

from is mandatory.

[fjl]

We need to change that in the RPC API so it returns the right error.

[ethers]

I specify the "from":

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{"from":"0x32ad27653e4df5d81728d16d8e251fee34f53d30", "gas":"0x30d40","value":"0x4563918244f40000","to":"0xa4a32f03650491ab977b6923864be50efc242a20","data":"0x26638a380000000000000000000000000000000000000000000000000000000000000005","gasPrice":"0x0"}],"id":1}' http://localhost:8080

I get an address that is too long:

{
    "id": 1,
    "jsonrpc": "2.0",
    "result": "0x2d5525aebc243630e165d4f44c4cfb77e69b673e832fa77be2745d917ee00121"
}                                                                              

Is it a separate issue?

[tgerring]

It looks like the result of that call is returning a transaction hash.(

go-ethereum/xeth/xeth.go

Lines 373 to 376 in fe819f3

	if types.IsContractAddr(to) {
	return toHex(core.AddressFromMessage(tx)), nil
	}
	return toHex(tx.Hash()), nil

)

Types is currently being refactored, so the underlying code this uses will change and I expect at least a slight refactor of RPC to use the updated functions will result in simpler and "more correct" RPC calls

[ethers]

thanks @tgerring tx hash is actually helpful (will even become more common than creating contracts)