- Fix formatting + fix/add links

- Update images

bip-0075.mediawiki

@@ -30,9 +30,9 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 ==Motivation==
 
-The motivation for defining this extension to the BIP70 Payment Protocol is to allow 2 parties to exchange payment information in a permissioned and encrypted way such that wallet address communication can become a more automated process. Additionally, this extension allows for the requester of a PaymentRequest to supply a certificate and signature in order to facilitate identification for address release. This also allows for automated creation of off blockchain transaction logs that are human readable, containing who you transacted with, in addition to the information that it contains today.
+The motivation for defining this extension to the [[bip-0070.mediawiki|BIP70]] Payment Protocol is to allow 2 parties to exchange payment information in a permissioned and encrypted way such that wallet address communication can become a more automated process. Additionally, this extension allows for the requester of a PaymentRequest to supply a certificate and signature in order to facilitate identification for address release. This also allows for automated creation of off blockchain transaction logs that are human readable, containing who you transacted with, in addition to the information that it contains today.
 
-The motivation for this extension to BIP70 is threefold:
+The motivation for this extension to [[bip-0070.mediawiki|BIP70]] is threefold:
 
 # Ensure that the payment details can only be seen by the participants in the transaction, and not by any third party.  
 
@@ -58,7 +58,7 @@ With this BIP, Bitcoin wallets could maintain an "address book" that only needs
 
 2. Individual Permissioned Address Release
 
-A Bitcoin wallet developer would like to allow users to view a potential sending party's identifying information before deciding whether or not to share payment information with them. Currently, 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.
+A Bitcoin wallet developer would like to allow users to view a potential sending party's identifying information before deciding whether or not to share payment information with them. Currently, [[bip-0070.mediawiki|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 gives the receiving party more control over who receives their payment and identity information, and could be helpful for businesses that need to follow KYC policies or wallets that want to focus on privacy.
 
@@ -71,10 +71,10 @@ With this BIP, returned payment information is encrypted with an ECDH-computed s
 ==New Messages==
 Updated [/bip-0075/paymentrequest.proto paymentrequest.proto] contains the existing PaymentRequest Protocol Buffer messages as well as the messages newly defined in this BIP.
 
-Note: Public keys from both parties must be known to each other in order to facilitate encrypted communication. Although including both public keys in every message may get redundant, it provides the most flexibility as each message is completely self-contained.
+'''NOTE''': Public keys from both parties must be known to each other in order to facilitate encrypted communication. Although including both public keys in every message may get redundant, it provides the most flexibility as each message is completely self-contained.
 
 ===InvoiceRequest===
