[ZIP-231] Add Newsletter, Reply-to and Application Layer Use Cases

zips/zip-0231.md

@@ -75,7 +75,7 @@ hides the sender(s) (that is, the addresses corresponding to the keys used to
 spend the input notes) from all of the recipients. For certain kinds of
 transactions, it is desirable to make one or more sender addresses available to
 one or more recipients (for example, a reply address). In such circumstances it
-is important to authenticate the sender address(es), to give the recipient a
+is important to authenticate the sender addresses, to give the recipient a
 guarantee that the address is controlled by a sender of the transaction;
 failure to authenticate this address can enable phishing attacks. These
 Authenticated Reply Addresses require zero-knowledge proofs, and for the
@@ -119,6 +119,61 @@ recipient. By separating memo data from the decryption capability for those
 memos, it admits a greater variety of applications that utilize memo data,
 while decreasing the amount of data that needs to be stored on-chain overall.
 
+# Use Cases
+
+## Authenticated Reply-to addresses
+In a peer-to-peer transaction Bob and Alice can split a lunch check. 
+Bob can send a shielded memo to Alice that says "Nice Lunch! It was fun! this 
+is my half + tips. Hugs, Bob.". Bob would show Alice his transaction detail in 
+his wallet and Alice can visibly check hers and verify that the memo contained 
+in that transaction was authored by Bob. That in-person manual verification 
+process is only valid for that one transaction. Anyone that knows Alice's address
+and the fact that she exchanged messages over Zcash memos with Bob could spoof a
+shielded memo impersonating Bob. Neither Alice or her wallet have an aid to judge 
+the authorship of any of the received messages. 
+
+If Bob's wallet had the capability to prove the authorship of a message, Alice's
+wallet could help her notice such a spoofing attempt. The rationale of this use case 
+is that application developers can use this mechanism to build a user experience
+that can help users tell apart trustworthy memos from those whose origin cannot 
+be certainly determined. 
+
+It has to be noted that providing a mechanism for wallet applications to attach 
+data that can help prove the origin of a transaction through the memo field will
+not prevent that spoofers attempt such attacks. Spoofers continue to send memos 
+to attempt to deceive a user. The proving data is not self-sufficient to determine 
+that the author of a shielded memo shall be trusted. Further verification 
+steps would be needed to determine a such a level of trust. This specification 
+enables wallet developers to build a user experience that helps Zcash wallet
+users to identify authentic memos containing Reply-to addresses from spoofed ones.
+The definition of such UX is outside of the scope of this ZIP.
+
+## Memos as input for application layer
+Using unverifiable memo data as input for business logic is unadvisable. 
+Repeatedly, application developers have discussed memos an on-chain data layer for 
+privacy-minded software such as Instant (or ansynchronous) messaging applications
+or marketplaces. These applications require that the memo information can
+be _trusted_ and therefore be treated as _actionable_ data by the application
+business logic. Without such a mechanism the application does not have a way to 
+choose which messages should be trusted and which ones shall be ignored. The 
+ability to attach proofs to memos provides application developers with mechanisms
+to distinguish plausible user intent from arbitrary memos generated outside the 
+application domain.
+
+## Broadcasting a newsletter
+The ZecHub DAO runs a "Shielded Newsletter" service [^shielded-newsletter]. Users subscribe by sending a
+one-time transaction with a subscription fee and a shielded memo that tells the 
+service where to send the newsletter to. As discussed in the motivation section, 
+Memo bundles will help the newsletter service to avoid chain bloat by enabling 
+subscribers to share a single key to decrypt a single memo instead of sending 
+individual memos to each one of them. Additionally, by requiring subscribers to 
+prove the authorship of their subscription memos, the newsletter can verify that
+the recipient address indicated in the one-time subscription memo is indeed the
+author of the subscription and not a subscription bot attempting to perform a pseudospoofing
+attack against the service. Finally, the newsletter service can require one-time
+unsubscribe messages to attach a proof-of-authorship that proves that the sender
+owns spend authority over the address that the unsubcription is being requested
+for.
 
 # Privacy Implications
 
@@ -816,3 +871,5 @@ TBD
 [^pczt]: [zcash/zips issue #693: Standardize a protocol for creating shielded transactions offline](https://github.com/zcash/zips/issues/693)
 
 [^rfc-8439]: [RFC 8439: ChaCha20 and Poly1305 for IETF Protocols](https://www.rfc-editor.org/rfc/rfc8439.html)
+
+[^shielded-newsletter]: [ZecHub Shielded Newsletter](https://zechub.wiki/newsletter)