For now, I'm generating WIF and address using golang btcutil package programmatically.

    wif, err := btcutil.NewWIF(privateKey, conf, false)
    if err != nil {
        return nil, err
    strPrivateKey := wif.String()

    // Address
    address, err := child.Address(conf)

    walletKeys[i] = WalletKey{WIF: strPrivateKey, Address: address.String(), EncodedAddress: address.EncodeAddress()}

After generating wif, I import this wif using bitcoin client importprivkey

err := b.client.ImportPrivKeyRescan(privKeyWIF, label, false)

And then, I make sure this private key is added into wallet using getaddressesbyaccount "label" command.

Somehow listed address and first generated address seems different.

I'd like to know why it's different.

Thanks in advance.

2 Answers 2


Addresses are hashed and encoded pubKeyScript. There are different types of address you can derive per a single public-key (or say also private-key). Most prominent ones are P2PKH, P2SH-P2WPKH, native P2WPKH (bech32).

I expect that the address type you are deriving from BTCD is different then the one your getting from Core.

Since a Core 0.16 (until now time of writing Aug 2018), the default address derivation format is "p2sh-segwit" (P2SH-P2WPKH, starting with 3). I could imaging that BTCD still derives you P2PKH addresses (starting with 1).

Since 0.16, Core has that addresstype argument where you can pass in "legacy" or "bech32" in order to generate either traditional P2PKH addresses or new Bech32 ("bc1...") addresses


I found that cause.

wif, err := btcutil.NewWIF(privateKey, conf, false) That third parameter is compress and it should be true. In the ends, generated address by golang and shown on bitcoin core after importprivkey command was matched.


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.