# Why is the viewkey able to track incoming transactions, but not outgoing transactions?

This question basically boils down to why can't we have a single key that we can publish, such that an auditor could see incoming transactions, outgoing transactions, and thus a balance of a certain account.

To answer this question, we first have to explain how Monero works. The letters used in this answer correspond to the letters used for the math in the CryptoNote whitepaper. Note that scalars (private keys) are always represented by lowercase letters in equations and points (public keys) are always represented by uppercase letters.

In Monero you have two set of keys, namely the private view key (a) and the private spendkey (b), and the public view key (A) and public spend key (B). The public view key (A) and public spend key (B) are the counterparts of the private view key (a) and private spend key (b). That is, the private view key and private spend key are multiplied by the base point (G) to create their counterparts, the public view key (A = aG) and public spend key (B = bG). The public keys are needed to generate a public address. A detailed explanation of how this is done can be found here, but is irrelevant for this question. The view key that we can publish is known as the `tracking key (a,B)` in the CryptoNote whitepaper.

To illustrate how this view key works, we first have to explain how transaction outputs work in Monero. In Monero, coins are received to a unique, one-time stealth address. The formula for stealth addresses is as follows:

`P = Hs(rA)G + B`

• P -- the final stealth address (one-time output key, the destination where funds will actually be sent);
• Hs* -- a hashing algorithm that returns a scalar (i.e., the hash output is interpreted as an integer and reduced modulo l);
• r -- the new random scalar Alice chose for this transaction;
• A -- Bob's public view key;
• G -- the standard Ed25519 base point;
• B -- Bob's public spend key.

Stealth addresses are created as follows. First, the sender (Alice) does ECDH (Elliptic curve Diffie–Hellman) with her randomly-chosen r and the receiver's (Bob) public view key, A. This is point D (D = rA), which is a shared, secret point known only to Alice and Bob (D = D'). Thus, no one other than Alice or Bob is able to compute D. Second, Alice uses D to generate a new scalar, f, with f = Hs(D). Third, Alice computes F = fG. Lastly, Alice computes P = F + B (Bob's public spend key). Note that F is equal to Hs(rA)G in the formula above. Also Alice computes R by multiplying r by G, the curve's base point, (R = rG) and attaches it to the transaction.

If Bob receives a transaction, he wants to check if it belongs to him. This is done as follows. First, Bob retrieves R, which Alice has attached to the transaction. Second, Bob computes D'. In this step Bob doesn't (yet) know if D' is equal to D. D' = aR. Third, Bob computes f' = Hs(D'). Fourth, Bob computes F' = f'G. Fifth, Bob computes P' = F' + B. Lastly, Bob checks if P' is equal to P, which was included in the transaction as the destination. If P' = P the transaction output belongs to Bob.

From the aforementioned formula and explanation we can infer that, if an auditor knows a and B of Bob, he is able to compute aR (= D') for every transaction on the blockchain. Given that he also knows B, he is able to compute all stealth addresses for Bob (P) and thus is able to view all transactions and corresponding amounts Bob has received. Thus, the view key is able to track all incoming transactions for the corresponding account.

If Bob receives a transaction that belongs to him, he also wants to check if the outputs in this transaction have already been spent. This is done as follows. First, Bob recomputes f' = Hs(D') (as above). Second, Bob derives x = f' + b (to reiterate, b is Bob's private spend key). Third, to check if P is spent, Bob computes its "key image" and queries the blockchain to see if it is marked as spent. Key image = I = xHp(P). Lastly, to spend P, Bob needs to sign a new transaction with x.

From these steps we can infer that key images require the private spend key of Bob. Thus, if we want to track key images of a certain account (and thus the outgoing transactions), we would have to give the auditor our private spend key as well, which means he can also spend our funds! However, Bob would be able to retrieve the key images from the wallet and publish them, since an auditor wouldn't be able to derive the private spend key from the key images. This is a benefit of asymmetric cryptography. An auditor could subsequently query the blockchain to see which of Bob's published key images has been spent. Furthermore, he is able to compel Bob to publish corresponding key images for all outputs Bob has received. Given that he can also see all incoming transactions with the view key, he would be able to compute a balance for Bob's account.

I acknowledge this answer is quite technical and would certainly understand if you don't fully grasp it. It's quite difficult to answer this question in a less technical way. However, if you read the excellent articles of core-team member luigi1111, you would probably be able to understand. Most of this answer is based on his articles, hence.

P.S. luigi1111's articles can be found here:

https://steemit.com/monero/@luigi1111/understanding-monero-cryptography-privacy-introduction