diff --git a/en/ln-07.md b/en/ln-07.md
index 55c30c3..ddc71af 100644
--- a/en/ln-07.md
+++ b/en/ln-07.md
@@ -7,7 +7,7 @@ Table of contents
 
 ### Overview
 
-In this chapter we will cover the normal operations of a channel. This involves understanding how HTLCs are added to a channel and how channel peers commit to a new state to include these HTLCs. We will then cover how a channel's normal flow is re-established after a disconnection. Finally, we will cover the cooperative channel closure flow. By the way, all of these topics are covered in [BOLT2](). 
+In this chapter we will cover the normal operations of a channel. This involves understanding how HTLCs are added to a channel and how channel peers commit to a new state to include these HTLCs. We will then cover how a channel's normal flow is re-established after a disconnection. Finally, we will cover the cooperative channel closure flow. By the way, all of these topics are covered in [BOLT2](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md). 
 
 ### Preliminaries
 
@@ -271,7 +271,7 @@ Note that with anchor channels, the need to use the `update_fee` messaging is be
 
 ### Message retransmission
 
-Something that you may have picked up on in the add/remove HTLC flow is that explicit acknowledgements for the `update_*` messages is delayed until the `commitment_signed`/`revoke_and_ack` exchange. That is ok most of the time since we assume that the underlying transport between the two nodes (see [BOLT8]()) is ordered and reliable. However, if for some reason the connection between the two nodes needs to be re-established for some reason, there will be doubt regarding whether our peer has received the last message that we sent. This is where the `channel_reestablish` message comes in. Upon reconnection, before continuing with the noirmal operation flow, the peers will exchange this message to make sure they are on the same page and to determine which messages they possibly need to re-send to their peer. 
+Something that you may have picked up on in the add/remove HTLC flow is that explicit acknowledgements for the `update_*` messages is delayed until the `commitment_signed`/`revoke_and_ack` exchange. That is ok most of the time since we assume that the underlying transport between the two nodes (see [BOLT8](https://github.com/lightning/bolts/blob/master/08-transport.md)) is ordered and reliable. However, if for some reason the connection between the two nodes needs to be re-established for some reason, there will be doubt regarding whether our peer has received the last message that we sent. This is where the `channel_reestablish` message comes in. Upon reconnection, before continuing with the noirmal operation flow, the peers will exchange this message to make sure they are on the same page and to determine which messages they possibly need to re-send to their peer. 
 
 ![channel_reestablish]()
 
@@ -285,7 +285,7 @@ The `your_last_per_commitment_secret` is the last per-commitment secret received
 
 `my_current_per_commitment_point` is the commitment point of the local party on its last commitment transaction signed by the remote peer (in other words, the commitment transaction that has not yet been revoked). 
 
-There are lots of checks that a node should do when receiving a `channel_reestablish` in order to make sure that all necessary updates are re-sent so that the channel can continue working as normal. There are also some checks that ensure that nodes are not tricked into revoking a state that should not yet be revoked or tricked into broadcasting a state that _has_ been revoked. If you are interested in the details around these checks, read [BOLT2](). 
+There are lots of checks that a node should do when receiving a `channel_reestablish` in order to make sure that all necessary updates are re-sent so that the channel can continue working as normal. There are also some checks that ensure that nodes are not tricked into revoking a state that should not yet be revoked or tricked into broadcasting a state that _has_ been revoked. If you are interested in the details around these checks, read [BOLT2](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md). 
 
 Note that when a connection re-establish happens, both sides must remove any uncommitted updates from their staging area. If we revisit the git analogy, they should use git stash when a reconnection occurs. This means that both sides will need to retransmit any `update_*` messages that were not yet committed on the other side's commitment transaction.