<p>The purpose of BIP32 is to provide a standard for hierarchical deterministic (HD) key derivation. BIP32 allows users to back up the initial secret of their wallet, and then reconstitute all derived addresses from this initial backup in the future.</p>
<p>The mechanism you describe is essentially an application of an Elliptic Curve Diffie-Hellman (ECDH) to establish a shared secret. It relies on foreign input and therefore (as described) does not fulfill this backup function—each new address requires the sender's secret to be retained for the address to be recoverable in the future.</p>
<p>A similar approach is in use for  Monero's <a href="https://www.getmonero.org/resources/moneropedia/stealthaddress.html" rel="nofollow noreferrer">Stealth Addresses</a>. AFAIU, Monero solved the backup concern by using <code>OP_RETURN</code> outputs on the Monero blockchain to establish the shared secret. This ensures that the recipient key is sufficient to rediscover the shared secrets when resyncing the blockchain. This comes with some trade-offs: finding all recipient keys is much slower (since the blockchain has to be parsed) instead of something that can be done with local data even on offline devices and each address creation adds more data to the blockchain.</p>

CC BY-SA 4.0
2021-04-25T11:08:24.903Z
BIP47 was not well received, and is discouraged from being implemented.
Murch
CC BY-SA 4.0
2021-04-24T13:36:46.717Z
2021-04-24T13:47:34.003Z
2021-04-24T13:47:34.003Z
Murch
<p>I understand that:</p>
<pre><code>pubkey(a + b) = pubkey(a).combine(pubkey(b))
</code></pre>
<p>where <code>a</code> and <code>b</code> are secret keys.  (See: <a href="https://crypto.stackexchange.com/q/83694/17505">https://crypto.stackexchange.com/q/83694/17505</a>)</p>
<p>If, under the circumstances:</p>
<ul>
<li>Bob wants to pay Alice, by creating transaction output whose private key only Alice will know, yet whose public key different from Alice's public key.</li>
<li>Alice publishes <code>pubkey(alice_secret)</code>.</li>
<li>Bob creates an one-use, random secret key <code>x_secret</code>.</li>
<li>Bob publishes <code>x_secret</code>.</li>
</ul>
<p>Do the following conditions hold?</p>
<ul>
<li>Only Alice can sign messages with the secret key <code>(alice_secret + x_secret)</code>, as no-one else knows both secret keys.</li>
<li>Anyone can verify such a message's signature using <code>pubkey(alice_secret).combine(pubkey(x_secret))</code>, as <code>pubkey(x_secret)</code> can be calculated from the published <code>x_secret</code>.</li>
</ul>
<p>If so, why is BIP32 more complex than this?</p>

CC BY-SA 4.0
2021-04-24T11:52:32.363Z
BIP32 is hierarchical _deterministic_ key derivation. What you describe is not deterministic, but relies on foreign data. Could you elaborate how the two fulfill the same or a similar purpose? (Or is that your question?)
Murch
CC BY-SA 4.0
2021-04-24T13:20:05.103Z
Thanks, I think you've answered my question.  What I am describing is not deterministic, but instead a way for Bob to Pay Alice in a way that Alice can receive the funds, but using a different public key for each transaction.  If you rephrase your comment as an answer, I'll accept it.
fadedbee
<bip32-hd-wallets><address-generation><ecdh>
Why is BIP32 not simply PublicKey multiplication?
fadedbee
# Why is BIP32 not simply PublicKey multiplication?

(Asked by: username_0 on 2021-04-24)

I understand that:
pubkey(a + b) = pubkey(a).combine(pubkey(b))

where a and b are secret keys.  (See: https://crypto.stackexchange.com/q/83694/17505)
If, under the circumstances:

Bob wants to pay Alice, by creating transaction output whose private key only Alice will know, yet whose public key different from Alice's public key.
Alice publishes pubkey(alice_secret).
Bob creates an one-use, random secret key x_secret.
Bob publishes x_secret.

Do the following conditions hold?

Only Alice can sign messages with the secret key (alice_secret + x_secret), as no-one else knows both secret keys.
Anyone can verify such a message's signature using pubkey(alice_secret).combine(pubkey(x_secret)), as pubkey(x_secret) can be calculated from the published x_secret.

If so, why is BIP32 more complex than this?

**Tags:** bip32-hd-wallets, address-generation, ecdh

> **Comments:**
> **username_1**: BIP32 is hierarchical _deterministic_ key derivation. What you describe is not deterministic, but relies on foreign data. Could you elaborate how the two fulfill the same or a similar purpose? (Or is that your question?)  
> **username_0**: Thanks, I think you've answered my question.  What I am describing is not deterministic, but instead a way for Bob to Pay Alice in a way that Alice can receive the funds, but using a different public key for each transaction.  If you rephrase your comment as an answer, I'll accept it.  

---

## 1 answers

### Answer by username_1 on 2021-04-24. Score: 2 | Accepted answer

The purpose of BIP32 is to provide a standard for hierarchical deterministic (HD) key derivation. BIP32 allows users to back up the initial secret of their wallet, and then reconstitute all derived addresses from this initial backup in the future.

The mechanism you describe is essentially an application of an Elliptic Curve Diffie-Hellman (ECDH) to establish a shared secret. It relies on foreign input and therefore (as described) does not fulfill this backup function—each new address requires the sender's secret to be retained for the address to be recoverable in the future.

A similar approach is in use for Monero's [Stealth Addresses](https://www.getmonero.org/resources/moneropedia/stealthaddress.html). AFAIU, Monero solved the backup concern by using `OP_RETURN` outputs on the Monero blockchain to establish the shared secret. This ensures that the recipient key is sufficient to rediscover the shared secrets when resyncing the blockchain. This comes with some trade-offs: finding all recipient keys is much slower (since the blockchain has to be parsed) instead of something that can be done with local data even on offline devices and each address creation adds more data to the blockchain.

> **Comments:**
> **username_1**: BIP47 was not well received, and is discouraged from being implemented.  

---

