diff --git a/BITSWAP.md b/BITSWAP.md
index 9a8c43abc..bbf9e292b 100644
--- a/BITSWAP.md
+++ b/BITSWAP.md
@@ -27,7 +27,9 @@ Bitswap is a data exchange protocol for sending and receiving content addressed
 
 ## Introduction
 
-Bitswap is a message-based protocol, as opposed to request-response. All messages contain wantlists, and/or blocks. Upon receiving a wantlist, a Bitswap server should eventually process and respond to the requester with either information about the block or the block itself. Upon receiving blocks, the client should send a `Cancel` notification to peers that have asked for the data, signifying that the client no longer wants the block.
+Bitswap is a message-based protocol, as opposed to request-response. All messages contain wantlists, and/or blocks.
+Upon receiving a wantlist, a Bitswap server should eventually process and respond to the requester with either information about the block or the block itself.
+Upon receiving blocks, the client should send a `Cancel` notification to peers that have asked for the data, signifying that the client no longer wants the block.
 
 Bitswap aims to be a simple protocol, so that implementations can balance aspects such as throughput, latency, fairness, memory usage, etc. for their specific requirements.
 
@@ -50,8 +52,8 @@ Bitswap implementations must support sending and receiving individual blocks of
 Given that a client C wants to fetch data from some server S:
 
 1. C sends a message to S for the blocks it wants, via a stream `s_want`
-    1. C may either send a complete wantlist, or an update to an outstanding wantlist
-    2. C may reuse this stream to send new wants
+  1. C may either send a complete wantlist, or an update to an outstanding wantlist
+  2. C may reuse this stream to send new wants
 2. S sends back blocks on a stream `s_receive`. S may reuse this stream to send back subsequent responses.
   1. S should respect the relative priority of wantlist requests from C, with wants that have higher `priority` values being responded to first.
 3. When C no longer needs a block it previously asked for, it should send a `Cancel` message for that block to all peers from which it has not received a response about that block
@@ -88,7 +90,7 @@ message Message {
 
 All protocol messages sent over a stream are prefixed with the message length in
 bytes, encoded as an unsigned variable length integer as defined by the
-[multiformats unsigned-varint spec][uvarint-spec].
+[multiformats unsigned-varint spec](https://github.com/multiformats/unsigned-varint).
 
 All protocol messages must be less than or equal to 4MiB in size
 
@@ -138,14 +140,14 @@ Bitswap 1.2.0 extends the Bitswap 1.1.0 protocol with the three changes:
 Given that a client C wants to fetch data from some server S:
 
 1. C opens a stream `s_want` to S and sends a message for the blocks it wants
-    1. C may either send a complete wantlist, or an update to an outstanding wantlist
-    2. C may reuse this stream to send new wants
-    3. For each of the items in the wantlist C may ask if S has the block (i.e. a Have request) or for S to send the block (i.e. a block request). C may also ask S to send back a DontHave message in the event it doesn't have the block
+  1. C may either send a complete wantlist, or an update to an outstanding wantlist
+  2. C may reuse this stream to send new wants
+  3. For each of the items in the wantlist C may ask if S has the block (i.e. a Have request) or for S to send the block (i.e. a block request). C may also ask S to send back a DontHave message in the event it doesn't have the block
 2. S responds back on a stream `s_receive`. S may reuse this stream to send back subsequent responses
-    1. If C sends S a Have request for data S has (and is willing to give to C) it should respond with a Have, although it may instead respond with the block itself (e.g. if the block is very small)
-    2. If C sends S a Have request for data S does not have (or has but is not willing to give to C) and C has requested for DontHave responses then S should respond with DontHave
-    3. S may choose to include the number of bytes that are pending to be sent to C in the response message
-    4. S should respect the relative priority of wantlist requests from C, with wants that have higher `priority` values being responded to first.
+  1. If C sends S a Have request for data S has (and is willing to give to C) it should respond with a Have, although it may instead respond with the block itself (e.g. if the block is very small)
+  2. If C sends S a Have request for data S does not have (or has but is not willing to give to C) and C has requested for DontHave responses then S should respond with DontHave
+  3. S may choose to include the number of bytes that are pending to be sent to C in the response message
+  4. S should respect the relative priority of wantlist requests from C, with wants that have higher `priority` values being responded to first.
 3. When C no longer needs a block it previously asked for it should send a Cancel message for that request to any peers that have not already responded about that particular block. It should particularly send Cancel messages for Block requests (as opposed to Have requests) that have not yet been answered.
 
 ### Bitswap 1.2.0: Wire Format