search

MetaMask / metamask-extension

:globe_with_meridians: :electric_plug: The MetaMask browser extension enables browsing Ethereum blockchain enabled websites
https://metamask.io
Other
11.87k stars 4.85k forks source link

Remove "0x" from beginning of raw private keys (super low priority) #687

Closed tayvano closed 7 years ago

tayvano commented 7 years ago

I've never seen this raw, unencrypted private keys start with and add'l "0x" before. I know it doesn't actually make a difference in the grand scheme of things, but it won't unlock in MyEtherWallet.com nor via Geth. Jaxx's output of private key doesn't include the 0x either.

Where does this occur?

Demo

Seed phrase: section feel merit flower clump accuse exit maple piano chat crouch pyramid

Jaxx Outputs (HD):

MetaMask Outputs:

MEW (unlock via private key):

Geth (Using this method for importing plain private key):

danfinlay commented 7 years ago

Thanks for the report!

It's strange to me nobody else hex prefixes this, but it's easy to exclude.

On Sep 30, 2016, at 3:11 PM, Taylor Van Orden notifications@github.com wrote:

I've never seen this raw, unencrypted private keys start with and add'l "0x" before. I know it doesn't actually make a difference in the grand scheme of things, but it won't unlock in MyEtherWallet.com nor via Geth. Jaxx's output of private key doesn't include the 0x either.

Where does this occur?

Chrome extension -> click key icon/export private key for a wallet -> type I understand -> copy private key. Demo

Seed phrase: section feel merit flower clump accuse exit maple piano chat crouch pyramid

Jaxx Outputs (HD):

0xE2979fD0eB5d304891aBA9D39b27E82c9Fda6eE2 e316ca8ecfb79b0f0d085a17ac835cd390f806ac736ef39c9951747445cff202 MetaMask Outputs:

0xE2979fD0eB5d304891aBA9D39b27E82c9Fda6eE2 0xe316ca8ecfb79b0f0d085a17ac835cd390f806ac736ef39c9951747445cff202 MEW (unlock via private key):

0xe316ca8ecfb79b0f0d085a17ac835cd390f806ac736ef39c9951747445cff202 = invalid, won't unlock e316ca8ecfb79b0f0d085a17ac835cd390f806ac736ef39c9951747445cff202 = unlocks, displays address 0xE2979fD0eB5d304891aBA9D39b27E82c9Fda6eE2 Geth (Using this method for importing plain private key):

file with0xe316ca8ecfb79b0f0d085a17ac835cd390f806ac736ef39c9951747445cff202 returns Fatal: Failed to load the private key: encoding/hex: invalid byte: U+0078 'x' file with e316ca8ecfb79b0f0d085a17ac835cd390f806ac736ef39c9951747445cff202 returns true and encrypts the private key to UTC--2016-09-30T07-08-26.155091180Z--e2979fd0eb5d304891aba9d39b27e82c9fda6ee2 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

tayvano commented 7 years ago

I agree. I actually went thru jaxx and geth assuming I needed to update MEW to support both (which we totally could) only to discover you're the outlier. Sorry! 🙏 😛

paymog commented 6 years ago

It seems that ganache requires private keys to have the 0x prefix otherwise a RangeError happens saying that the private key length is invalid. Is it possible to ask metamask to sign with the 0x prefix?

tayvano commented 6 years ago

You should open an issue with ganache then. It's pretty standard at this point not to prefix private keys with 0x.

One good reason is private keys and transactions hashes are the same length. Prefixing transaction hashes with 0x and not private keys reduces the likelihood that you'll ever switch one out for another.

e.g. which of the below is a transaction hash and which is a private key?

0xafdfd9c3d2095ef696594f6cedcae59e72dcd697e2a7521b1578140422a4f890

0xb8b1f812af73c8e67b41520e5a93135b4d061002d33de1d06a606f5d314b7004

Fun fact, in 2016 there were 6 transaction hashes on the blockchain that, when used as a private key, that had a balance in them.

danfinlay commented 6 years ago

Fun fact, in 2016 there were 6 transaction hashes on the blockchain that, when used as a private key, that had a balance in them.

That's horrifying.

paymog commented 6 years ago

@tayvano you're right! Turns out I wasn't using the latest version of Ganache. Problem seems to be fixed in v6.1.6