Explication of encrypted memo format

bsip-1203.md

@@ -94,6 +94,18 @@ _Field_ | _Purpose_
 
 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`. 
 
+Structure of `encrypted_memo`:
+
+_Field_ | _Purpose_
+-------:|:-------
+**`from_key`:** | Original use:<br><br><ul>Identifies address key of sender **(optional)**. &nbsp; _(EC curve point, 33 bytes)_</ul>Alternate possible uses:<br><br> <ul><li>Instead of ID'ing the 'from' address, could use this field to embed an _invoice nonce_ to allow receiver to correlate payment to an invoice.</li></ul>
+**`amount`:** | Value of commitment. &nbsp; _(Integer, 32 bytes)_
+**`blinding_factor`:** | Blinding factor. &nbsp; _(Integer, 32 bytes)_<br><br>_Note: Except when a blind_sum is needed, the blinding factor is deterministic from a hash of the shared secret, meaning this field can potentially be repurposed or omitted. To guarantee that the blinding factor can always be deterministic, transactions can be padded with a commitment to zero to absorb the blind_sum._
+**`commitment`:** | The Pedersen commitment. &nbsp; _(EC curve point, 33 bytes)_<br><br> _Note: This field is redundent, since the commitment is determined by_ C = amnt * H + blind * G, _and could potentially be omitted._
+**`check`:** | Checksum to confirm correct decryption. &nbsp; _(4 bytes)_
+
+_(TODO: How is this serialized? Do omitted fields "take up space"?  Can fields be chosen a la carte? How hard will it be to extend this memo format, for, say, multiple assets in the case of CA? See fc::raw::pack.)_
+
 #### Procedure for dual-key stealth addresses (CryptoNote-style)
 
 ##### Embedding recognizability data in the transaction