Rewriting of Motivation section for clarity and specifics.

bsip-1203.md

@@ -20,15 +20,22 @@ _Keys involved in a cTX output (cTXO):_
 * **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 Auth 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.
 
-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.  (As one simple option, the ability to decrypt the receipt could be viewed as the challenge condition, although it may not be the most performant.)
+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 already allows, but does not require, receipts to be embedded in the transactions.  Additionally, an existing cleartext field allows (but does not require) the recipient to be identified via their blind address, which could serve to alert the recipient, but at the steep expense of sacrificing unlinkability and anonymity.
+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.
 
-It is proposed to repurpose and perhaps extend the cleartext fields to contain a challenge condition, rather than cleartext address, which recipients can efficiently use to flag inbound transactions while still maintaining unlinkability and anonymity.
+**Stealth Memo structure:**
 
-To support this, a wallet will need to either (a) inspect all cTX activity on the network and test the challenge conditions on each transaction, or (b) transmit to the API node some kernel of the challenge so that the API node can select an inclusive cTXO set on behalf of the wallet. (The latter option likely undermines unlinkability, although it would lessen the burden on the receiving wallet.)
+<span></span> | <span></span>
+-----: | :---
+**One-time PubKey:** | Chosen from randomness by sender &nbsp; **_(33 bytes)_**
+**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!!_
 
-Additionally, the WS/RPC API offered by network nodes will need to be extended to support returning ranges of cTXOs occuring within specified block ranges, so that wallets can scan them.  (Currently, cTXOs can *only* be looked up by Pedersen commitment, which for a new inbound transaction, would not yet be known to the wallet.)
+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.
+
+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.
 
 ## Rationale
 ## Specifications