Fix formatting

1 files changed, 20 insertions, 23 deletions

diff --git a/bip-0073.mediawiki b/bip-0073.mediawiki
index 07add74..4414351 100644
--- a/bip-0073.mediawiki
+++ b/bip-0073.mediawiki
@@ -1,8 +1,6 @@
-{{bip}}
-
 <pre>
   BIP: 73
-  Title: Use "Accept" header for response type negotiation with Payment Request URLs 
+  Title: Use "Accept" header for response type negotiation with Payment Request URLs
   Author: Stephen Pair <stephen@bitpay.com>
   Status: Draft
   Type: Standards Track
@@ -11,15 +9,15 @@
 
 ==Abstract==
 
-This BIP describes an enhancement to the payment protocol ([[BIP 0070|BIP 70]])
+This BIP describes an enhancement to the payment protocol ([[bip-0070.mediawiki|BIP 70]])
 that addresses the need for short URLs when scanning from QR codes.  It
-generalizes the specification for the behavior of a payment request URL in a 
-way that allows the client and server to negotiate the content of the 
+generalizes the specification for the behavior of a payment request URL in a
+way that allows the client and server to negotiate the content of the
 response using the HTTP Accept: header field.  Specifically, the client
 can indicate to the server whether it prefers to receive a bitcoin URI or
 a payment request.
 
-Implementation of this BIP does not require full payment request ([[BIP 0070|BIP 70]]) support.
+Implementation of this BIP does not require full payment request ([[bip-0070.mediawiki|BIP 70]]) support.
 
 ==Motivation==
 
@@ -29,7 +27,7 @@ downloaded.  This creates long URIs that, when rendered as a QR code, have
 a high information density.  Dense QR codes can be difficult to scan resulting
 in a more frustrating user experience.  The goal is to create a standard that
 would allow QR scanning wallets to use less dense QR codes.  It also makes
-general purpose QR code scanners more usable with bitcoin accepting 
+general purpose QR code scanners more usable with bitcoin accepting
 websites.
 
 ==Specification==
@@ -37,35 +35,35 @@ websites.
 QR scanning wallets will consider a non bitcoin URI scanned from a QR code to
 be an end point where either a bitcoin URI or a payment request can be obtained.
 
-A wallet client uses the Accept: HTTP header to specify whether it can accept 
+A wallet client uses the Accept: HTTP header to specify whether it can accept
 a payment request, a URI, or both.  A media type of text/uri-list specifies that
 the client accepts a bitcoin URI. A media type of application/bitcoin-paymentrequest
-specifies that the client can process a payment request.  In the absence of an 
-Accept: header, the server is expected to respond with text/html suitable for 
+specifies that the client can process a payment request.  In the absence of an
+Accept: header, the server is expected to respond with text/html suitable for
 rendering in a browser.  An HTML response will ensure that QR codes scanned
 by non Bitcoin wallet QR scanners are useful (they could render an HTML page
 with a payment link that when clicked would open a wallet on the device).
 
-It is not required that the client and server support the full semantics of an 
+It is not required that the client and server support the full semantics of an
 HTTP Accept header.  If application/bitcoin-paymentrequest is specified in the
 header, the server should send a payment request regardless of anything else
-specified in the Accept header.  If text/uri-list is specified (but not 
-application/bitcoin-paymentrequest), a valid Bitcoin URI should be returned.  If 
+specified in the Accept header.  If text/uri-list is specified (but not
+application/bitcoin-paymentrequest), a valid Bitcoin URI should be returned.  If
 neither is specified, the server can return an HTML page.  When a uri-list is returned
 only the first item in the list is used (and expected to be a bitcoin URI), any additional
 URIs should be ignored.
 
 ==Compatibility==
 
-Only QR scanning wallets that implement this BIP will be able to process QR 
+Only QR scanning wallets that implement this BIP will be able to process QR
 codes containing payment request URLs.  There are two possible workarounds for QR
-scanning wallets that do not implement this BIP: 1) the server gives the user an 
-option to change the QR code to a bitcoin: URI or 2) the user scans the code with 
+scanning wallets that do not implement this BIP: 1) the server gives the user an
+option to change the QR code to a bitcoin: URI or 2) the user scans the code with
 a generic QR code scanner.
 
-In the second scenario, if the server responds with a webpage containing a link 
+In the second scenario, if the server responds with a webpage containing a link
 to a bitcoin URI, the user can complete the payment by clicking that link provided
-the user has a wallet installed on their device and it supports bitcoin URIs.  If the 
+the user has a wallet installed on their device and it supports bitcoin URIs.  If the
 wallet/device does not have support for bitcoin URIs, the user can fall back on
 address copy/paste.
 
@@ -74,10 +72,9 @@ implementing BIP 70 make use of the Accept: HTTP header when retrieving a
 payment request.
 
 ==Examples==
-The first image below is of a bitcoin URI with an amount and payment request 
-specified (note, this is a fairly minimal URI as it does not contain a 
+The first image below is of a bitcoin URI with an amount and payment request
+specified (note, this is a fairly minimal URI as it does not contain a
 label and the request URL is of moderate size).  The second image is a QR
 code with only the payment request url specified.
 
-[[File:BIP_0073a.png]]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[[File:BIP_0073b.png]]
-[[Category:BIP]]
+<img src=bip-0073/a.png></img><img src=bip-0073/b.png></img>