<p>maybe this will help? <a href="https://bitcoin.org/en/developer-guide#hierarchical-deterministic-key-creation" rel="nofollow">https://bitcoin.org/en/developer-guide#hierarchical-deterministic-key-creation</a></p>

<p>or check the various BIP32 implementations (bitcore for example)</p>

CC BY-SA 3.0
2014-12-29T09:43:12.363Z
2014-12-29T09:43:12.363Z
Ruben de Vries
<p>I believe there is a typo. It should instead read <code>Q'=(d+c)G=Q+cG</code>. The private part <code>d+c</code> is an offset of the payee's private part <code>d</code>, so only known to the payee. The public part is an offset <code>cG</code>, known to both.</p>

CC BY-SA 3.0
2014-04-09T07:49:19.933Z
2014-04-09T07:49:19.933Z
Randomblue
<p>This algorithm generates a public key, which both parties know. It's just a public key, though, so only recipient has the ability to spend the funds.</p>

<p>According to the paper, <code>Q</code> is the recipient's stealth public key and <code>c</code> is the shared secret. The calculation <code>Q'=(Q+c)G</code> creates a shared public key derived from the receiver's stealth public key.</p>

<p>If the receiver's private stealth key is <code>d</code>, they can unlock the funds by calculating the new private key <code>(d+c)</code>. The sender doesn't know <code>d</code>, so they have no way of calculating this value.</p>

<p>BIP32 HD wallets use the same idea. You can start with a private key, <code>k</code>, and a public key <code>K = kG</code>. Then, you start adding random numbers (hashes, actually) to both keys. As long as you add the same number to both the private and the public key, you maintain a working keypair. You can reveal your public key <code>K</code>, which allows others to addresses, but they cannot spend from those addresses without knowing the private key <code>k</code>.</p>

CC BY-SA 3.0
2015-02-13T05:50:08.257Z
2015-02-13T05:57:55.800Z
2015-02-13T05:57:55.800Z
William Swanson
<p>I am reading the technical "specification" for stealth addresses, available <a href="http://sourceforge.net/p/bitcoin/mailman/message/31813471/" rel="noreferrer">here</a>. The core idea is described in the following paragraph:</p>

<blockquote>
  <p>Using Elliptic curve Diffie-Hellman (ECDH) we can generate a shared
  secret that the payee can use to recover their funds. Let the payee
  have keypair Q=dG. The payor generates nonce keypair P=eG and uses
  ECDH to arrive at shared secret c=H(eQ)=H(dP). This secret could be
  used to derive a ECC secret key, and from that a scriptPubKey, however
  that would allow both payor and payee the ability to spend the funds.
  So instead we use BIP32-style derivation to create Q'=(Q+c)G and
  associated scriptPubKey.</p>
</blockquote>

<p>I understand everything except the last sentence. As far as I can tell, <code>Q</code> and <code>c</code> are known to the payee and payer so the keypair <code>Q'=(Q+c)G</code> is also known to both. How does <code>Q'</code> allow for only the payee to spend the funds? How does BIP32-style derivation work?</p>

<address><ecdh>
What is BIP32-style derivation?
Randomblue
# What is BIP32-style derivation?

(Asked by: username_0 on 2014-04-08)

I am reading the technical "specification" for stealth addresses, available [here](http://sourceforge.net/p/bitcoin/mailman/message/31813471/). The core idea is described in the following paragraph:

> Using Elliptic curve Diffie-Hellman (ECDH) we can generate a shared
> secret that the payee can use to recover their funds. Let the payee
> have keypair Q=dG. The payor generates nonce keypair P=eG and uses
> ECDH to arrive at shared secret c=H(eQ)=H(dP). This secret could be
> used to derive a ECC secret key, and from that a scriptPubKey, however
> that would allow both payor and payee the ability to spend the funds.
> So instead we use BIP32-style derivation to create Q'=(Q+c)G and
> associated scriptPubKey.

I understand everything except the last sentence. As far as I can tell, `Q` and `c` are known to the payee and payer so the keypair `Q'=(Q+c)G` is also known to both. How does `Q'` allow for only the payee to spend the funds? How does BIP32-style derivation work?

**Tags:** address, ecdh


---

## 3 answers

### Answer by username_1 on 2014-12-29. Score: 1

maybe this will help? <https://bitcoin.org/en/developer-guide#hierarchical-deterministic-key-creation>

or check the various BIP32 implementations (bitcore for example)


---

### Answer by username_0 on 2014-04-09. Score: 1

I believe there is a typo. It should instead read `Q'=(d+c)G=Q+cG`. The private part `d+c` is an offset of the payee's private part `d`, so only known to the payee. The public part is an offset `cG`, known to both.


---

### Answer by username_2 on 2015-02-13. Score: 0

This algorithm generates a public key, which both parties know. It's just a public key, though, so only recipient has the ability to spend the funds.

According to the paper, `Q` is the recipient's stealth public key and `c` is the shared secret. The calculation `Q'=(Q+c)G` creates a shared public key derived from the receiver's stealth public key.

If the receiver's private stealth key is `d`, they can unlock the funds by calculating the new private key `(d+c)`. The sender doesn't know `d`, so they have no way of calculating this value.

BIP32 HD wallets use the same idea. You can start with a private key, `k`, and a public key `K = kG`. Then, you start adding random numbers (hashes, actually) to both keys. As long as you add the same number to both the private and the public key, you maintain a working keypair. You can reveal your public key `K`, which allows others to addresses, but they cannot spend from those addresses without knowing the private key `k`.


---

