ligi: ligi: Because they do a BIP44 derivation …

So there’s the problem. I don’t think any of the main Ethereum clients use BIP44. To this day, I still don’t understand why all the wallets look at Ethereum like it is Bitcoin (it is not; the only shared aspect is secp256k1).

We decided not to use BIP44 and there a long list of reasons why. Foremost is that it adds a lot of complexity and injects a standard which is specific to Bitcoin. BIP44 is a layer on top of and strongly bound to secp256k1 and Bitcoin’s UTXO model. And, at the time we developed “JSON-UTC”, BIP44 was optional for Bitcoin and not yet the default. That de facto makes BIP44 optional. BIP32/44 were at an early-stage when we were going through audits and the only non-standard parts of Bitcoin’s cryptography that had gone through a thorough audit was secp256k1 (thanks to Pieter Wuille who also created BIP32).

What information might be missing here, and with all wallets, is that BIP32 is very specific to Bitcoin and it has a lot of sharp edges which are counterintuitive. In the context of Ethereum, BIP32’s functionality is redundant and perhaps misleading. BIP32 was NOT created for supporting multiple accounts – it is for creating multiple LINKED accounts for use with a UTXO model, specifically such that every transaction can be linked to every other transaction. This is juxtaposed to Ethereum’s account and transaction model and poses a risk to privacy. Ethereum could use an HD KDF for accounts, but if we did that, its not clear what happens if future releases support curves other than secp256k1 (in such cases, BIP32s linkability wouldn’t work, rendering it as useless vs. an ordinary HKDF). This wasn’t postulation, as metropolis and serenity were already being considered (both of which hypothetically support non-secp256k1 curves via account abstraction).

With BIP44, there’s no reliable way to figure out the user’s current address, which addresses they have balances on and which addresses they don’t – it is literally a brute-force process. That’s not fun at all. And since Ethereum has nonces and doesn’t use UTXO, BIP32 is redundant and adds unnecessary complexity vs. a normal HKDF.

So its simple to support both. When someone restores a mnemonic, you check both. Preferably, a wallet would not ask someone to extract their native Ethereum private key into a mnemonic. I also firmly believe there are safer ways of handling this.

Needless to say, I wish I had more time and cycles to work on this. Just not there yet!