Formatting improvements to BIP-75

 * Fixing a few extra closing `b` tags and converting others to wiki bold syntax.
 * Linking "see below" and "see above" items to the actual section of the BIP.
 * Consistent capitalization of "Bitcoin".
 * "requester" => "requester* (more common outside of legal writing)
 * "concious" => "conscious"
 * "Foward" => "Forward"
 * "Satoshis" => "satoshis" (as unit of bitcoin, not the name of creator)
 * Removing unnecessary </img> which can actually cause problems.
 * Adding required `alt` attribute to img tags.
 * Fix wrapping of long lines (some were wrapped at 112 chars) - No effect on final rendering users see.

1 files changed, 38 insertions, 60 deletions

diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki
index e71058f..3075dd3 100644
--- a/bip-0075.mediawiki
+++ b/bip-0075.mediawiki
@@ -14,7 +14,7 @@
 
 This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol.
 
-# It allows the requestor (Sender) of a Payment Request to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with. 
+# It allows the requester (Sender) of a Payment Request to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with. 
 
 # It encrypts the Payment Request that is returned, before handing it off to the SSL/TLS layer to prevent man in the middle viewing of the Payment Request details.
 
@@ -30,7 +30,7 @@ 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 requestor 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 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:
 
@@ -40,50 +40,36 @@ The motivation for this extension to BIP70 is threefold:
 
 # Allow a sender of funds the option of sharing their identity with the receiver.  This information could then be used to:
 
-#* Make bitcoin logs more human readable 
+#* Make Bitcoin logs more human readable 
 #* 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 for regulated financial entities to meet regulatory requirements
 #* 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.
+In short we wanted to make Bitcoin more human, while at the same time improving transaction privacy.
 
 ==Example Use Cases==
 
 1. Address Book
 
-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 a risk of unknowingly sending funds to an X-Pub address after the owner has lost access to the 
-corresponding private key.
+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 a 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.
+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.
 
 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.
 
-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.
+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.
 
 3. Using Store & Forward Servers
 
-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.
+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.
+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.
 
 ==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.
+Updated [/bip-0075/paymentrequest.proto paymentrequest.proto] contains the existing PaymentRequest Protocol Buffer messages as well asthe 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.
 
