Topic: Please review my work-in-progress of xpriv / xpub key derivation. (Read 104 times)

🤣, I keep on finding other parts of the picture... Truly a gift that keeps on giving... Bitcoin.

But is the above going in the right direction?

It's not just xpubs and xprvs that can be derived like this, you can also make ypub, zpub and so on by changing the extended key version bits.

I think you might find the full list on SLIP-32 or maybe SLIP-132, I'm not sure which one. But it also includes the values for testnet.

I'm trying to write a personal summary, and the above is a rough start. Thanks for the great input, though, you're especially trained in being an asshole, it seems. Typical Bitcoin Talk trash.

How is this different from what is described in BIP-32?

You're merely transscribing inconhesive bits of what is already know and described better in HD key derivation scheme cited above as BIP-32, unless I missed some important deviations you try to do or something you want to improve (somewhat unlikely).

What purpose exactly does your post has? What are you trying to achieve?

Derivation of Extended Private Key

The extended private key is derived from the root key by employing a cryptographic hash function, such as HMAC-SHA512, resulting in a hash value that contains both the chain code and extended private key.

• The hash value is 512 bits (64 bytes) in size. The first 256 bits (32 bytes) of the hash represent the chain code, while the next 256 bits (32 bytes) represent the extended private key.

• The chain code, along with the parent private key, is then used to deterministically derive child keys. By combining the parent private key with the chain code and an index, a unique child key is generated.

This ensures that the same child key can be derived independently by different parties as long as they have the same parent private key and chain code.

Moreover, The chain code also enhances security by preventing the derivation of parent private keys from child keys alone, adding an additional layer of protection to hierarchical deterministic wallets.

Derivation of Extended Public Key

The extended public key is derived from the extended private key by applying elliptic curve cryptography (ECC) to the corresponding private key, resulting in the public key, which is subsequently combined with the chain code from the extended private key to form the extended public key—thereby enabling the same deterministic derivation of child keys as the extended private key.

ECC is a type of asymmetric cryptography that relies on the mathematical properties of elliptic curves over finite fields.

An elliptic curve is defined by an equation of the form y² = x³ + ax + b mod p, where y² and x³ represent the coordinates of points on the curve, including both the generator point G (denoted as xG and yG) and the resulting public key K (denoted as xK and yK).

Furthermore, a, b, and p are parameters that define a specific elliptic curve, with a and b determining the specific shape and properties of the curve, and p ensuring that the curve operates over a finite field of 2*256 elements, providing a large number of points for cryptographic operations.

• The specific curve utilized in the Bitcoin protocol is “secp256k1”, with the above referring to that specific curve.

In order to derive public key K, generator point G is added to itself k times, or K = k × G, where K is the resulting point (the public key), k is the private key, and G is the generator point.

• The generator point G is a fixed point on the elliptic curve that serves as the starting point for generating other points on the curve through scalar multiplication, which refers to the operation of adding point G to itself multiple times.


• Each addition of G to itself represents one "step" in the multiplication process, and after k steps, we arrive at the resulting point K, which is the public key corresponding to the private key k.

Once the public key is known, it is combined with the chain code derived from the extended private key, a checksum is computed and appended, and the package is encoded into Base 58, rendering the extended public key human-readable and suitable for use in HD wallets.