I’m trying to replicate some of the Electrum’s functionalities in an effort to understand the Bitcoin protocol. According to what I gathered from BIP-32 there are 3 child key derivation (CKD) functions:
- private parent key –> private child key
- public parent key –> public child key
- private parent key –> public child key
I started with the following sample mnemonic:
ancient inflict mimic valve luggage doctor march tackle hour danger shoot urban
I’ve successfully derived the master private key (927e83f76f95b957e5bde160761b8cee72094edc8c7007bcf31f53fa0ce5e483) and master public key (03931fb9b188e7c582e187620bd8d65eec7ddcd134f68cae78301a6f94fb866d68). However, when I try to derive the public key/ address associated with the path shown as m/0/0 by the wallet, the results don’t match. I’ve tried many code tweaks (key hardening, different depths, etc) with lots of different results. The expected results are:
- public key: 022586d491bc387b161959e25d05772e98814da69215a3152b54e4d1ae0c1a4168
- address: bc1q83ljq9ad7rck4vdz0l7f7rr2zsprgn8rtvpmpa
I’m self implementing the secp256k1 field operation, but I believe the main reason for the wrong results are flawed CKD functions in my code. Some of the points that are not clear to me:
- Why are the chain codes identical if they seem to be obtained by different processes?
This extension, called the chain code, is identical for corresponding private and public keys, and consists of 32 bytes.
- Aren’t public keys in general expected to be independently derived from private keys by scalar multiplication? There seems to be two additional routes to derive extended public child keys, namely, either from a public parent key or private parent key, and by different means, according to BIP-32.
- The private parent key –> public child key route involves a “neutered” key. What key is “neutered” and what does it mean?
