MASTERING-BITCOIN

The Algebra Trick Behind HD Wallets

IKey Formulas

Formula	Name	Meaning
$K = k \cdot G$	Key pair identity	Public key = private scalar times generator
$K + t \cdot G = (k + t) \cdot G$	Linearity identity	Adding $t \cdot G$ publicly equals adding $t$ to $k$ privately
$k' = k + t,\ \ K' = k' \cdot G$	Child key pair	Derived (non-hardened) child from tweak $t$
$t = H(k \,\\|\, \text{index})$	Hardened tweak	Mixes parent private key into the tweak so $K$ alone cannot derive child

IIVisualization 1: Linearity — Two Paths, One Destination

The single identity $K + t \cdot G = (k + t) \cdot G$ is the whole trick. It says that scalar multiplication by $G$ is linear, so adding a tweak on the public side gives the same point as adding the tweak to the secret and multiplying after.

Below, $G$ is drawn as a 2D vector standing in for the elliptic-curve generator. Scalar multiplication of a vector by an integer has the same linearity property that the elliptic curve has. Watch how the public route (red then blue) and the private route (green dashed) always land on the same endpoint $K'$ .

⚙ interactive visualization — coming to this page format soon

Notice: No matter which values of $k$ and $t$ you pick, the gold star sits at exactly the same point whether you traveled there by the public route (red + blue) or the private route (green dashed). That single fact is the whole reason watch-only wallets and offline hardware signers can agree on addresses without ever sharing a secret.

IIIVisualization 2: The BIP32 Tree

BIP32 applies the tweak trick recursively. From a single master key (derived from a 12- or 24-word seed), an entire tree of child key pairs is generated — accounts, receiving/change chains, and thousands of individual addresses per chain. Explore the tree below by picking an account and an address index.

⚙ interactive visualization — coming to this page format soon

Reflect: The entire tree — every account, every chain, every address — is reproducible from the same seed phrase. One paper backup protects a lifetime of addresses. Non-hardened branches (the lower levels) allow an online machine holding only $K$ to derive child public keys; hardened branches (the top-level accounts, marked with an apostrophe) isolate sensitive segments so a leaked child reveals nothing upstream.

IVQuiz

Question 1

Alice holds the master private key $k$ and the master public key $K = k \cdot G$ . Bob has only $K$ . Bob picks a tweak $t = 42$ and computes $K + t \cdot G$ .

What does Bob's result equal?

✅ Correct! This is the linearity identity with $t = 42$ .

❌ Not quite. Remember the identity $K + t \cdot G = (k + t) \cdot G$ .

Show solution

Solution:

The linearity identity says $K + t \cdot G \;=\; (k + t) \cdot G.$

So with $t = 42$ , $K + 42 \cdot G \;=\; (k + 42) \cdot G.$

The child private key is $k' = k + 42$ , and the child public key is $K' = k' \cdot G$ . Bob computed $K'$ using only public data; Alice can later compute the matching $k'$ by adding $42$ to her secret $k$ .

Note why the other options are wrong:

"k · (G + 42)" — ❌ You cannot add the scalar $42$ to the curve point $G$ .
"(k · 42) · G" — ❌ That would be $42$ times the public key, not the linearity identity.
"k + 42 · G" — ❌ Mixes a scalar and a point; not a valid expression.

Question 2

True or False: A web frontend that holds only the master public key $K$ (and never any private key) can still generate an unlimited supply of fresh Bitcoin receiving addresses for customers, as long as it uses non-hardened derivation.

✅ Correct! This is the watch-only wallet pattern.

❌ Not quite. The linearity identity lets you compute child public keys from $K$ alone along non-hardened branches.

❌ Not quite. Try again — the hints above can help.

Show solution

Solution: True.

For each new payment the frontend picks a fresh tweak $t$ (often derived deterministically, e.g. from a counter or a chain code and an index) and computes $K' = K + t \cdot G.$

This uses only the master public key $K$ and the publicly-computable point $t \cdot G$ . No secret is required on the frontend. The matching private key $k' = k + t$ only needs to exist on the offline hardware signer when a spend is actually required.

This is exactly what powers watch-only wallets, exchange deposit address generation, and the hot/cold split in hardware-wallet setups.

(Note: hardened derivation breaks this trick on purpose — but Question 3 covers that.)

Question 3

An attacker somehow learns a non-hardened child private key $k'$ and also learns the tweak $t$ that produced it from the parent.

What can the attacker compute?

✅ Correct! This upward leak is exactly the reason hardened derivation exists.

❌ Not quite. With non-hardened derivation, $k' = k + t$ , so subtracting $t$ recovers $k$ .

Show solution

Solution:

Non-hardened derivation uses $k' = k + t$ where $t$ is a publicly-computable tweak. If an attacker knows both $k'$ and $t$ , they can simply rearrange: $k = k' - t.$

This is the known downside of non-hardened derivation, and it is exactly why BIP32 also defines hardened derivation. Hardened derivation builds the tweak from a hash of the parent private key: $t = H(k \,\|\, \text{index}).$

Because an attacker with only $K$ (or even a leaked child key) cannot invert the hash to recover $k$ , hardened derivation breaks the public-side linearity trick on purpose and isolates the branch.

Rule of thumb:

Non-hardened — use where you need watch-only address generation.
Hardened — use at sensitive boundaries (e.g., top-level accounts) to contain the blast radius of a leak.

Question 4

Which property of elliptic-curve scalar multiplication is the single fact that makes HD wallets, watch-only wallets, and offline hardware signers all possible?

✅ Correct! Linearity is the one property doing the heavy lifting across every HD-wallet feature.

❌ Not quite. The other properties matter for Bitcoin, but the HD-wallet trick specifically depends on linearity.

Show solution

Solution:

The key property is linearity: $K + t \cdot G \;=\; (k + t) \cdot G.$

Because adding the same tweak on each side preserves the $K = k \cdot G$ relationship, you can derive a valid child public key on the public side (using only $K$ ) and the matching child private key on the private side (using only $k$ ), and they will line up — with no communication required beyond the publicly-known tweak.

The other options are all true statements about EC cryptography, but they play different roles:

One-wayness (option 1) is what keeps the master private key safe once the master public key is published. It's necessary for Bitcoin to work at all, but it is not what enables HD derivation.
The point at infinity and SHA-256 are plumbing details; neither one is what makes the public/private split of HD wallets possible.

One line of algebra carries the entire self-custody stack.

Solved: 0 / 4