I am making an attempt to determine this out as properly.
Apparently it is simply “the primary 32 bits of the Hash160 of the grasp pubkey”.
So:
First_8_characters(RIPEMD160(SHA256($publicKey)))
It appears to have been applied in python at: https://github.com/darosior/python-bip32/
So utilizing the next python code I feel this makes the proper fingerprint:
$ pip3 set up bip32
$ python3
import binascii
from bip32 import BIP32, HARDENED_INDEX
bip = BIP32.from_xpub("xpub6CbtS57jivMSuzcvp5YZxp6JhUU8YWup2axi2xkQRVHY8w4otp8YkEvfWBHgE5rA2AJYNHquuRoLFFdWeSi1UgVohcUeM7SkE9c8NftRwRJ")
binascii.hexlify( bip.parent_fingerprint ).decode('ascii')
# provides "814adbb4"
bip = BIP32.from_xpriv("xprv9zrFarSYsBUzhmLYWJN4tYcdhZnEWQ7XCUQzNaouUDLu52xJggNisybDgqJRVe1hWww16SLJM478q5CCquPq5YQ19i2eTmz7HqmpsBnt1SS")
binascii.hexlify( bip.parent_fingerprint ).decode('ascii')
# provides "2984b47b"
Nevertheless it looks as if any 4-byte hex fingerprint works simply nice within the bitcoin core pockets, together with 00000000. In my testing, all legitimate (00000000-ffffffff) fingerprints generate the identical bitcoin addresses anyway.
So
$ bitcoin-cli getdescriptorinfo "wpkh([00000000/0h]$acctKey/0h/*)"
$ bitcoin-cli deriveaddresses "wpkh([00000000/0h]$acctKey/0h/*)#<checksum right here>"
Sources:
https://github.com/bitcoin/bitcoin/blob/grasp/doc/descriptors.md#key-origin-identification
”
When interacting with a {hardware} system, it could be crucial to incorporate the complete path from the grasp down. BIP174 standardizes this by offering the grasp key fingerprint (first 32 little bit of the Hash160 of the grasp pubkey), plus all derivation steps. To assist setting up these, we allow offering this key origin data contained in the descriptor language, though it doesn’t have an effect on the precise scriptPubKeys it refers to.
Each public key could be prefixed by an 8-character hexadecimal fingerprint plus elective derivation steps (hardened and unhardened) surrounded by brackets, figuring out the grasp and derivation path the important thing or xpub that follows was derived with.
Notice that the fingerprint of the guardian solely serves as a quick technique to detect guardian and little one nodes in software program, and software program should be keen to cope with collisions.
“
https://github.com/bitcoin/bitcoin/blob/grasp/doc/descriptors.md#reference
KEY expressions:
Optionally, key origin data, consisting of:
- An open bracket [
- Exactly 8 hex characters for the fingerprint of the key
where the derivation starts (see BIP32 for details)
- Followed by zero or more /NUM or /NUM' path elements to
indicate unhardened or hardened derivation steps between
the fingerprint and the key or xpub/xprv root that follows
- A closing bracket ]
Following the hyperlink for BIP32 exhibits:
https://github.com/bitcoin/bips/blob/grasp/bip-0032.mediawiki#key-identifiers
”
Prolonged keys could be recognized by the Hash160 (RIPEMD160 after SHA256) of the serialized ECDSA public key Okay, ignoring the chain code. This corresponds precisely to the info utilized in conventional Bitcoin addresses. It isn’t suggested to symbolize this information in base58 format although, as it could be interpreted as an tackle that manner (and pockets software program shouldn’t be required to simply accept cost to the chain key itself).
The primary 32 bits of the identifier are known as the important thing fingerprint.
“
4 bytes: the fingerprint of the guardian's key (0x00000000 if grasp key)