More edits for clarity.

bsip-1203.md

@@ -13,7 +13,7 @@ The existing Stealth implementation ([BSIP-0008](bsip-0008.md)) requires the sen
 
 ## Motivation
 
-"Stealth addresses" are a method of providing _unlinkability_ to blockchain transactions.  Unlinkability is a major component of the Privacy Triad: _unlinkability_, _confidentiality_, and _untraceability_.  Using a stealth address, a sending wallet is able to compute a child public key that derives from a public key encoded in the address, but which cannot be correlated, or "linked", to the address public key, unless you are either the sender or the receiver.  This child key becomes the authorization key for transaction outputs (TXOs) intended for the receiver.  As such, third party observers cannot link TXOs to addresses, nor even link together independent TXOs which are "controlled" by the same address.
+"Stealth addresses" are a method of providing _unlinkability_ to blockchain transactions.  Unlinkability is a major component of the Privacy Triad: _unlinkability_, _confidentiality_, and _untraceability_.  Using a stealth address, a sending wallet is able to compute a child public key that derives from a public key encoded in the address, but which cannot be correlated, or "linked", to the address public key, unless you are either the sender or the receiver.  This child key becomes the authorization key for transaction outputs (TXOs) intended for the receiver.  As such, third party observers cannot link TXOs to addresses, nor even link together independent TXOs which are destined to the same address.
 
 Although this is a great benefit to privacy, it complicates the matter of detecting inbound transactions, since a wallet cannot simply scan for transactions which explicitly identify the destination address.
 
@@ -24,15 +24,15 @@ Existing [Stealth Phase I](bsip-0008.md) functionality already includes the use
 A confidential transaction (cTX) does not identify the recipient.  As such, there is no direct way for a wallet to use only its Stealth address to query the p2p network for inbound transactions.  In the current "phase one" implementation of Stealth ([BSIP-0008](bsip-0008.md)), inbound discovery is a manual process requiring the sender to communicate "transaction receipts" to the intended recipients of each transaction output in order to alert each recipient of their incoming balance.  Transaction receipts are encrypted data structures that embed the Pedersen commitment of the transaction output and the value and blinding factor that the recipient needs to "open" the commitment.  Additionally, the receipt records the one-time public key which the recipient must use to derive the private key offset needed to spend the incoming coin, via a shared-secret procedure between the one-time key and the recipient's address key.  The need to communicate transaction receipts is burdensome and introduces substantial risk of lost funds due to failure to communicate or retain receipts.
 
 _Keys involved in a cTX output (cTXO):_
-* **One-time PubKey (OTK)** — The sender generates this key (public and private) from randomness and uses it to generate a shared-secret between the OTK and the recipient's Address PubKey.  The OTK PubKey will be clear-text encoded in the Tx receipt, and optionally also recorded in the transaction output to enable automated discovery.
-* **Address PubKey (APK)** — This is a public key encoded in the recipient's stealth address.  The goal of a stealth address scheme is to _not_ identify this public key in a transaction output.  The APK serves as a base point from which individual Tx output AuthKeys are computed.
-* **Tx Output Authorization Key (AuthKey)** — This public key will be recorded in the confidential transaction output (cTXO) as the key which is authorized to spend the commitment.  This key is offset from the APK by a secret offset that only the sender and recipient can calculate (from the shared secret between OTK and APK).  The sender knows only the offset between APK and AuthKey, but not the full secret key to the AuthKey.  The recipient, knowing the private key behind the APK, can compute the private key to AuthKey and therefore can spend the commitment.
+* **One-Time Key (OTK)** — The sender generates this key (public and private) from randomness and uses it to generate a shared-secret between the OTK and the recipient's Address ViewKey.  The OTK PubKey will be clear-text encoded in the Tx receipt, and optionally also recorded in the transaction output to enable automated discovery.
+* **Address Key(s) (ViewKey and SpendKey)** — These are public keys encoded in the recipient's stealth address.  The goal of a stealth address scheme is to _not_ identify these public keys in any transaction output.  A long-form address encodes _two_ public keys, referred to as ViewKey and SpendKey. The SpendKey serves as a base point from which individual Tx output AuthKeys are computed as an offset, and the ViewKey is used with the OTK to compute the offset.  A short-form address encodes only a single public key, which serves as both the ViewKey and SpendKey.
+* **Tx Output Authorization Key (AuthKey)** — This public key will be recorded in the confidential transaction output (cTXO) as the key which is authorized to spend the commitment.  This key is offset from the address SpendKey by a secret offset that only the sender and recipient can calculate (from the shared secret between OTK and ViewKey).  The sender can only know the offset, but not the full secret key to the AuthKey.  The recipient, knowing the private key behind the SpendKey, can compute the private key to AuthKey and therefore can spend the commitment.
 
 Automated discovery could be enabled if the receipt were embedded within the transaction data structure and if an aspect of that data structure supported a challenge condition which the recipient could recognize.
 