-The InvoiceRequest message allows a Sender to send information to the Receiver such that the Receiver can create and return a PaymentRequest.
+The '''InvoiceRequest''' message allows a Sender to send information to the Receiver such that the Receiver can create and return a PaymentRequest.
 
 <pre>
 message InvoiceRequest {
@@ -107,7 +107,7 @@ message InvoiceRequest {
 |}
 
 ===ProtocolMessageType Enum===
-The ProtocolMessageType enum is defined in an extensible way to allow for new message type additions to the Payment Protocol. This enum is used in the newly defined ProtocolMessage and EncryptedProtocolMessage messages to define the serialized message type.
+This enum is used in the newly defined [[#ProtocolMessage|ProtocolMessage]] and [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages to define the serialized message type. The '''ProtocolMessageType''' enum is defined in an extensible way to allow for new message type additions to the Payment Protocol.
 <pre>
 enum ProtocolMessageType {
     INVOICE_REQUEST = 0;
@@ -118,7 +118,7 @@ enum ProtocolMessageType {
 </pre>
 
 ===ProtocolMessage===
-The ProtocolMessage message is an encapsulating wrapper for any Payment Protocol message. It allows two-way, non-encrypted communication of Payment Protocol messages. The message also includes a status code and a status message that is used for error communication so the protocol does not rely on transport-layer error handling.
+The '''ProtocolMessage''' message is an encapsulating wrapper for any Payment Protocol message. It allows two-way, non-encrypted communication of Payment Protocol messages. The message also includes a status code and a status message that is used for error communication such that the protocol does not rely on transport-layer error handling.
 <pre>
 message ProtocolMessage {
     required ProtocolMessageType message_type = 1;
@@ -132,7 +132,7 @@ message ProtocolMessage {
 {| class="wikitable"
 ! Field Name !! Description
 |-
-|message_type               || Message Type of serialized_message (using enum ProtocolMessageType)
+|message_type               || Message Type of serialized_message
 |-
 |serialized_message         || Serialized Payment Protocol Message
 |-
@@ -144,7 +144,7 @@ message ProtocolMessage {
 |}
 
 ===EncryptedProtocolMessage===
-The EncryptedProtocolMessage message is an encapsualting wrapper for any Payment Protocol message. It allows two-way, authenticated and encrypted communication of Payment Protocol messages in order to keep their contents secret. The message also includes a status code and status message that is used for error communication so the protocol does not rely on transport-layer error handling.
+The '''EncryptedProtocolMessage''' message is an encapsualting wrapper for any Payment Protocol message. It allows two-way, authenticated and encrypted communication of Payment Protocol messages in order to keep their contents secret. The message also includes a status code and status message that is used for error communication such that the protocol does not rely on transport-layer error handling.
 <pre>
 message EncryptedProtocolMessage {
     required ProtocolMessageType message_type = 1;
@@ -160,6 +160,7 @@ message EncryptedProtocolMessage {
 </pre>
 {| class="wikitable"
 ! Field Name   !!  Description
+|-
 | message_type          || Message Type of Decrypted encrypted_message
 |-
 | encrypted_message     || AES-256-GCM Encrypted (as defined in BIP75) Payment Protocol Message
@@ -180,30 +181,28 @@ message EncryptedProtocolMessage {
 |}
 
 ==Payment Protocol Process with InvoiceRequests==
-The full process overview for using InvoiceRequests in the Payment Protocol is defined below. All Payment Protocol messages are to be encapsulated in either a ProtocolMessage or EncryptedProcotolMessage. Once the process begins using EncryptedProtocolMessage messages, all subsequent communications MUST use EncryptedProtocolMessages. All Payment Protocol messages SHOULD be communicated using EncryptedProtocolMessage encapsulating messages with the exception that an InvoiceRequest MAY be communicated using the ProtocolMessage if the receiver's public key is unknown.
+The full process overview for using '''InvoiceRequests''' in the Payment Protocol is defined below. All Payment Protocol messages MUST be encapsulated in either a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProcotolMessage|EncryptedProtocolMessage]. Once the process begins using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages, all subsequent communications MUST use [[#EncryptedProtocolMessage|EncryptedProtocolMessages]]. All Payment Protocol messages SHOULD be communicated using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulating messages with the exception that an [[#InvoiceRequest|InvoiceRequest]] MAY be communicated using the [[#ProtocolMessage|ProtocolMessage]] if the receiver's public key is unknown.
 
-See [[Sending_Encrypted_Payment_Protocol_Messages_using_EncryptedProtocolMessages|Sending Encrypted Payment Protocol Messages using EncryptedProtocolMessages]] and [[Validating_and_Decrypting_Payment_Protocol_Messages_using_EncryptedProtocolMessages|Validating and Decrypting Payment Protocol Messages using EncryptedProtocolMessages]] for the process of communicating using encrypted Payment Protocol messages.
-
-TODO: See about adding some info about using ProtocolMessages
+The process of communicating using encrypted Payment Protocol messages is enumerated in [[#Sending_Encrypted_Payment_Protocol_Messages_using_EncryptedProtocolMessages|Sending Encrypted Payment Protocol Messages using EncryptedProtocolMessages]] and [[#Validating_and_Decrypting_Payment_Protocol_Messages_using_EncryptedProtocolMessages|Validating and Decrypting Payment Protocol Messages using EncryptedProtocolMessages]].
 
 # Sender creates InvoiceRequest
 # Sender encapsulates InvoiceRequest in (Encrypted)ProtocolMessage
 # Sender sends (Encrypted)ProtocolMessage to Receiver
-# Receiver retrieves InvoiceRequest from (Encrypted)ProtocolMessage
+# Receiver retrieves InvoiceRequest in (Encrypted)ProtocolMessage from Sender
 # Receiver creates PaymentRequest
 # Receiver encapsulates PaymentRequest in EncryptedProtocolMessage
 # Receiver transmits EncryptedProtocolMessage to Sender
-# Sender validates PaymentRequest
-# The PaymentRequest is processed according to BIP70, including optional Payment and PaymentACK messages encapsulated in EncryptedProtocolMessage messages.
+# Sender validates PaymentRequest retrieved from the EncryptedProtocolMessage
+# The PaymentRequest is processed according to [[bip-0070.mediawiki|BIP70]], including optional Payment and PaymentACK messages encapsulated in EncryptedProtocolMessage messages.
 
-'''NOTE:''' See section [[#Initial_Public_Key_Retrieval_for_InvoiceRequest_Encryption|Initial Public Key Retrieval for InvoiceRequest Encryption]] below for possible options to retrieve Receiver's public key.
+'''NOTE:''' See section [[#Initial_Public_Key_Retrieval_for_InvoiceRequest_Encryption|Initial Public Key Retrieval for InvoiceRequest Encryption]] for possible options to retrieve Receiver's public key.
  
 <img src="bip-0075/encrypted-invoice-request-process.png" alt="Flow diagram of Encrypted InvoiceRequest">
 
 ==Message Interaction Details==
 
-===New Message HTTP Content Types===
-When communicated via HTTP, these messages MUST be transmitted via TLS-protected HTTP using the appropriate Content-Type header as defined per message type here:
+===HTTP Content Types for New Message Types===
+When communicated via '''HTTP''', the listed messages MUST be transmitted via TLS-protected HTTP using the appropriate Content-Type header as defined here per message:
 {| class="wikitable"
 ! Message Type !! Content Type
 |-
@@ -214,7 +213,9 @@ When communicated via HTTP, these messages MUST be transmitted via TLS-protected
 
 ===Payment Protocol Status Communication===
 
-In the case of an error that causes the Payment Protocol process to be stopped or retried for a transaction, a ProtocolMessage or EncryptedProtocolMessage MUST be sent by the party generating the error. The content of the message must contain the same serialized_message or encrypted_message and identifier (if used) and MUST have the status_code set appropriately. The status_message value SHOULD be set with a human readable explanation of the status code. For example, if in an EncryptedProtocolMessage, the provided hash of the serialized message does not match the contents of the message once decrypted, a general error (100) MUST be returned to prevent oracle attacks.
+In the case of an error that causes the Payment Protocol process to be stopped or requires that message be retried, a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] MUST be sent by the party generating the error. The content of the message MUST contain the same '''serialized_message''' or '''encrypted_message''' and identifier (if present) and MUST have the status_code set appropriately. 
+
+The status_message value SHOULD be set with a human readable explanation of the status code. For example, if in an [[#EncryptedProtocolMessage|EncryptedProtocolMessage]], the AES-256-GCM decryption fails to authenticate, an Authentication Failed (102) '''status_code''' MUST be returned to prevent oracle attacks.
 
 ====Payment Protocol Status Codes====
 {| class="wikitable"
@@ -248,54 +249,53 @@ In the case of an error that causes the Payment Protocol process to be stopped o
 |-
 |}
 
-===Communication Errors===
+===Transport Layer Communication Errors===
 
 Communications errors MUST be communicated to the party that initiated the communication via the communication layer's existing error messaging faciltiies. In the case of TLS-protected HTTP, this SHOULD be done through standard HTTP Status Code messaging ([https://tools.ietf.org/html/rfc7231 RFC 7231 Section 6]).
 
 ==New Process Details==
-This BIP extends the Payment Protocol as defined in BIP70.
+This BIP extends the Payment Protocol as defined in [[bip-0070.mediawiki|BIP70]].
 
 For the following we assume the Sender already knows the Receiver's public key, and the exchange is being facilitated by a Store & Forward server which requires valid signatures for authentication.
 
-Where used, '''nonce''' MUST be set to a non-repeating number AND MUST be chosen by the encryptor. The current epoch time in microseconds SHOULD be used, unless the creating device doesn't have access to a RTC (in the case of a smart card, for example). The service receiving the message containing the '''nonce''' MAY use whatever method to make sure that the '''nonce''' is never repeated.
+'''nonce''' MUST be set to a non-repeating number '''and''' MUST be chosen by the encryptor. The current epoch time in microseconds SHOULD be used, unless the creating device doesn't have access to a RTC (in the case of a smart card, for example). The service receiving the message containing the '''nonce''' MAY use whatever method to make sure that the '''nonce''' is never repeated.
 
 ===InvoiceRequest Message Creation===
-* Create an InvoiceRequest message
-* sender_public_key MUST be set to the public key of an EC keypair
-* Amount is optional. If the amount is not specified by the InvoiceRequest, the Receiver MAY specify the amount in the returned PaymentRequest. If an amount is specified by the InvoiceRequest and a PaymentRequest cannot be generated for that amount, the InvoiceRequest SHOULD return a PaymentRequest with the status_code and status_message fields set appropriately.
-* Memo is optional. This MAY be set to a human readable description of the InvoiceRequest
-* Set notification_url to URL that the Receiver will submit completed EncryptedPaymentRequest to
-* If NOT including certificate, set pki_type to "none"
+* Create an [[#InvoiceRequest|InvoiceRequest]] message
+* '''sender_public_key''' MUST be set to the public key of an EC keypair
+* '''amount''' is optional. If the amount is not specified by the [[#InvoiceRequest|InvoiceRequest]], the Receiver MAY specify the amount in the returned PaymentRequest. If an amount is specified by the [[#InvoiceRequest|InvoiceRequest]] and a PaymentRequest cannot be generated for that amount, the [[#InvoiceRequest|InvoiceRequest]] SHOULD return the same [[#InvoiceRequest|InvoiceRequest]] in a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] with the status_code and status_message fields set appropriately.
+* '''memo''' is optional. This MAY be set to a human readable description of the InvoiceRequest
+* Set '''notification_url''' to URL that the Receiver will submit completed PaymentRequest (encapsulated in an [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] to
+* If NOT including certificate, set '''pki_type''' to "none"
 * If including certificate:
-** Set pki_type to "x509+sha256"
-** Set pki_data as it would be set in BIP-0070 (see [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki#Certificates Certificates]) section)
-** Sign InvoiceRequest with signature = "" using the X509 Certificate's private key
-** Set signature value to the computed signature
+** Set '''pki_type''' to "x509+sha256"
+** Set '''pki_data''' as it would be set in BIP-0070 (see [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki#Certificates Certificates]) section)
+** Sign [[#InvoiceRequest|InvoiceRequest]] with signature = "" using the X509 Certificate's private key
+** Set '''signature''' value to the computed signature
 
 ===InvoiceRequest Validation===
-* Validate sender_public_key is a valid EC public key 
-* Validate notification_url if set, contains characters deemed valid for a URL (avoiding XSS related characters, etc).
-* If pki_type is None, InvoiceRequest is VALID
-* If pki_type is x509+sha256 and signature is valid for the serialized InvoiceRequest where signature is set to "", InvoiceRequest is VALID
+* Validate '''sender_public_key''' is a valid EC public key 
+* Validate '''notification_url''', if set, contains characters deemed valid for a URL (avoiding XSS related characters, etc).
+* If '''pki_type''' is None, [[#InvoiceRequest|InvoiceRequest]] is VALID
+* If '''pki_type''' is x509+sha256 and '''signature''' is valid for the serialized [[#InvoiceRequest|InvoiceRequest]] where signature is set to "", [[#InvoiceRequest|InvoiceRequest]] is VALID
 
 ===Sending Encrypted Payment Protocol Messages using EncryptedProtocolMessages===
 * Encrypt the serialized Payment Protocol message using AES-256-CBC setup as described in [[#ECDH_Point_Generation_and_AES256_GCM_Mode_Setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]] (see below)
-* Create EncryptedProtocolMessage message
-* Set encrypted_message to be the encrypted value of the Payment Protocol message
-* sender_public_key MUST be set to the public key of the Sender's EC keypair
-* receiver_public_key MUST be set to the public key of the Receiver's EC keypair
-* nonce MUST be set to the nonce used in the AES-256-CBC encryption operation
-* requires_payment_message MAY be set to true if the PaymentRequest requires a Payment message '''TODO: How are we doing this now?'''
-* Set identifier to the identifier value received in the originating InvoiceRequest's ProtocolMessage or EncryptedProtocolMessage wrapper message
-* Set signature to ""
-* Sign the serialized EncryptedProtocolMessage message with the communicating party's EC public key
-* Set signature to the result of the signature operation above
+* Create [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] message
+* Set '''encrypted_message''' to be the encrypted value of the Payment Protocol message
+* '''sender_public_key''' MUST be set to the public key of the Sender's EC keypair
+* '''receiver_public_key''' MUST be set to the public key of the Receiver's EC keypair
+* '''nonce''' MUST be set to the nonce used in the AES-256-CBC encryption operation
+* Set '''identifier''' to the identifier value received in the originating InvoiceRequest's ProtocolMessage or EncryptedProtocolMessage wrapper message
+* Set '''signature''' to ""
+* Sign the serialized [#EncryptedProtocolMessage|EncryptedProtocolMessage]] message with the communicating party's EC public key
+* Set '''signature''' to the result of the signature operation above
 
-'''SIGNATURE NOTE:''' EncryptedProtocolMessage messages are signed with the public keys of the party transmitting the message. This allows a Store & Forward server or other transmission system to prevent spam or other abuses. For those who are privacy conscious and don't want the server to track the interactions between two public keys, the Sender can generate a new public key for each interaction to keep their identity anonymous.
+'''SIGNATURE NOTE:''' [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages are signed with the public keys of the party transmitting the message. This allows a Store & Forward server or other transmission system to prevent spam or other abuses. For those who are privacy conscious and don't want the server to track the interactions between two public keys, the Sender can generate a new public key for each interaction to keep their identity anonymous.
 
 ===Validating and Decrypting Payment Protocol Messages using EncryptedProtocolMessages===
-* The nonce MUST not be repeated. The service receiving the InvoiceRequest MAY use whatever method to make sure that the nonce is never repeated.
-* Decrypt the serialized Payment Protocol message using AES-256-GCM setup as described in [[#ECDH_Point_Generation_and_AES256_GCM_Mode_Setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]] (see below)
+* The '''nonce''' MUST not be repeated. The service receiving the [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] MAY use whatever method to make sure that the nonce is never repeated.
+* Decrypt the serialized Payment Protocol message using AES-256-GCM setup as described in [[#ECDH_Point_Generation_and_AES256_GCM_Mode_Setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]]
 * Deserialize the serialized Payment Protocol message
 
 ===ECDH Point Generation and AES-256 (GCM Mode) Setup===
@@ -303,25 +303,27 @@ Where used, '''nonce''' MUST be set to a non-repeating number AND MUST be chosen
 * Generate the '''secret point''' using [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman ECDH] using the local entity's private key and the remote entity's public key as inputs.
 * Initialize [http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf HMAC_DRBG] 
 ** Use '''SHA256(secret point's X value)''' for Entropy
-** Use the given message's nonce field for Nonce
+** Use the given message's '''nonce''' field for Nonce
 * Initialize AES-256 in GCM Mode
 ** Use HMAC_DRBG.GENERATE(32) as the Encryption Key (256 bits)
 ** Use HMAC_DRBG.GENERATE(16) as the Initialization Vector (IV) (128 bits)
 
 ===Initial Public Key Retrieval for InvoiceRequest Encryption===
-Initial public key retrieval for InvoiceRequest encryption in EncryptedProtocolMessage can be done in a number of ways including, but not limited to, the following:
-* Wallet Name public key asset type resolution - DNSSEC-validated name resolution returns Base64 encoded DER-formatted EC public key via TXT Record [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
-* Key Server lookup - Key Server lookup (similar to PGP's pgp.mit.edu) based on key server identifier (i.e., e-mail address) returns Base64 encoded DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
-* QR Code - Use of QR-code to encode DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
-* Address Service Public Key Exposure
+Initial public key retrieval for [[#InvoiceRequest|InvoiceRequest]] encryption via [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulation can be done in a number of ways including, but not limited to, the following:
+# Wallet Name public key asset type resolution - DNSSEC-validated name resolution returns Base64 encoded DER-formatted EC public key via TXT Record [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
+# Key Server lookup - Key Server lookup (similar to PGP's pgp.mit.edu) based on key server identifier (i.e., e-mail address) returns Base64 encoded DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
+# QR Code - Use of QR-code to encode DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
+# Address Service Public Key Exposure
 
-==Payment / PaymentACK Messages with a Store & Forward Server==
-When a Store & Forward server is in use during the Payment Protocol exchange, a Payment message generated as the result of a PaymentRequest with the '''requires_payment_message''' (TODO: Should add something more generic to the encapsulating messages?) flag set to true MUST be accepted by a Store & Forward server. The accepted Payment message is NOT validated as the Store & Forward server does not have access to encrypted data.
+==Payment / PaymentACK Messages with a HTTP Store & Forward Server==
+A Store & Forward server SHOULD store PaymentRequest messages until either a timeout expires the message or a Payment message for the PaymentRequest message has been received. The timeout SHOULD be greater than 24 hours.
+
+When a Store & Forward server is used for a Payment Protocol exchange, a Payment message generated as the result of a PaymentRequest MUST be accepted by a Store & Forward server if the associated PaymentRequest message exists on the Store & Forward server, otherwise an HTTP 404 Not Found message should be returned. The accepted Payment message is NOT validated as the Store & Forward server does not have access to encrypted data.
 
 Store & Forward servers MAY accept and/or overwrite Payment messages until an PaymentACK message with matching identifier and valid Receiver signature is received, after which the server MAY reject all further Payment messages matching that identifier. This feature SHOULD be used for updating Payment metadata or replacing invalid transactions with valid ones. Clients SHOULD keep in mind Receivers can broadcast a transaction without returning an ACK. If a payment message needs to be updated, it SHOULD include at least one input referenced in the original transaction to prevent the Receiver from broadcasting both transactions and getting paid twice.
 
 ==Public Key & Signature Encoding==
-* All EC public keys (sender_public_key, receiver_public_key) included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded.
+* All EC public keys ('''sender_public_key''', '''receiver_public_key''') included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded.
 * All ECC signatures included in any message defined in this BIP MUST use the SHA-256 hashing algorithm and MUST be DER [ITU.X690.1994] encoded.
 
 ==Implementation==
@@ -334,26 +336,21 @@ A reference client implementation can be found in the InvoiceRequest functional
 [https://github.com/netkicorp/addressimo/blob/master/functest/functest_bip75.py BIP75 Client Reference Implementation]
 
 ==BIP70 Extension==
-The following flowchart is borrowed from BIP70 and expanded upon in order to visually describe how this BIP is an extension to BIP70.
+The following flowchart is borrowed from [[bip-0070.mediawiki|BIP70]] and expanded upon in order to visually describe how this BIP is an extension to [[bip-0070.mediawiki|BIP70]].
 
 <img src="bip-0075/bip70-extension.png" alt="Flowchart explaining how this BIP extends BIP 70">
 
 ==Mobile to Mobile Examples==
 
-===EncryptedPayment Required===
-The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client with the use of an InvoiceRequest, a Store & Forward server, an EncryptedPaymentRequest (with require_payment_message = true), an EncryptedPayment and an EncryptedPaymentACK. In this case, the Receiver submits the transaction to the Bitcoin network.
+===Full Payment Protocol===
+The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client with the use of an InvoiceRequest, a Store & Forward server, PaymentRequest, Payment and PaymentACK. In this case, the PaymentRequest, Payment and PaymentACK messages are encrypted using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] '''and''' the Receiver submits the transaction to the Bitcoin network.
 
-<img src="bip-0075/mobile-sf-ir-with-payment.png" alt="EncryptedPayment Required flow diagram">
+<img src="bip-0075/mobile-sf-ir-with-payment.png" alt="Payment Required flow diagram">
 
-===EncryptedPayment NOT Required===
-The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client with the use of an InvoiceRequest, a Store & Forward server, and an EncryptedPaymentRequest (with require_payment_message = false). In this case, the Sender submits the transaction to the Bitcoin network.
+===Encrypting Initial InvoiceRequest via EncryptedProtocolMessage===
+The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client using an [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] to transmit the InvoiceRequest using encryption, Store & Forward server, and PaymentRequest. In this case, all Payment Protocol messages are encrypting using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] '''and''' the Sender submits the transaction to the Bitcoin network.
 
-<img src="bip-0075/mobile-sf-ir-without-payment.png" alt="EncryptedPayment NOT Required flow diagram">
-
-===Using EncryptedInvoiceRequest Message===
-The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client with the use of an EncryptedInvoiceRequest, a Store & Forward server, and an EncryptedPaymentRequest (with require_payment_message = false). In this case, the Sender submits the transaction to the Bitcoin network.
-
-<img src="bip-0075/mobile-sf-encrypted-ir-without-payment.png" alt="EncryptedInvoiceRequest without payment">
+<img src="bip-0075/mobile-sf-encrypted-ir-without-payment.png" alt="Encrypted InvoiceRequest without payment">
 
 ==References==