How does prefixing work exactly when signing messages?

Question

Here's a message I've signed using web3 :

> web3.eth.sign(web3.utils.soliditySha3("xyz"), "0x00a329c0648769A73afAc7F9381E08FB43dBEA72", "testing").then(console.log);
Promise {
  _bitField: 0,
  _fulfillmentHandler0: undefined,
  _rejectionHandler0: undefined,
  _promise0: undefined,
  _receiver0: undefined }
> 0xbddd506ff736e03c1c25eaefbc7d73ead76c34135bd7d2f0c626735a7246ac612ed1b71915e8e9131ef7b0711ac2cfef62cbef2e22d4c1cce8f273fd285240cb1b

If one tries to verify it using etherscan with:

[Step 1] Address: 0x00a329c0648769A73afAc7F9381E08FB43dBEA72
[Step 2] Message Signature Hash: 0xbddd506ff736e03c1c25eaefbc7d73ead76c34135bd7d2f0c626735a7246ac612ed1b71915e8e9131ef7b0711ac2cfef62cbef2e22d4c1cce8f273fd285240cb1b
[Step 3] Enter the original Message that was signed: xyz

Result would be Message Signature (with Geth Prefix) Verified. Pass!

But etherchain is giving Invalid signature! which I suppose is because of the prefix.

I've tried these as Message but none works :

\x19Ethereum Signed Message:\n32xyz
\x19Ethereum Signed Message:\n320x9dd2c369a187b4e6b9c402f030e50743e619301ea62aa4c0737d4ef7e10a3d49
\x19Ethereum Signed Message:\n329dd2c369a187b4e6b9c402f030e50743e619301ea62aa4c0737d4ef7e10a3d49
\x19Ethereum Signed Message:\n32ÒÃi¡´æ¹Äð0åCæ0¦*¤Às}N÷á
=I

What is the right Message?

---

Back to web3

> web3.eth.accounts.sign("xyz","0x177be4516179d50d87ed895505f84ea95189d8a74b59a54adac0466cfc436aaa")
{ message: 'xyz',
  messageHash: 
'0x47c659bdb805bd39452735d0acd70fafc43394fccbcd22897f98e58fd97c32f4',
  v: '0x1b',
  r: '0x...',
  s: '0x...',
  signature: '0x...' }

messageHash stays the same for every key, which is

> web3.utils.sha3("\x19Ethereum Signed Message:\n3xyz")
'0x47c659bdb805bd39452735d0acd70fafc43394fccbcd22897f98e58fd97c32f4'

Question 1: In solidity the prefix has to be \n32 instead of \n3 for ecrecover to work. Why?

Question 2: Why I am getting a wrong public address when:

> web3.eth.accounts.recover("0x47c659bdb805bd39452735d0acd70fafc43394fccbcd22897f98e58fd97c32f4", "0x1b", "0xbddd506ff736e03c1c25eaefbc7d73ead76c34135bd7d2f0c626735a7246ac61", "0x2ed1b71915e8e9131ef7b0711ac2cfef62cbef2e22d4c1cce8f273fd285240cb")
'0xf70Ec3f5A4eeDDc0fce9Ebe244CaBD22B5A49C95' !!!!!

Answer 1

As of today (18th August 2017) prefixing does not work.

That is to say there is no consistent specification, and clients implement signature generation in different ways.

I.E. Something signed in one place won't necessarily validate in another place if they have done the signing in a different way.

This is currently being debated. Please share your views.