diff --git a/bip-invoicerequest-extension.mediawiki b/bip-invoicerequest-extension.mediawiki
index 6594fd2..ff033d8 100644
--- a/bip-invoicerequest-extension.mediawiki
+++ b/bip-invoicerequest-extension.mediawiki
@@ -31,17 +31,17 @@ The motivation for this extension to BIP70 is twofold:
 
 # 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 
-* Allow for an open standards based way 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
+#* 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 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.
 
 ==Example Use Cases==
 
-# Address Book
+1. Address Book
 
 Let's say 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 
@@ -56,7 +56,7 @@ searching a public repository. When the user wishes to make a payment, their wal
 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.
 
-# Individual Permissioned Address Release
+2. Individual Permissioned Address Release
 
 Let's say a Bitcoin wallet developer would like to offer the ability for a user to individually release address information 
 to a new potential sending party only if they can confirm the identity of the potential sending party. BIP70 specifies that 
@@ -67,7 +67,7 @@ With this BIP, Bitcoin wallets could prompt a wallet user to release payment inf
 information about the potential sending party via an included certificate. This allows the potential receiving party to 
 make a more informed decision regarding to whom they are releasing payment and identity information.
 
-# Using Store & Forward Servers
+3. Using Store & Forward Servers
 
 Let's say 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.