2

I am copying and pasting the example from the bitcoin-cli help:

deriveaddresses "wpkh([d34db33f/84h/0h/0h] xpub6EuEBhzm7KD3yxmt9wFHisymSNmK8w2CFmfgUgXi74ChFa79YouJ1w3hpZmFAWiuLezZqD38fY6K8PkxUfPifzSEB35skuBBNf1efmSp12K/0/*)#trd0mf0l" "[0,2]"

And copying in a valid xpub.

However I always get an error:

Invalid descriptor (code -5)

Even if I copy in the exact bitcoin-cli call from the bitcoin github page here deriveaddresses pull request

deriveaddresses "wpkh([d34db33f/84h/0h/0h]xpub6DJ2dNUysrn5Vt36jH2KLBT2i1auw1tTSSomg8PhqNiUtx8QX2SvC9nrHu81fT41fvDUnhMjEzQgXnQjKEu3oaqMSzhSrHMxyyoEAmUHQbY/0/0)"

I still get the same error.

I am entering the commands directly in the console. What am I doing wrong?

Im using mainnet bitcoin core 0.18.0, mac OS 10.13.6

Michael Folkson
  • 14,337
  • 3
  • 11
  • 45
Fontaine
  • 466
  • 2
  • 10

1 Answers1

1

There are multiple things you are doing wrong.

Firstly, in your first descriptor, you have a miscellaneous space between the origin info (the stuff in square brackets) and the xpub. Secondly, this descriptor is also invalid because you have not computed the correct checksum for it. The checksum is the stuff that appears after the pound symbol (#) at the end of the descriptor. The checksum you have there is the checksum for the one from the help text which is only valid for that descriptor.

In order for your descriptor to be valid, you need to remove the space and recompute the checksum. Remove the checksum, including the pound symbol separator, and pass the non-checksummed descriptor into getdescriptorinfo. This will give you a descriptor with the correct checksum. Please note that it will change the hs in the origin info to single quotes (') which may need to be escaped.

Furthermore, because you are changing the xpub in your descriptor, the origin info in your descriptor is incorrect (although Bitcoin Core does not know this). You should change the origin information to match your xpub, or remove it entirely.

The reason the second descriptor you are trying does not work is because it does not have a checksum. The PR for deriveaddress was written before descriptors had checksums. The RPC was updated and changed when checksums were introduced.

Andrew Chow
  • 67,209
  • 5
  • 76
  • 149
  • Thank you, what is the "d34db33f" portion of the origin info and how do I get the correct origin info for my xpub? I understand the derivation path 84'/0'/0' but not the rest. – Fontaine May 07 '19 at 16:59
  • That is the fingerprint of the master public key. It's the first 4 bytes of the ripemd160 hash of the sha256 hash of the public key. – Andrew Chow May 07 '19 at 17:11
  • How can i ensure the descriptor has range? – Fontaine May 07 '19 at 17:12
  • By having `/*` after your xpub. You can specify unhardened indexes after the xpub, and ending with `/*` indicates that the last index is the range. – Andrew Chow May 07 '19 at 17:19
  • Still trying to wrap my head around the origin info and its effect on the derived keys. Again i get how the 84'/0'/0' derives keys work. But when I input `deriveaddresses "wpkh([d34db33f/84'/0'/0']xpub6EuEBhzm7KD3yxmt9wFHisymSNmK8w2CFmfgUgXi74ChFa79YouJ1w3hpZmFAWiuLezZqD38fY6K8PkxUfPifzSEB35skuBBNf1efmSp12K/*)#9k0fv7eh" "[0,99]"` It returns the same 100 keys from an xpub that I created on another app, which is great, but I copied the `d34db33f` from the example origin, it seems like the fingerprint doesn't have an effect? If it does can you explain its effect? – Fontaine May 07 '19 at 17:37
  • Origin info has no effect on key derivation entirely. It is metadata that is useful for transaction signing. You would want to have origin info if you were importing the descriptors via `importmulti`, but for `deriveaddress`, it is unnecessary. – Andrew Chow May 07 '19 at 17:40