I'm writing a library for Ethereum BIP44 address trees and comparing it against https://iancoleman.io/bip39/ using the same mnemonic phrase.

Given this mnemonic (just a test)

report dash combine correct until media shrimp wide about remain accuse sound solar lawsuit chest myth layer always style filter farm prison will brief

I correctly derived the seed


The BIP32 Root Key matches as well:


This is for ETH, so I'm using the following path to get the Account Extended keys: m/44'/60'/0' (also matching)

# Account extended private key

# Account extended public key

The BIP32 derivation path looks correct as well (m/44'/60'/0'/0)

BIP32 Extended private key

BIP32 Extended public key

Everything checks but the generation of the ethereum addresses.



Question: Is this correct ?

  • The above address is generated from the BIP32 root key using the specified path following these steps.

  • The resulting extended public key (note the M) is Base58 decoded

  • The compressed public key is recovered, using EC curve calculation we recover the Y coordinate and append X and Y together to get the uncompressed public key

    • The standard steps to get 20 byte address (keccak sha3, keep just the tail 20 bytes and append "0x")

I double checked my Keccak hash function and it returns the correct hash for the "" value:


1 Answer 1


This is silly but I found what the problem was. After I ran the libsecp256k1 point multiplication to obtain the second coordinate of the public key I was discarding the first 8 bytes of the resulting public key instead of just the first ("0x04" prefix).

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.