- Update e-mail addresses for Justin and Matt

- Add 2 new use cases and add Wallet Name to the Address Book section of optional ways to add entries to an address book

bip-invoicerequest-extension.mediawiki

@@ -1,8 +1,8 @@
 <pre>
   BIP:     XXX
   Title:   Out of Band Address Exchange using Encrypted PaymentRequests
-  Authors: Matt David <matt@netki.com>
+  Authors: Justin Newton <justin@gid.net>
-           Justin Newton <justin@netki.com>
+           Matt David <mgd@mgddev.com>
            Aaron Voisine <voisine@gmail.com>
            James MacWhyte <macwhyte@gmail.com>
   Status:  Draft
@@ -39,11 +39,42 @@ The motivation for this extension to BIP70 is twofold:
 
 In short we wanted to make bitcoin more human, while at the same time improving transaction privacy.
 
-==Example Use Case==
+==Example Use Cases==
 
-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.
+# Address Book
 
-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.
+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 using a Wallet Name, 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.
+
+# Individual Permissioned Address Release
+
+Let's say a Bitcoin wallet developer would like to offer the ability for a user to individually release address information 
+to a new potential sending party only if they can confirm the identity of the potential sending party. BIP70 specifies that 
+the Merchant Server respond to a "pay now" style request with a PaymentRequest, releasing address and X.509 certificate identity 
+information of the potential receiving party.
+
+With this BIP, Bitcoin wallets could prompt a wallet user to release payment information while displaying identity 
+information about the potential sending party via an included certificate. This allows the potential receiving party to 
+make a more informed decision regarding to whom they are releasing payment and identity information.
+
+# Using Store & Forward Servers
+
+Let's say a Bitcoin wallet developer would like to use a public Store & Forward service for an asynchronous address 
+exchange. This is a common case for mobile and offline wallets.
+
+With this BIP, returned payment information is encrypted with an ECDH-computed shared key before sending to a Store & Forward 
+service. In this case, a successful attack against a Store & Forward service would not be able to read or modify wallet address 
+or payment information, only delete encrypted messages.
 
 ==Definitions==
 {| class="wikitable"