Clarity edits in Specifications section.

bsip-1203.md

@@ -68,7 +68,7 @@ And in the second subsection, [_API requirements..._](#api-requirements-to-allow
 
 Assumptions:
 
-1. Wallet has access to a set of private keys corresponding to stealth addresses which may own commitments on the blockchain.  These private keys are needed to "recognize" incoming transactions.  If the wallet is a watch-only wallet for a particular address, then it is assumed to have the private ViewKey, but only the public SpendKey.
+1. Wallet has access to a set of private keys corresponding to stealth addresses which may own commitments on the blockchain.  These private keys are needed to "recognize" incoming transactions.  If the wallet is a watch-only wallet for a particular address, then it is assumed to have the private and public ViewKey, but only the public SpendKey.
 2. Wallet can query an API node for commitments occurring between specified block heights, to obtain sets of embedded receipts to scan for owned commitments. ([See below](#api-requirements-to-allow-detection-of-inbound-commitments) for this process.)
 
 We detail procedures for stealth address formats which encode either a single public key, or two distinct public keys in which one key is the ViewKey and the other the SpendKey. The single-key format is already in use on the BitShares network and is borrowed from the original Confidential Transactions specification. The dual-key format allows for additional wallet features and is borrowed from CryptoNote-based coins such as Monero.  No changes to the network nodes are required for wallets to support dual-key address formats.  In fact, the single-key format can be thought of as a special case of the dual-key format in which the same key is used as the ViewKey and the SpendKey.
@@ -92,11 +92,11 @@ Recognizability depends on there being a deterministic relationship between the
 
 We assume that the stealth address encodes public keys corresponding to two purposes: discovery, and expenditure.  When an address encodes only one public key, that key is used for both purposes. We refer to the key for discovery as the "view" key, and denote the private, public pair as _(v, ViewKey)_.  For spending, we denote the key pair as _(s, SpendKey)_.
 
-The AuthKey for a cTXO is an EC point summation of the address's SpendKey and an EC point "offset," which, for present purposes we will denote by the private, public pair _(o, Offset)_, with _Offset = o*G_.
+The AuthKey for a cTXO is an EC point summation of the address's SpendKey and an EC point "offset," which, for present purposes we will denote by the private, public pair _(o, Offset)_, with _Offset = o*G_, where _G_ is the generator point for the curve.
 
   _AuthKey  =  SpendKey  +  Offset_
 
-Anonymity is preserved so long as only the sender and the receiver are able to compute _o_ and _Offset_.  The algorithm for computing _Offset_ is a deterministic function of the OTK and ViewKey only, (and not the SpendKey).  This allows the the recipient to recover the SpendKey by simple subtraction of _Offset_ from the AuthKey and compare against a list of SpendKeys that the wallet may have used to generate an address family with a common ViewKey. (See _[address-per-invoice](#utility-of-dual-key-addresses)_ below.)
+Anonymity is preserved so long as only the sender and the receiver are able to compute _o_ and _Offset_.  The algorithm for computing _Offset_ is a deterministic function of the OTK and ViewKey only, (and not the SpendKey).  This allows the the recipient to recover the SpendKey by simple subtraction of _Offset_ from the AuthKey.  The recipient's wallet then compares the computed SpendKey against the address SpendKey.  The wallet may even compare against a whole list of SpendKeys that the wallet may have used to generate an address family with a common ViewKey, allowing for differentiable invoices, without sacrificing efficiency of scanning. (See _[address-per-invoice](#utility-of-dual-key-addresses)_ below.)
 
 Algorithm | Description / Specification
 :---:|:---------------------------
@@ -111,6 +111,8 @@ The sender's procedure for computing the offset and generating the AuthKey for t
 <li> Compute a "shared secret" between between the sender and receiver:
 
 _secret = Shared(otk, ViewKey)_
+
+The sender must be careful to leak neither the shared shared secret nor the private _otk_ key.
 </li>
 <li> Compute the OffsetKey as a child of the ViewKey, indexed by the shared secret:
 
@@ -152,7 +154,7 @@ Thus, a wallet may undertake to periodically download and scan the metadata for
 
 ##### Embedding recognizability data in the transaction
 
-For the recipient to have the practical ability to recognize a cTXO as their own, the cTXO, as recorded on the blockchain, must include the following two items: 1.) The one-time PubKey (OTK) that the sender generated for shared-secret generation, and, 2.) the authorization PubKey (AuthKey) of the cTXO.  Because the AuthKey is computed deterministically from _Shared(OTK,AddrKey)_, it stands that if the recipient can generate the same AuthKey, and thereby determine that the cTXO belongs to them.
+For the recipient to have the practical ability to recognize a cTXO as their own, the cTXO, as recorded on the blockchain, must include the following two items: 1.) The one-time PubKey (OTK) that the sender generated for shared-secret generation, and, 2.) the authorization PubKey (AuthKey) of the cTXO.  Because the AuthKey is computed deterministically from _Shared(OTK,AddrKey)_, it stands that if the recipient can generate the same AuthKey, then the cTXO belongs to them.
 
 The structure of a cTXO is as follows:
 
@@ -163,9 +165,9 @@ _Field_ | _Purpose_
 **`owner`:** | BitShares owner structure specifying weighted list of keys or accounts that may spend this commitment. (Typically lists just one public key, the "AuthKey" for the cTXO.)
 **`stealth_memo`:** | Also known as the "transaction receipt" when transmitted off-chain.<br><br> **`one_time_key`:** &nbsp; _(EC curve point, 33 bytes)_<br> **`to`:** &nbsp; Use the AuthKey here! _(EC curve point, 33 bytes)_<br> **`encrypted_memo`:** &nbsp; Data that recipient needs to "open" the commitment.<br><br> _The stealth memo is optional as far as the network is concerned, but essential if you want the recipient to be able to detect the incoming transaction without sending a "receipt."_
 
-_(An example transaction showing all these fields can be seen in [block 22157273](https://cryptofresh.com/tx/8182e9d78cbce7df281bc252a9e6d87566ca0622). In this Tx, the stealth_memo '`to`' field names the recipient's address key, rather than the cTXO Auth key, and thus breaks unlinkability.)_
+_(An example transaction showing all these fields can be seen in [block 22157273](https://cryptofresh.com/tx/8182e9d78cbce7df281bc252a9e6d87566ca0622). In this Tx, the stealth_memo '`to`' field unwisely names the recipient's address key, rather than the cTXO Auth key, and thus breaks unlinkability.)_
 
-Since the `stealth_memo` field can be used to record both the OTK and the AuthKey, all the wallet needs to do to scan for incoming transactions is to download batches of stealth memos and, for each one, test whether the combination of the OTK and the wallet's Address key yields the AuthKey.  If it does, then use then derive the AES decryption key from _Shared(OTK,AuthKey)_ and use that to read the additional data in `encrypted_memo`. 
+Since the `stealth_memo` field can be used to record both the OTK and the AuthKey, all the wallet needs to do to scan for incoming transactions is to download batches of stealth memos and, for each one, test whether the combination of the OTK and the wallet's Address key yields the AuthKey.  If it does, then derive the AES decryption key from _Shared(OTK,ViewKey)_ and use that to read the additional data in `encrypted_memo`. 
 
 Structure of `encrypted_memo`:
 
@@ -212,6 +214,12 @@ Another use case for an extended address format would be... (TODO: Discuss inclu
 
 ### Pitfalls and Cautions
 
+#### Specific risks and remedies
+
+##### Sender leaks private _otk_ or private _shared secret_:
+
+TODO: analyze
+
 #### An attack on address key from leak of a transaction private key
 
 A confidential output will have associated with it an "Output PubKey." He who can provide a signature from that PubKey is authorized to spend the commitment.  Automated detection of inbound commitments depends on the deterministic computation of an offset between the One-time PubKey and the Address PubKey, which is computed from the shared secret between the sender and receiver.  Because only the offset is deterministic, the sender cannot compute the private key to the Output PubKey.  Only the receiver can do this (by knowing both the offset and the Address private key).