2

Why are the params from the request object in reverse order between personal_sign and eth_sign?

For example, the personal_sign request object has the hex message in params[0]:

// Request
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "personal_sign",
  "params":["0xdeadbeaf","0x9b2055d370f73ec7d8a03e965129118dc8f5bf83"],
}

Whereas in eth_sign, the hex message in found in params[1]:

// Request
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "eth_sign",
  "params": ["0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "0xdeadbeaf"],
}

1 Answer 1

1

It's kinda a historical development thing:

  • eth_sign — was implemented first and the goal was to sign messages to prove the account ownership. It has the account address first and the message second. eth_sign however as you probably know has been often misused or maliciously used in that it can trick the user to sign a message that results in a transaction that in turn may result in stole funds. e.g. have a read on eth_sign phishing analysis here.

  • personal_sign — to combat the eth_sign misuse, personal_sign was later introduced. personal_sign has a different prefix to ensure the users are aware they are signing a personal message, not a transaction. That's why personal_sign has the message first and the address second. personal_sign does not result in a transaction and thus cannot be misused in the same way that eth_sign can.

You can even go down the rabbit hole of the original thread here that's still alive today.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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