@@ -115,7 +101,7 @@ message InvoiceRequest {
 |-
 | memo                  || Human-readable description of invoice request for the receiver
 |-
-| notification_url      || Secure (usually HTTPS) location where an EncryptedPaymentRequest (see below) SHOULD be sent when ready
+| notification_url      || Secure (usually HTTPS) location where an [[#EncryptedPaymentRequest|EncryptedPaymentRequest]] (see below) SHOULD be sent when ready
 |-
 | signature             || PKI-dependent signature
 |}
@@ -137,7 +123,7 @@ message EncryptedInvoiceRequest {
 </pre>
 
 {| class="wikitable"
-! Field Name</b> !! Description
+! Field Name !! Description
 |-
 | encrypted_invoice_request || AES-256-CBC encrypted, serialized InvoiceRequest
 |-
@@ -171,7 +157,7 @@ message EncryptedPaymentRequest {
 }
 </pre>
 {| class="wikitable"
-! Field Name</b> !! Description
+! Field Name !! Description
 |-
 | encrypted_payment_request || AES-256-CBC encrypted, serialized BIP70 PaymentRequest
 |-
@@ -206,7 +192,7 @@ message EncryptedPayment {
 }
 </pre>
 {| class="wikitable"
-! Field Name</b> !! Description
+! Field Name !! Description
 |-
 | encrypted_payment         || AES-256-CBC encrypted, serialized BIP70 Payment message
 |-
@@ -239,7 +225,7 @@ message EncryptedPaymentACK {
 }
 </pre>
 {| class="wikitable"
-! Field Name</b> !! Description
+! Field Name !! Description
 |-
 | encrypted_payment_ack         || AES-256-CBC encrypted, serialized BIP70 PaymentACK message
 |-
@@ -257,8 +243,7 @@ message EncryptedPaymentACK {
 |}
 
 ==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 <b>Encrypted InvoiceRequest Overview</b> 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 below.
 
 ===Non-Encrypted InvoiceRequest Overview===
 # Sender creates InvoiceRequest
@@ -273,7 +258,7 @@ Optionally, the Sender MAY choose to encrypt the InvoiceRequest message and ther
 # The PaymentRequest is processed according to BIP70, including optional Payment and PaymentACK messages
 
 
-<img src="bip-0075/invoice-request-process.png"></img>
+<img src="bip-0075/invoice-request-process.png" alt="Flow diagram of Non-Encrypted InvoiceRequest">
 
 ===Encrypted InvoiceRequest Overview===
 # Sender retrieves Receiver InvoiceRequest Public Key
@@ -291,9 +276,9 @@ Optionally, the Sender MAY choose to encrypt the InvoiceRequest message and ther
 # Sender decrypts and validates encrypted PaymentRequest
 # The PaymentRequest is processed according to BIP70, including optional EncryptedPayment and EncryptedPaymentACK messages
 
-<b>NOTE:</b> See section <b>Initial Public Key Retrieval for InvoiceRequest Encryption</b> below for possible options to retrieve Receiver InvoiceRequest public keys.
-
-<img src="bip-0075/encrypted-invoice-request-process.png"></img>
+'''NOTE:''' See section [[#Initial_Public_Key_Retrieval_for_InvoiceRequest_Encryption|Initial Public Key Retrieval for InvoiceRequest Encryption]] below for possible options to retrieve Receiver InvoiceRequest public keys.
+ 
+<img src="bip-0075/encrypted-invoice-request-process.png" alt="Flow diagram of Encrypted InvoiceRequest">
 
 ==Message Interaction Details==
 
@@ -314,14 +299,13 @@ Messages MUST be transmitted via TLS-protected HTTP using the appropriate Conten
 |}
 
 ===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]). If the provided hash of each message does not match the contents of the message once decrypted, a general error should be returned to prevent oracle attacks.
+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]). If the provided hash of each message does not match the contents of the message once decrypted, a general error should be returned to prevent oracle attacks.
 
 ==Process Step Details==
 
 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, <b>nonce</b> 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 <b>nonce</b> MAY use whatever method to make sure that the <b>nonce</b> is never repeated.
+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.
 
 ===InvoiceRequest Message Creation===
 * Create an InvoiceRequest message
@@ -339,11 +323,11 @@ Where used, <b>nonce</b> MUST be set to a non-repeating number AND MUST be chose
 
 ===EncryptedInvoiceRequest Message Creation===
 * Create an EncryptedInvoiceRequest
-* Retrieve endpoint public key to use in <b>ECDH Point Generation</b> as specified in <b>Initial Public Key Retrieval for InvoiceRequest Encryption</b> (see below)
+* Retrieve endpoint public key to use in '''ECDH Point Generation''' as specified in [[#Initial_Public_Key_Retrieval_for_InvoiceRequest_Encryption|Initial Public Key Retrieval for InvoiceRequest Encryption]] (see below)
 * 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
 * invoice_request_hash MUST be set to the SHA256 hash of the serialized InvoiceRequest (without encryption)
-* Encrypt the serialized InvoiceRequest using AES-256-CBC setup as described in <b>ECDH Point Generation and AES-256 (CBC Mode) Setup (see below)</b>
+* Encrypt the serialized InvoiceRequest using AES-256-CBC setup as described in [[#ECDH_Point_Generation_and_AES256_CBC_Mode_Setup|ECDH Point Generation and AES-256 (CBC Mode) Setup]] (see below)
 * encrypted_invoice_Request MUST be set to the encrypted values of the InvoiceRequest
 * nonce MUST be set to the nonce used in the AES-256-CBC encryption operation
 * Set identifier to invoice_request_hash
@@ -356,7 +340,7 @@ Where used, <b>nonce</b> MUST be set to a non-repeating number AND MUST be chose
 * If pki_type is x509+sha256 and signature is valid for the serialized InvoiceRequest where signature is set to "", InvoiceRequest is VALID
 
 ===EncryptedPaymentRequest Message Creation and PaymentRequest Encryption===
-* Encrypt the serialized PaymentRequest using AES-256-CBC setup as described in <b>ECDH Point Generation and AES-256 (CBC Mode) Setup (see below)</b>
+* Encrypt the serialized PaymentRequest using AES-256-CBC setup as described in [[#ECDH_Point_Generation_and_AES256_CBC_Mode_Setup|ECDH Point Generation and AES-256 (CBC Mode) Setup]] (see below)
 * Create EncryptedPaymentRequest message
 * Set encrypted_payment_request to be the encrypted value of the PaymentRequest
 * Set payment_request_hash to generated SHA256 hash of the serialized PaymentRequest (without encryption)
@@ -370,7 +354,7 @@ Where used, <b>nonce</b> MUST be set to a non-repeating number AND MUST be chose
 * Set signature to the result of the signature operation above
 
 ===EncryptedPaymentRequest Validation and Decryption===
-* Decrypt the serialized PaymentRequest using AES-256-CBC setup as described in <b>ECDH Point Generation and AES-256 (CBC Mode) Setup (see below)</b>
+* Decrypt the serialized PaymentRequest using AES-256-CBC setup as described in [[#ECDH_Point_Generation_and_AES256_CBC_Mode_Setup|ECDH Point Generation and AES-256 (CBC Mode) Setup]] (see below)
 * Validate payment_request_hash matches SHA256 of the decrypted, serialized PaymentRequest
 * Deserialize the serialized PaymentRequest
 
@@ -392,7 +376,7 @@ Initial public key retrieval for InvoiceRequest encryption can be done in a numb
 ==EncryptedPayment and EncryptedPaymentACK Details==
 
 ===EncryptedPayment Message Creation===
-* Encrypt the serialized Payment using AES-256-CBC using secret key calculated in the <b>EncryptedPaymentRequest Message Creation and PaymentRequest Encryption</b> step (see above)
+* Encrypt the serialized Payment using AES-256-CBC using secret key calculated in the [[#EncryptedPaymentRequest_Message_Creation_and_PaymentRequest_Encryption|EncryptedPaymentRequest Message Creation and PaymentRequest Encryption]] step (see above)
 * Create EncryptedPayment message
 * Set encrypted_payment to be the encrypted value of the Payment
 * Set payment_hash to generated SHA256 hash of the serialized Payment (without encryption)
@@ -405,7 +389,7 @@ Initial public key retrieval for InvoiceRequest encryption can be done in a numb
 * Set signature to the result of the signature operation above
 
 ===EncryptedPaymentACK Message Creation===
-* Encrypt the serialized PaymentACK using AES-256-CBC using secret key calculated in the <b>EncryptedPaymentRequest Message Creation and PaymentRequest Encryption</b> step (see above)
+* Encrypt the serialized PaymentACK using AES-256-CBC using secret key calculated in the [[#EncryptedPaymentRequest_Message_Creation_and_PaymentRequest_Encryption|EncryptedPaymentRequest Message Creation and PaymentRequest Encryption]] step (see above)
 * Create EncryptedPaymentACK message
 * Set encrypted_payment_ack to be the encrypted value of the PaymentACK
 * Set payment_ack_hash to generated SHA256 hash of the serialized PaymentACK (without encryption)
@@ -418,9 +402,9 @@ Initial public key retrieval for InvoiceRequest encryption can be done in a numb
 * Set signature to the result of the signature operation above
 
 
-<b>SIGNATURE NOTE:</b> EncryptedPaymentRequest, EncryptedPayment, and EncryptedPaymentACK 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 concious 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:''' EncryptedPaymentRequest, EncryptedPayment, and EncryptedPaymentACK 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.
 
-==Payment / PaymentACK Messages with a Store & Foward Server==
+==Payment / PaymentACK Messages with a Store & Forward Server==
 When a Store & Forward server is in use during the Payment Protocol exchange, an EncryptedPayment message generated as the result of a EncryptedPaymentRequest with the requires_payment_message 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.
 
 Store & Forward servers MAY accept and/or overwrite EncryptedPayment messages until an EncryptedPaymentACK message with matching identifier and valid Receiver signature is received, after which the server MAY reject all further EncryptedPayment 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.
@@ -441,30 +425,24 @@ A reference client implementation can be found in the InvoiceRequest functional
 ==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.
 
-<img src="bip-0075/bip70-extension.png"></img>
+<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.
+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.
 
-<img src="bip-0075/mobile-sf-ir-with-payment.png"></img>
+<img src="bip-0075/mobile-sf-ir-with-payment.png" alt="EncryptedPayment 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.
+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.
 
-<img src="bip-0075/mobile-sf-ir-without-payment.png"></img>
+<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.
+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"></img>
+<img src="bip-0075/mobile-sf-encrypted-ir-without-payment.png" alt="EncryptedInvoiceRequest without payment">
 
 ==Extending BIP70 PaymentDetails==
 
@@ -482,7 +460,7 @@ message PaymentDetails {
 {| class="wikitable"
 ! Field Name !! Field Number !! Description
 |-
-| subtractable_fee      ||  1000   || In some situations the receiver may be willing to cover the cost of the transaction fee. If present, this field indicates how many Satoshis can be subtracted from the requested amount and instead applied towards the fee.
+| subtractable_fee      ||  1000   || In some situations the receiver may be willing to cover the cost of the transaction fee. If present, this field indicates how many satoshis can be subtracted from the requested amount and instead applied towards the fee.
 |-
 | fee_per_kb            ||  1001   || This field allows the receiver (merchant) to specify the minimum transaction fee that must be included with the transaction in order for it to be accepted with zero confirmations.
 |-