-The current implementation allows for a receipt to be embedded in each Tx output via a `stealth_memo` field which is formatted in the same way as the encrypted memos that may accompany regular (non-Stealth) transfer operations. These memos are composed of a header specifying the OTK PubKey and the "message PubKey" for which the recipient holds the corresponding private key, followed by cipher text which is AES encrypted with a shared-secret key between the OTK and the message PubKey.  For the `stealth_memo`, the current behavior of the CLI reference wallet is to use the recipient's Address PubKey (APK) as the message PubKey.  Although this is a reasonable choice for encrypting the message text, identifying the recipient's APK in the memo header breaks anonymity and completely negates the unlinkability provided by using a stealth address scheme.  For this reason, the CLI reference wallet does _NOT_ actually embed the memo in the Tx ouput but instead Base58 encodes it and prints it to the screen, calling it a "transaction receipt." The sender must manually, and secretly, transmit this to the recipient via a side channel.
+Current network rules allow for a receipt to be embedded in each Tx output via a `stealth_memo` field which is formatted in a similar way as the encrypted memos that may accompany regular (non-Stealth) transfer operations. These memos are composed of a header specifying the OTK PubKey and the "message PubKey" for which the recipient holds the corresponding private key, followed by cipher text which is AES encrypted with a shared-secret key between the OTK and the message PubKey.  For this `stealth_memo` field, the current behavior of the CLI reference wallet is to use the recipient's Address PubKey as the message PubKey.  Although this is a reasonable choice for encrypting message text generally, it has the severe downside of identifying the recipient's Address PubKey in the memo header, and therefor breaks anonymity and negates the unlinkability provided by using a stealth address scheme.  For this reason, the CLI reference wallet currently does _NOT_ actually embed the memo in the Tx ouput but instead Base58 encodes it and prints it to the screen, calling it a "transaction receipt." The sender must manually, and secretly, transmit this to the recipient via a side channel.
 
-**Stealth Memo structure:**
+**Stealth Memo structure: (Stealth I)**
 
 <span></span> | <span></span>
 -----: | :---
@@ -40,9 +40,9 @@ The current implementation allows for a receipt to be embedded in each Tx output
 **Message PubKey:** |  Public key controlled by recipient. &nbsp; **_(33 bytes)_**<br>
 **Cipher Text:** | AES encrypted message, using _key &leftarrow; Shared(OTK,MPK)_
 
-_Note: Present behavior is to use the Address PubKey as the message PubKey, which reveals intended recipient!!_
+_Current Stealth I behavior is to use the Address PubKey as the message PubKey, which reveals intended recipient!!_
 
-A very simple solution would be to change the behavior of using the APK as the message PubKey, and instead to use the Tx output AuthKey as the message PubKey.  Because the recipient is able to derive the private key behind the AuthKey through knowledge of the OTK PubKey and the recipient's APK, the recipient would simply need to test the OTK against each of their APK private keys to see if the resulting AuthKey matches the message PubKey.  If it does, then the output is recognized as destined to the recipient, even though the recipient's Address PubKey is not identified in the memo header.  The computational cost of this is one Diffie Hellman round, a hash operation, and a child key derivation.
+A very simple solution would be to change the behavior of embedding the Address PubKey in the message PubKey field, and to instead record the Tx output AuthKey in this slot.  Because the recipient is also able to derive this AuthKey through knowledge of her own address private keys (in combination with the OTK recorded in the header), the recipient would simply need to test the OTK against each of their own Address Keys to see if the resulting AuthKey matches the one in the header.  If it does, then the output is recognized as destined to the recipient, even though the recipient's Address PubKeys are not identified in the memo header.  The computational cost of this is one Diffie Hellman round, a hash operation, and a child key derivation.  It should be noted that the AES encryption key should still be computed from the shared secret between the OTK and the address ViewKey, however, as this will still allow view-only wallets which cannot compute the private key behind the AuthKey to decrypt the memo and tally the incoming transaction.
 
 To support this strategy, a wallet will need to inspect all cTX activity on the network and test the challenge conditions on each transaction.  This could be achieved if API nodes are extended to provide an API call to retrieve `stealth_memo` fields from all cTXOs appearing in a specified block range.  The wallet could simply download the memos, test the challenge on each one, and identify and decrypt the ones that are destined to the wallet.  No need would remain to manually transmit transaction receipts.  The receipts would be embedded, compactly and unlinkably, in the Tx outputs.