2

Im trying to rewrite the all ethereum address creation and Tx creation in PHP and Im almost there. I have implemented a sha3 but now Im confused on if its giving me the correct output because it seems ethereum sha3 implemenations lack consistency when dealing with prefixed hex characters Which of the following scenarios has the correct sha3 of this RPL hash. In my php I have generated this RPL hash (its a hex output) PS Iknow the difference between Ethereum sha3 (Keccak) and standard sha3 ec0185055f9408bc82520c94145e99f7bc840f3ea42d9a64221f041f9955dca2880429d069189e000080038080

Now using Parity node and web3js I create a sha3().

Scenario 1

web3.utils.sha3('ec0185055f9408bc82520c94145e99f7bc840f3ea42d9a64221f041f9955dca2880429d069189e000080038080')

or

web3.utils.sha3('ec0185055f9408bc82520c94145e99f7bc840f3ea42d9a64221f041f9955dca2880429d069189e000080038080',{encoding:'hex'})

'0x9a8419514d3c7382a6dafc67adf18ac13b818687e9a074a0cee123e0f9a483d8'

Scenario 2

web3.utils.sha3('0xec0185055f9408bc82520c94145e99f7bc840f3ea42d9a64221f041f9955dca2880429d069189e000080038080')

'0xf1d622e8725ef0dd84e1e65239a0ecac4428b05a2ee0c219739e6e85eb57a8b6'

scenario 3

Using etheruemjs

var util = require('ethereumjs-util');
var hashed = util.sha3('0xec0185055f9408bc82520c94145e99f7bc840f3ea42d9a64221f041f9955dca2880429d069189e000000038080')

'0x0e79fdc47ef979edbbed33d347f42da74849149139db9d5a58a4038ae6bdc99c'

scenario 4

(Using etheruemjs)

var util = require('ethereumjs-util');
var hashed = util.sha3('ec0185055f9408bc82520c94145e99f7bc840f3ea42d9a64221f041f9955dca2880429d069189e000080038080')

'0x9a8419514d3c7382a6dafc67adf18ac13b818687e9a074a0cee123e0f9a483d8'

0

It's this one, assuming that what you are doing is hashing 45 consecutive bytes:

> web3.utils.sha3('0xec0185055f9408bc82520c94145e99f7bc840f3ea42d9a64221f041f9955dca2880429d069189e000080038080',{encoding:'hex'})
'0xf1d622e8725ef0dd84e1e65239a0ecac4428b05a2ee0c219739e6e85eb57a8b6'

(It turns out that the "encoding:'hex'" flag is optional in Web3 1.0. It didn't used to be.)

To confirm this, I wrote a little LLL program to get an authoritative answer from the EVM:

(returnlll
  (seq
     [0]:0xec0185055f9408bc82520c94145e99f7bc840f3ea42d9a64221f041f9955dca2
    [32]:0x880429d069189e00008003808000000000000000000000000000000000000000
    (return (keccak256 0 45))))

Running it gives,

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

as above.

I'm pretty certain this is correct. It's as close to the EVM as you can get without writing bytecode.

In most of your other examples (scenarios 1 & 4) you are hashing the ASCII string representation, which you can confirm using this utility. I don't know what scenario 3 is processing.

  • Thanks. I had done some trial and error and ending up using that implementation, but this confirms why. – ofumbi Dec 28 '17 at 16:15
  • @ofumbi Thanks, good to know. If you don't want to accept my answer, you can still upvote it - it took quite a bit of work, and every little helps ;-) – benjaminion Dec 28 '17 at 19:23
0

My apologies. Guess I was just Tired. I do not know why I did not think of doing some trial and Error before Asking. So I just created and attempted to broadcast the TX based on the all the hashes

scenerio 1 >> invalid sender.

scenerio 2 >> sent Successfully.

scenerio 3 >> sent Successfully.

scenerio 4 >> invalid sender

So decided to go with scenario 2 since my php code was already outputting that and it works like a charm.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.