From 19845126ec697f043a23f382a2653c0bdd10a6a3 Mon Sep 17 00:00:00 2001
From: Luke Dashjr <luke-jr+git@utopios.org>
Date: Thu, 17 Mar 2016 05:21:40 +0000
Subject: Put BIP 75 in the right place in README, and clean up formatting a
 bit

---
 bip-0075.mediawiki | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

(limited to 'bip-0075.mediawiki')

diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki
index 753c6e5..6d1587e 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 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 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.
 
@@ -34,15 +34,15 @@ The motivation for defining this extension to the BIP70 Payment Protocol is to a
 
 The motivation for this extension to BIP70 is threefold:
 
-# Ensure that the payment details can only be seen by the participants in the transaction, and not by any third party.  
+# Ensure that the payment details can only be seen by the participants in the transaction, and not by any third party.
 
 # Enhance the Payment Protocol to allow for store and forward servers in order to allow, for example, mobile wallets to sign and serve Payment Requests.
 
 # 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 
-#* 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 
+#* 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
 
@@ -118,7 +118,6 @@ message EncryptedInvoiceRequest {
     required uint64 nonce = 5;
     optional bytes  signature = 6;
     optional bytes  identifier = 7;
-    
 }
 </pre>
 
@@ -277,7 +276,7 @@ The process overview for using InvoiceRequests and receiving encrypted PaymentRe
 # The PaymentRequest is processed according to BIP70, including optional EncryptedPayment and EncryptedPaymentACK 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 InvoiceRequest public keys.
- 
+
 <img src="bip-0075/encrypted-invoice-request-process.png" alt="Flow diagram of Encrypted InvoiceRequest">
 
 ==Message Interaction Details==
@@ -334,7 +333,7 @@ Where used, '''nonce''' MUST be set to a non-repeating number AND MUST be chosen
 
 ===InvoiceRequest Validation===
 * Validate sender_public_key is a valid EC public key
-* The nonce MUST not be repeated. The service receiving the InvoiceRequest MAY use whatever method to make sure that the nonce is never repeated. 
+* The nonce MUST not be repeated. The service receiving the InvoiceRequest MAY use whatever method to make sure that the nonce is never repeated.
 * 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
@@ -360,7 +359,7 @@ Where used, '''nonce''' MUST be set to a non-repeating number AND MUST be chosen
 
 ===ECDH Point Generation and AES-256 (CBC Mode) Setup===
 * 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] 
+* Initialize [http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf HMAC_DRBG]
 ** Use '''secret point's''' X value for Entropy
 ** Use the given message's nonce field for Nonce
 * Initialize AES-256 in CBC Mode
@@ -414,11 +413,11 @@ Store & Forward servers MAY accept and/or overwrite EncryptedPayment messages un
 * Each ECC signature included in any message defined in this BIP MUST use the SHA-256 hashing algorithm and MUST be DER [ITU.X690.1994] encoded.
 
 ==Implementation==
-A reference implementation for a Store & Forward server supporting this proposal can be found here: 
+A reference implementation for a Store & Forward server supporting this proposal can be found here:
 
 [https://github.com/netkicorp/addressimo Addressimo]
 
-A reference client implementation can be found in the InvoiceRequest functional testing for Addressimo here: 
+A reference client implementation can be found in the InvoiceRequest functional testing for Addressimo here:
 
 [https://github.com/netkicorp/addressimo/blob/master/functest/functest_ir.py InvoiceRequest Client Reference Implementation]
 
-- 
cgit v1.2.3

