Merge pull request #3 from jmacwhyte/proofread

Added example use case.

Author: techguy613

bip-invoicerequest-extension.mediawiki

@@ -35,10 +35,16 @@ The motivation for this extension to BIP70 is twofold:
 * Give the user the ability to decide who to release payment details to 
 * Allow an entity such as a political campaign to ensure donors match regulatory and legal requirements 
 * Allow for an open standards based way to meet regulatory requirements
-* Automate the creation and maintenance of an "address book" of payees, without relying on static addresses or BIP32 X-Pubs which can become outdated and/or compromise privacy
+* Automate the active exchange of payment addresses, so static addresses and BIP32 X-Pubs can be avoided to maintain privacy and convenience
 
 In short we wanted to make bitcoin more human, while at the same time improving transaction privacy.
 
+==Example Use Case==
+
+Let's say a Bitcoin wallet developer would like to offer the ability to store an "address book" of payees, so users could send multiple payments to known entities without having to request an address every time. Static addresses compromise privacy, and address reuse is considered a security risk. BIP32 X-Pubs allow the generation of unique addresses, but watching an X-Pub chain for each person you wish to receive funds from is too resource-intensive for mobile applications, and there is always the risk of unknowingly sending funds to an X-Pub address after the owner has lost access to the corresponding private key.
+
+With this BIP, Bitcoin wallets could maintain an "address book" that only needs to store each payee's public key. Adding an entry to one's address book could be done by scanning a QR code, sending a URI through a text message or e-mail, or searching a public repository. When the user wishes to make a payment, their wallet would do all the work in the background to communicate with the payee's wallet to receive a unique payment address. If the payee's wallet has been lost, replaced, or destroyed, no communication will be possible, and the sending of funds to a "dead" address is prevented.
+
 ==Definitions==
 {| class="wikitable"
 | Sender    || Entity wishing to transfer value that they control