diff --git a/bip-invoicerequest-extension.mediawiki b/bip-invoicerequest-extension.mediawiki
index ff033d84..60e2d856 100644
--- a/bip-invoicerequest-extension.mediawiki
+++ b/bip-invoicerequest-extension.mediawiki
@@ -39,6 +39,13 @@ 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.
+==Definitions==
+{| class="wikitable"
+| Sender || Entity wishing to transfer value that they control
+|-
+| Receiver || Entity receiving a value transfer
+|}
+
==Example Use Cases==
1. Address Book
@@ -76,13 +83,6 @@ With this BIP, returned payment information is encrypted with an ECDH-computed s
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"
-| Sender || Entity wishing to transfer value that they control
-|-
-| Receiver || Entity receiving a value transfer
-|}
-
==New Messages==
===EncryptedInvoiceRequest===
@@ -159,15 +159,13 @@ message EncryptedPaymentRequest {
| payment_request_hash || SHA256 Hash of Non-Encrypted, Serialized PaymentRequest
|}
-==Encrypted InvoiceRequest / PaymentRequest Process==
-
-===Overview===
+==InvoiceRequest / PaymentRequest Process==
+The process overview for using InvoiceRequests and receiving encrypted PaymentRequests is defined below in two sections.
+Optionally, the Sender MAY choose to encrypt the InvoiceRequest message and therefore MUST follow the Encrypted InvoiceRequest Overview process.
+===Non-Encrypted InvoiceRequest Overview===
# Sender creates InvoiceRequest
-# Sender encrypts the InvoiceRequest
-# Sender creates EncryptedInvoiceRequest (containing an encrypted InvoiceRequest)
-# Sender transmits EncryptedInvoiceRequest to Receiver
-# Receiver decrypts and validates EncryptedPaymentRequest
+# Sender transmits InvoiceRequest to Receiver
# Receiver validates InvoiceRequest
# Receiver creates PaymentRequest
# Receiver encrypts the PaymentRequest
@@ -176,26 +174,50 @@ message EncryptedPaymentRequest {
# Sender validates EncryptedPaymentRequest
# Sender decrypts and validates encrypted PaymentRequest
-This overview flow is illustrated below:
+
-
+===Encrypted InvoiceRequest Overview===
+# Sender retrieves Receiver InvoiceRequest Public Key
+# Sender creates InvoiceRequest
+# Sender encrypts the InvoiceRequest
+# Sender creates EncryptedInvoiceRequest (containing an encrypted InvoiceRequest)
+# Sender transmits EncryptedInvoiceRequest to Receiver
+# Receiver decrypts and validates EncryptedInvoiceRequest
+# Receiver validates InvoiceRequest
+# Receiver creates PaymentRequest
+# Receiver encrypts the PaymentRequest
+# Receiver creates EncryptedPaymentRequest (containing an encrypted PaymentRequest)
+# Receiver transmits EncryptedPaymentRequest to Sender
+# Sender validates EncryptedPaymentRequest
+# Sender decrypts and validates encrypted PaymentRequest
-===Message Interaction Details===
+NOTE: See section Initial Public Key Retrieval for InvoiceRequest Encryption below for possible options to retrieve Receiver InvoiceRequet public keys.
+
+
+
+==Message Interaction Details==
===EncryptedInvoiceRequest===
-Sender MUST transmit EncryptedInvoiceRequest to Receiver (or Receiver's agent) via TLS-protected HTTP, Sender transmitting
+Sender MUST transmit EncryptedInvoiceRequest to Receiver (or Receiver's agent) via TLS-protected HTTP. Sender transmitting
EncryptedInvoiceRequest message MUST set appropriate Content-Type headers as specified here:
Content-Type: application/bitcoin-encrypted-invoicerequest-====EncryptedPaymentRequest==== +===InvoiceRequest=== +Sender MUST transmit InvoiceRequest to Receiver (or Receiver's agent) via TLS-protected HTTP. Sender transmitting +InvoiceRequest message MUST set appropriate Content-Type headers as specified here: +
Content-Type: application/bitcoin-invoicerequest+ +===EncryptedPaymentRequest=== Receiver MUST transmit EncryptedPaymentRequest to Sender (or Sender's agent) via TLS-protected HTTP. Receiver transmitting EncryptedPaymentRequest messages MUST set appropriate Content-Type headers as specified here:
Content-Type: application/bitcoin-encrypted-paymentrequest-====Message or Communication Errors==== +===Message or Communication Errors=== An invalid or unparsable message or communications error MUST be communicated to the party that initiated the communication. This SHOULD be done through standard HTTP Status Code messaging ([https://tools.ietf.org/html/rfc7231 RFC 7231 Section 6]). +==Process Step Details== + ===InvoiceRequest Message Creation=== * Create an InvoiceRequest message * sender_public_key MUST be set to the public key of an EC keypair diff --git a/bip-ir/encrypted-invoice-request-process.png b/bip-ir/encrypted-invoice-request-process.png new file mode 100644 index 00000000..beb5df1f Binary files /dev/null and b/bip-ir/encrypted-invoice-request-process.png differ diff --git a/bip-ir/invoice-request-process.png b/bip-ir/invoice-request-process.png new file mode 100644 index 00000000..47a4fac5 Binary files /dev/null and b/bip-ir/invoice-request-process.png differ