[Ethereum] Invalid transaction v,r,s values with geth when reading from of signed MEW RLP transaction

go-ethereumraw-transactionrlptransactions

I generated a signed transaction with myEtherWallet:

0xf86b80847735940082520894ef5bbb9bba2e1ca69ef81b23a8727d889f3ef0a1880de0b6b3a7640000802ba06fef16c44726a102e6d55a651740636ef8aec6df3ebf009e7b0c1f29e4ac114aa057e7fbc69760b522a78bb568cfc37a58bfdcf6ea86cb8f9b550263f58074b9cc

I can convert it to a geth transaction object via:

Geth.newTransactionFromRLP(hex)

And successfully read fields like value or to – but when trying to access the from field I get an exception "Invalid transaction v,r,s values"
Is there anything I am doing wrong here – or should I report this as a bug?
Also interesting when doing transaction.encodeJSON() it also does not include the from field.
But it does not seem to be a general problem – when encoding/decoding with geth like this:

Geth.newTransactionFromRLP(transactionWithSignature.encodeRLP())

I can access the from field.

Update: Hint from Péter Szilágyi (@karalabe) on gitter:
Hmmm, one bet is that the mobile library might be using homestead signatures
and mew returning proper eip155

Best Answer

I ended up opening an issue for this and it is confirmed to be the problem @karalabe guessed it is: https://github.com/ethereum/go-ethereum/issues/14599

Will be fixed soon

In which functions do I need a transaction?

Only in that that changes values. The other you can call from a single ethereum node. This does not require spending any any ETH.

From the web3 documentation:

web3.eth.call(callObject [, defaultBlock] [, callback])

Executes a message call transaction, which is directly executed in the VM of the node, but never mined into the blockchain.

Use constant functions

To make sure that the function can be called without transactions use constant.
That would be:

   function get() constant returns (uint) { 
        return x;
    }

From Solidity doc:

constant functions can perform some action and return a value, but cannot change state (this is not yet enforced by the compiler). In other words, a constant function cannot save or update any variables within the contract or wider blockchain. These functions are called using c.someFunction(...) from geth or any other web3.js environment.

“non-constant” functions (those lacking the constant specifier) must be called with c.someMethod.sendTransaction({from:eth.accounts[x], gas: 1000000}); That is, because they can change state, they have to have a gas payment sent along to get the work done.

Do I need a function to get a value from a smart Contract when I am a full node?

It depends, public state variables have automatically a getter setter, but I prefer to do it explicitly

What happens when inc() is called with a transaction but not inserted in a Block and I read an old value? Is this an important point or can it be ignored?

Ultimately the mined block decides what ist the true history of your contract calls. So yes it does matter. Each block is like a discrete time step. Note that you can call multiple inc() in one block but the order and if they are included is not deterministic.

When do I get a/the return value? Instantly or when the transaction in placed in a block?

In the same line of argument: only if the block was mined, and to confuse you further... only if the block has been confirmed enough often to be sure this is the correct blockchain fork ;-)

[Ethereum] How to get signature parameters from a transaction

In the transaction object returned by eth_getTransaction to my geth instance does include the ECDSA parameters:

curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params": ["0x47ced780ecca7c273243dded62c6a240f3ba4332ab067345909a304d7294cfda"],"id":1}' localhost:8545

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "blockHash": "0x7126318b5736f655049fcb7c3f6ef02d0986a5553cb1b1fbc0ca188543b1e60a",
    "blockNumber": "0x339d04",
    "from": "0xea674fdde714fd979de3edf0f56aa9716b898ec8",
    "gas": "0x15f90",
    "gasPrice": "0x4a817c800",
    "hash": "0x47ced780ecca7c273243dded62c6a240f3ba4332ab067345909a304d7294cfda",
    "input": "0x",
    "nonce": "0x15dcf8",
    "to": "0xf34a762291e2578b79646cbf296abf4f5a242b3d",
    "transactionIndex": "0x0",
    "value": "0x16978c7c04171dc",
    "v": "0x26",
    "r": "0xe448b291661c63d8add23a8be2eb726e92ace5c100e902ee75a6396f8df8d221",
    "s": "0x197fb2e88dc2d4e8f606faf6abdb8012d21b024939756ceaf2d39b4bef619fa4"
  }
}

Note the v, r, and s parameters: these are what you need to verify the signature. I'm not sure why these aren't in the official RPC spec, but they are available if you need them