Invoke an issuehunter contract function from the RPC listener

[bugant]

This can be done by creating a new transaction that includes the correct data.

Example

curl -X POST --data '{
  "jsonrpc": "2.0",
  "method": "eth_sendTransaction",
  "params": [
    {
      "from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155",
      "to": "0xb2b2084de341e560da3d439ef5e5309d78a22a66",
      "data": "0x38b1e41868747470733a2f2f6769742e696f2f76356c33740000000000000000000000000000000000000000000000002dfbd363bf80097c24fa063730d0daace296533e3330353761653262316436303532633634343939616163393038303161373936"
    }
  ],
  "id": 1
}' http://localhost:8545 | jq .

Params:

• from - the issue manager account, note: it must be unlocked
• to - the contract address
• data - the hash of the invoked method signature and encoded parameters

Notes

Transaction data

In a transaction data the first four bytes of the call data for a function
call specifies the function to be called. It is the first (left, high-order in
big-endian) four bytes of the Keccak (SHA-3) hash of the signature of the
function.

The signature is defined as the canonical expression of the basic prototype,
i.e. the function name with the parenthesised list of parameter types. Parameter
types are split by a single comma - no spaces are used.

See the Function
Selector
section of Ethereum Contract ABI wiki page.

Example transaction data

The example transaction included the data:

0x38b1e41868747470733a2f2f6769742e696f2f76356c33740000000000000000000000000000000000000000000000002dfbd363bf80097c24fa063730d0daace296533e3330353761653262316436303532633634343939616163393038303161373936

The first four bytes are 0x38b1e418, are the first four bytes of the hash of
the verifyResolution function signature, that is
verifyResolution(bytes32,address,bytes32).

In a geth console:

> web3.sha3('verifyResolution(bytes32,address,bytes32)')
"0xb4c0d9ccc5ceea478a0039f7a0cd6eb1769b2f13ccbaa3e6374b85dead0d7556"

The remaining data

68747470733a2f2f6769742e696f2f76356c3374000000000000000000000000
0000000000000000000000002dfbd363bf80097c24fa063730d0daace296533e
3330353761653262316436303532633634343939616163393038303161373936

is the hexadecimal representation of:

• issueId
• resolutor address
• commitSHA

They're padded on the lower-order (right) side with zero-bytes such that the
length is 32 bytes in the byte32 case, or padded on the higher-order (left)
side with zero-bytes such that the length is a multiple of 32 bytes in the
address case.

In a geth console:

> web3.toAscii('68747470733a2f2f6769742e696f2f76356c3374000000000000000000000000')
"https://git.io/v5l3t\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"

> web3.toAscii('3330353761653262316436303532633634343939616163393038303161373936')
"3057ae2b1d6052c64499aac90801a796"

Decoded params:

• issueId: https://git.io/v5l3t
• resolutor: 0x2dfbd363bf80097c24fa063730d0daace296533e
• commitSHA: 3057ae2b1d6052c64499aac90801a796

Resources:

• https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI
• https://github.com/ethereum/wiki/wiki/JavaScript-API#web3tohex
• https://github.com/ethereum/wiki/wiki/JavaScript-API#web3toascii

Gas and gas price

There are two optional parameters that have been omitted from the example
request: gas and gasPrice.

The default gas value is 90000 and is just enough to send a "verify patch"
transaction. The last time I tested it I spent 88971 gas.

Gas price, if omitted, is going to be determined based on the mean gas price at
the time the transaction is sent. I think that's ok for now, but we should
create a new issue to make the gas price variable according to the patch
submission fee.

Unlocking an account

The from account must me unlocked in order to be able to sign (and send) the
transaction. To unlock an account there's a Management API's
personal_unlockaccount
function that can be used.

Example

curl -X POST --data '{
  "jsonrpc": "2.0",
  "method": "personal_unlockAccount",
  "params": [
    "0xb2b2084de341e560da3d439ef5e5309d78a22a66",
    "most secure password ever",
    0
  ],
  "id": 1
}' http://localhost:8545 | jq .

Params:

1. the account address to unlock
2. the passphrase associated to the account
3. an unlock expiration time in seconds

From the doc:

The unencrypted key will be held in memory until the unlock duration expires.
If the unlock duration defaults to 300 seconds. An explicit duration of zero
seconds unlocks the key until geth exits.

Security (or lack of): the invocation can use zero seconds as the expiration
param for the first version of this feature.