Update payment disclosure draft ZIP based on comments.

drafts/bitcartel-payment-disclosure/draft.rst

@@ -73,19 +73,19 @@ The payment disclosure does not prove that the party presenting the payment disc
 
 To mitigate against a replay attack, the recipient could enforce a policy where the first person to present a given payment disclosure is the honest sender.
 
-To prevent a man-in-the-middle attack, the recipient could pose an interactive challenge involving some out-of-band secret which only the sender would pass.
+[TODO: Example?] To prevent a man-in-the-middle attack, the recipient could pose an interactive challenge involving some out-of-band secret which only the sender would pass successfully.
 
 A non-interactive solution is also possible:
 
 #. The sender includes data, such as a refund address, in the memo field of a payment to a shielded address.  The memo field is non-malleable as it is part of the data signed by the sender when creating JoinSplitSig [PROTOCOL] §4.1.6 Signatures.  Currently, the public key to verify the signature is stored in the blockchain along with the transaction.
 #. When presenting the payment disclosure to a recepient, the sender signs the payment disclosure with the JoinSplitSig private key which only they would know.  The JoinSplitSig key pair is ephemeral and normally discarded but the method described in this ZIP will retain the private portion.  The recipient can then use the public key to verify the signed disclosure.
 
-Using the JoinSplitSig key pair in this way also means that a sender can make payments without having to first provide a refund address or other detail at the time of the original payment.  If at later date the sender and recipient need to confirm the payment, the sender can sign and send any data required to the recipient, who can in turn verify it.
+Using the JoinSplitSig key pair in this way also means that a sender can make payments without having to first provide a refund address or other details at the time of the original payment.  If at a later date the sender and recipient need to confirm the payment, the sender can sign and send any data required to the recipient, who can in turn verify it.
 
 
 Known Issues
 ------------
-Both plaintext outputs of a joinsplit are currently encrypted with the same ephemeral secret key. (TODO: Is there an existing ticket which explains the rationale for this?)
+Both plaintext outputs of a joinsplit are currently encrypted with symmetric keys derived from the same ephemeral secret key, as discusshed here: https://github.com/zcash/zcash/issues/558#issuecomment-167819936
 
 This means that a payment disclosure which includes the ephemeral secret key intended to decipher the note ciphertext belonging to a particular joinsplit output, creates a privacy leak by also deciphering the other joinsplit output and revealing it's amount and payment address.
 
@@ -97,7 +97,7 @@ Note the current implementation of the ``z_sendmany`` RPC call:
 
 A proposal to prevent information leakage of change addresses is currently under development [KDFT].  TODO: Does this block ZIP approval?
 
-Alao note that an independent third party cannot know for sure if the sender and recipient are not colluding to hide value transfer.  JoinSplits have two inputs and two outputs.  The recipient may identify their receiving address for one output, but not disclose the fact that the other output also belongs to them.
+Also note that an independent third party cannot know for sure if the sender and recipient are not colluding to hide value transfer.  JoinSplits have two inputs and two outputs.  The recipient may identify their receiving address for one output, but not disclose the fact that the other output also belongs to them.
 
 TODO: What happens if a transaction is created (at which point a payment disclosure can be created) but never gets mined and is stuck in the mempool?  Should the payment disclosure be retained or purged?
 
@@ -134,7 +134,7 @@ A new RPC call will be introduced to allow the sender to retrieve the payment di
 - Returns the payment disclosure in hexadecimal format.
 - Message is an optional parameter, a UTF-8 string.  We may want to restrict/sanitize this user input, e.g. number of characters, allowed characters.
 
-The sender want sthe payment disclosure to be non-malleable, to prevent an attacker modifying details like the refund address.  To achieve this, the sender will sign the payment disclosure with the JoinSplitSig private key and append the signature to the end of the payment disclosure data.
+The sender wants the payment disclosure to be non-malleable, to prevent an attacker modifying details like the refund address.  To achieve this, the sender will sign the payment disclosure with the JoinSplitSig private key and append the signature to the end of the payment disclosure data.
 
 A new RPC call will be introduced to allow a third party to verify a payment disclosure.