user21331: Lets say user A wants to send bitcoin to user B stealth address.

What is exactly user B's stealth address? Is it his public key? Since User A needs to multiply his private key with user B's public key based on Elliptic Curve Diffie-Hellman so I assume user A is receiving the complete point which is user B's public key.
User A shoud calculate PrivA * PublicB which results in a coordinate. As far as I know this point will be used by multiplying it to the publicB and a nonce and that will be sent to the network. If what I am saying is correct, how can I multiply this coordinate with PublicB since both of them are points. Do we only get one axis of this point from the diffie hellman's calculation?


user25088: 
What is exactly user B's stealth address? Is it his public key?

In the simplest stealth address scheme, yes. The exact encoding depends on the implementation; DarkWallet's is described in their wiki.

how can I multiply this coordinate with PublicB since both of them are points?

Correct, S = PrivA * PublicB = PrivB * PublicA is a point. We want an integral shared secret. ECDH tells you to use the x coordinate of S as the shared secret, but in Bitcoin it's done differently. Instead int(sha256(compress(S))) is used:

serialize S in compressed form as per SEC 1's Elliptic-Curve-Point-to-Octet-String Conversion
take its SHA-256 digest
interpret the result as a 256-bit big-endian integer

This integer, c, is then used by A to calculate a public key PublicB + c*G to which A spends, and by B to calculate its private key (PrivB + c) * G from which B can redeem (where G is the base point generator).
Note that there's a problem with this "simplest" scheme. The only way that B's wallet software can see if a UTXO is redeemable by B (to keep track of the wallet's balance) is by doing the math above, which requires PrivB. In other words, it makes watching-only wallets impossible (and cold wallets impractical).
One solution to this is to use one PublicB/PrivB pair for ECDH, but a different PublicB2/PrivB2 pair for deriving the spend/redeem keys. Now you can keep PrivB in your watching-only wallet, and PrivB2 in your cold wallet. On the down side, B's stealth address is now twice as long, containing both PublicB and PublicB2.

21331: <p>Lets say user <code>A</code> wants to send bitcoin to user <code>B</code> stealth address.</p>

<ol>
<li><p>What is exactly user <code>B</code>'s stealth address? Is it his public key? Since User <code>A</code> needs to multiply his private key with user <code>B</code>'s public key based on <a href="http://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman" rel="nofollow">Elliptic Curve Diffie-Hellman</a> so I assume user <code>A</code> is receiving the complete point which is user <code>B</code>'s public key.</p></li>
<li><p>User <code>A</code> shoud calculate <code>PrivA * PublicB</code> which results in a coordinate. As far as I know this point will be used by multiplying it to the <code>publicB</code> and a nonce and that will be sent to the network. If what I am saying is correct, how can I multiply this coordinate with <code>PublicB</code> since both of them are points. Do we only get one axis of this point from the diffie hellman's calculation?</p></li>
</ol>
 25088: <blockquote>
  <p>What is exactly user B's stealth address? Is it his public key?</p>
</blockquote>

<p>In the simplest stealth address scheme, yes. The exact encoding depends on the implementation; DarkWallet's is described <a href="https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth#Address_format" rel="nofollow">in their wiki</a>.</p>

<blockquote>
  <p>how can I multiply this coordinate with PublicB since both of them are points?</p>
</blockquote>

<p>Correct, <code>S = PrivA * PublicB = PrivB * PublicA</code> is a point. We want an integral shared secret. ECDH tells you to use the x coordinate of <code>S</code> as the shared secret, but in Bitcoin it's done differently. Instead <code>int(sha256(compress(S)))</code> is used:</p>

<ol>
<li>serialize S in compressed form as per <a href="http://www.secg.org/sec1-v2.pdf#page=16" rel="nofollow">SEC 1's Elliptic-Curve-Point-to-Octet-String Conversion</a></li>
<li>take its SHA-256 digest</li>
<li>interpret the result as a 256-bit big-endian integer</li>
</ol>

<p>This integer, <code>c</code>, is then used by A to calculate a public key <code>PublicB + c*G</code> to which A spends, and by B to calculate its private key <code>(PrivB + c) * G</code> from which B can redeem (where <code>G</code> is the base point generator).</p>

<p>Note that there's a problem with this "simplest" scheme. The only way that B's wallet software can see if a UTXO is redeemable by B (to keep track of the wallet's balance) is by doing the math above, which requires <code>PrivB</code>. In other words, it makes watching-only wallets impossible (and cold wallets impractical).</p>

<p>One solution to this is to use one <code>PublicB</code>/<code>PrivB</code> pair for ECDH, but a different <code>PublicB2</code>/<code>PrivB2</code> pair for deriving the spend/redeem keys. Now you can keep <code>PrivB</code> in your watching-only wallet, and <code>PrivB2</code> in your cold wallet. On the down side, B's stealth address is now twice as long, containing both <code>PublicB</code> and <code>PublicB2</code>.</p>
