diff --git a/md/images/multi-hop-locks.png b/md/images/multi-hop-locks.png
index e1b11f6..9dd1841 100644
Binary files a/md/images/multi-hop-locks.png and b/md/images/multi-hop-locks.png differ
diff --git a/md/images/multi-hop-locks.txt b/md/images/multi-hop-locks.txt
index 2741449..cf97521 100644
--- a/md/images/multi-hop-locks.txt
+++ b/md/images/multi-hop-locks.txt
@@ -7,7 +7,7 @@ participant Dave
 
 == Setup ==
 
-    Dave->Alice : z*G
+    Dave->Alice  : z*G
     note left
         z can be a proof of payment
     end note
@@ -15,10 +15,10 @@ participant Dave
     note left
         Alice sets up tuple (L,y,R) for every hop
     end note
-    Alice->Alice: z*G, y0, (z+y0)*G
-    Alice->Bob  : (z+y0)*G, y1, (z+y0+y1)*G
-    Alice->Carol: (z+y0+y1)*G, y2, (z+y0+y1+y2)*G
-    Alice->Dave : (z+y0+y1+y2)*G, y0+y1+y2
+    Alice->Alice : z*G, y0, (z+y0)*G
+    Alice->Bob   : (z+y0)*G, y1, (z+y0+y1)*G
+    Alice->Carol : (z+y0+y1)*G, y2, (z+y0+y1+y2)*G
+    Alice->Dave  : (z+y0+y1+y2)*G, y0+y1+y2
 
 == Update ==
 
@@ -34,8 +34,9 @@ Carol->Dave : psig(C,txD,(z+y0+y1+y2)*G)
 
 == Settlement ==
 
-Dave->Dave : create adaptor_sig(D,txD,(z+y0+y1+y2)*G),\nMuSig combine with psig(C,txD,(z+y0+y1+y2)*G),\nbroadcast txD with combined sig
+Dave->Dave   : create adaptor_sig(D,txD,(z+y0+y1+y2)*G),\nMuSig combine with psig(C,txD,(z+y0+y1+y2)*G),\nbroadcast txD with combined sig
 Carol->Carol : compute z+y0+y1 = adaptor_sig(D,txD,(z+y0+y1+y2)*G) - psig(D,txD,(z+y0+y1+y2)*G) - y2\nto create adaptor_sig(C,txC,(z+y0+y1)*G),\nMuSig combine with psig(B,txC,(z+y0+y1)*G),\nbroadcast txC with combined sig
-Bob->Bob : compute y0 = adaptor_sig(C,txC,(z+y0+y1)*G) - psig(C,txC,(z+y0+y1)*G) - y1\nto create adaptor_sig(B,txB,(z+y0)*G),\nMuSig combine with psig(A,txB,(z+y0)*G),\nbroadcast txB with combined sig
+Bob->Bob     : compute z+y0 = adaptor_sig(C,txC,(z+y0+y1)*G) - psig(C,txC,(z+y0+y1)*G) - y1\nto create adaptor_sig(B,txB,(z+y0)*G),\nMuSig combine with psig(A,txB,(z+y0)*G),\nbroadcast txB with combined sig
+Alice->Alice : compute z = adaptor_sig(B,txB,(z+y0)*G) - psig(B,txB,(z+y0)*G) - y0
 
 @enduml
diff --git a/md/multi-hop-locks.md b/md/multi-hop-locks.md
index 051adf7..51a6142 100644
--- a/md/multi-hop-locks.md
+++ b/md/multi-hop-locks.md
@@ -26,97 +26,105 @@ Protocol
 
 ![multi-hop-locks](images/multi-hop-locks.png)
 
-In the setup phase the payee chooses `z` at random and sends the payer `z*G`.
-The payer will set up the multi-hop locks such that a successful payment reveals `z` to her and only her.
+In the setup phase the recipient chooses `z` at random and sends the sender `z*G`.
+The sender will set up the multi-hop locks such that a successful payment reveals `z` to her and only her.
 Knowledge of `z` can be a proof of payment which is similar in concept to payment preimages in the Lightning v1.0 (see section below for details).
 
-We picture the payment starting from the payer on the left side through intermediate hops to the payee on the right side.
-The setup phase continues with the payer setting up a tuple `(Li,yi,Ri)` consisting of the *left lock* `Li` and *right lock* `Ri` for every hop `i` in the following way:
-Every `yi` is a scalar uniformly chosen at random.
-The payers own left lock `L0` is set to `z*G` which was previously received from the payer.
-Now for every lock `Ri` for hop `0<=i<n` and `Lj` for hop `j=i+1` the payer sets `Ri <- Li + yi*G` and `Lj <- Ri` (see the diagram).
+We picture the payment starting from the sender on the left side through intermediate hops to the recipient on the right side.
+The setup phase continues with the sender setting up a tuple `(Li,yi,Ri)` consisting of the *left lock* `Li` and *right lock* `Ri` for every hop `i` in the following way:
+
+- Every `yi` is a scalar uniformly chosen at random.
+- The sender's own left lock `L0` is set to `z*G` which was previously received from the recipient.
+- For every lock `Ri` for hop `0<=i<n` and `Lj` for hop `j=i+1` the sender sets `Ri <- Li + yi*G` and `Lj <- Ri` (see the diagram).
+
+Note that in Lightning, the sender would not directly send `(Li,yi,Ri)` to the intermediate nodes: it will instead use the payment onion to carry those values without disclosing his identity to intermediate nodes.
 
 In the update phase adjacent hops add a multisig output to their off-chain transactions similar to how they would add an HTLC output in the Lightning v1.0.
 Despite significant differences between v1.0 HTLCs and the outputs used to forward payments in scripless scripts multi-hop locks we continue to call the outputs HTLCs because they have the same purpose and work similarly on the surface.
 Just like v1.0 HTLCs, scriptless script HTLCs have a time out condition such that the left hop can reclaim her coins if the payment fails.
-But otherwise scriptless script HTLCs are plain 2-of-2 MuSig outputs and the hashlock is only implicitly added to the output only when a partial signature is received (see below).
+But otherwise scriptless script HTLCs are plain 2-of-2 MuSig outputs and the hashlock is only implicitly added to the output when a partial signature is received (see below).
 For demonstration purposes we assume [eltoo](https://blockstream.com/eltoo.pdf)-style channels which means that both parties have symmetric state and there's no need for revocation.
 
 If the payment does not time out, the coins in the scriptless script HTLC output shared by two adjacent hops will be spent by the right hop.
-Therefore, the left hop `i` creates a transaction `txj` that spends the HTLC and sends to coins to an output that the right hop `j` controls.
+Therefore, the left hop `i` creates a transaction `txj` that spends the HTLC and sends the coins to an output that the right hop `j` controls.
 Because the left hop is now aware of the message (i.e. the transaction digest of `txj`) it is going to sign, its public signature nonce can be sent to the right hop.
-Nonce commitments have been exchanged earlier whenever convenient for both nodes such that the nonce commitment roundtrips are not on the critical path of the payment.
+Nonce commitments may have been exchanged earlier whenever convenient for both nodes such that the nonce commitment roundtrips are not on the critical path of the payment.
 
-Upon receiving notice of the new HTLC and the left hops public nonce, the right hop `j` creates transaction `txj` as well, combines both nonces and partially signs `txj` as `psig(j,txj,Lj)`.
+Upon receiving notice of the new HTLC and the left hop's public nonce, the right hop `j` creates transaction `txj` as well, combines both nonces and partially signs `txj` as `psig(j,txj,Lj)`.
 This is similar to a regular partial signature except that its left lock `Lj` is added to the combined signature nonce.
 The left hop verifies the partial signature and sends its own partial signature for `txj` to the right hop in the following two cases:
 
-- the left hop is the payer
-- the left hop `i` received a signature `psig(i-1, txi, T-yi*G)` from the preceding hop `i-1` for the left hops transaction `txi`. In combination with the partial signature just received from the right hop, it is guaranteed that as soon as the right hop spends the coins, the left hop can open its left lock and spend the coins with `txi` as we will see below.
+- the left hop is the sender
+- the left hop `i` received a signature `psig(i-1,txi,T-yi*G)` from the preceding hop `i-1` for the left hop's transaction `txi`. In combination with the partial signature just received from the right hop, it is guaranteed that as soon as the right hop spends the coins, the left hop can open its left lock and spend the coins with `txi` as we will see below.
 
 Therefore the update phase starts with the leftmost pair and continues to the right.
 After receiving the partial signature from the left, the right hop can complete it as soon as it learns the secret of its left lock.
-In order to reduce the overall number of communication rounds the setup phase and update phase can be merged together.
+In order to reduce the overall number of communication rounds the setup phase and update phase can be merged together (e.g. using the payment onion in Lightning).
 
-The settlement phase begins when the payee receives the partial signature from its left hop.
-Because the multi-hop locks were set up by the payer such that the payee knows the secret of her left lock, she can use it as the adaptor secret and create an adaptor signature.
-The adaptor signature is combined with the left hop's partial signature resulting in a final signature for the right hop's (the payee's) transaction.
-At this point the right hop can broadcast the transaction to settle on-chain.
+The settlement phase begins when the recipient receives the partial signature from its left hop.
+Because the multi-hop locks were set up by the sender such that the recipient knows the secret of her left lock, she can use it as the adaptor secret and create an adaptor signature.
+The adaptor signature is combined with the left hop's partial signature resulting in a final signature for the right hop's (the recipient's) transaction.
+At this point the right hop can broadcast the transaction to settle on-chain (in case the left hop disappears or tries to cheat).
 
-In this case the left hop notices the combined signature and learns its right lock secret by subtracting the right hop's previously received partial signature and its own partial signature.
-```
+In this case the left hop notices the combined signature and learns its right lock secret by subtracting the right hop's previously received partial signature and its own partial signature:
+
+```text
 sig(tx,T) - psig(i,tx,Ri) - psig(j,tx,Lj) = adaptor_sig(j,tx,Lj) - psig(j,tx,Lj) = yj
 ```
-Alternatively, the right hop can send its secret `yj` directly to the left hop and request to update commitment (Lightning v1.0) or settlement (eltoo) transaction such that the HTLC is removed, the left hop's output amount is decreased by the payment amount and the right hop's output amount is increased by that amount.
-If the left hop would not follow up with an update, the right hop can still broadcast the transaction until the HTLC times out.
 
-Either way, once the payee claims the payment, the left hop learns the right lock secret, computes its left lock secret by subtracting `yi`, computes an adaptor signature, and so on until the payer learns the proof of payment `z` which completes the payment.
+Alternatively, the right hop can send its secret `yj` directly to the left hop and request to update commitment (Lightning v1.0) or settlement (eltoo) transaction such that the HTLC is removed, the left hop's output amount is decreased by the payment amount and the right hop's output amount is increased by that amount.
+If the left hop would not follow up with an update, the right hop can still broadcast the transaction before the HTLC times out.
 
+Either way, once the recipient claims the payment, the left hop learns the right lock secret, computes its left lock secret by subtracting `yi`, computes an adaptor signature, and so on until the sender learns the proof of payment `z` which completes the payment.
 
 Proof of Payment (PoP)
 ---
-The main difference to Lightning v1.0 is that the proof of payment (`z`) is only obtained by the payer and not by every hop along the route.
-Therefore, the proof of payment can be used to authenticate the payer to the payee.
+
+The main difference to Lightning v1.0 is that the proof of payment (`z`) is only obtained by the sender and not by every hop along the route.
+Therefore, the proof of payment can be used to authenticate the sender to the recipient.
 It is not necessary to reveal the PoP itself but instead a signature of `z*G` can be provided.
 Due to payment decorrelation intermediate hops can not associate a payment with the PoP.
 
-Obviously, not only the payer is able prove knowledge of `z`.
-Everyone the payee or payer choose to share `z` with can do so too which makes it unclear who actually paid.
-Therefore a signed statement (invoice) from payee should be sent to payer that includes `z*G` and the payers public key.
-Then the PoP is both a signature with the PoP and the payers secret key which can only be provided by the payer (or everyone the payer chooses to collaborate with).
+Obviously, not only the sender is able prove knowledge of `z`.
+Everyone the recipient or sender choose to share `z` with can do so too which makes it unclear who actually paid.
+Therefore a signed statement (invoice) from recipient should be sent to sender that includes `z*G` and the sender's public key.
+Then the PoP is both a signature with the PoP and the sender's secret key which can only be provided by the sender (or everyone the sender chooses to collaborate with).
 
-Ideally a single static invoice would be payable by multiple parties allowing spontaneous payments without requiring extra communication with the payee.
+Ideally a single static invoice would be payable by multiple parties allowing spontaneous payments without requiring extra communication with the recipient.
 But this is not compatible with PoPs because the PoP must be created from fresh randomness for every payment.
-However, recurring payments from a single payer [can be done using hash chains](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001496.html).
-
+However, recurring payments from a single sender [can be done using hash chains](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001496.html).
 
 Atomic Multipath Payments (AMP)
 ---
-With scriptless script multi-hop locks it is possible to do AMP in a similarly to [*base AMP*](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001577.html) while allowing payment decorrelation between the paths.
-The payer sets up multiple routes to the payee using uncorrelated locks such that any partial payment claimed by the payee reveals the proof of payment (`z`) to the payer.
-Because the payee doesn't want to give up the PoP for just a partial payment, she waits until all routes to her are fully established and claims the all partial payments at once.
 
-It's also possible to set up multiple paths such that the receiver's payment preimage is only revealed once all paths are established, similar to [*base AMP*](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html) (also known as *low AMP*).
+With scriptless script multi-hop locks it is possible to do AMP in a way similar to [*base AMP*](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001577.html) while allowing payment decorrelation between the paths.
+The sender sets up multiple routes to the recipient using uncorrelated locks such that any partial payment claimed by the recipient reveals the proof of payment (`z`) to the sender.
+Because the recipient doesn't want to give up the PoP for just a partial payment, she waits until all routes to her are fully established and claims all the partial payments at once.
+
+It's also possible to set up multiple paths such that the recipient's secret (`z`) is only revealed once all paths are established, similar to [*base AMP*](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html) (also known as *low AMP*).
 The difference is that in the multi-hop-locks world we can keep the proof of payment.
 This is referred to as [*high AMP*](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001494.html).
 
 In high AMP the sender first draws a random number `q` and determines random `q1, ... qn` where `n` is the number of paths such that `q = q1 + ... qn`.
-The sender adds `q*G` to the receiver's payment point on every path, who is therefore unable to claim any payment because the receiver is not aware of `q`.
-However, when setting up each path `i` the sender sent `qi` along to the receiver.
-As soon as all paths are established, the receiver can compute `q` and claim the payments.
+The sender adds `q*G` to the recipient's payment point on every path, who is therefore unable to claim any payment because the recipient is not aware of `q`.
+However, when setting up each path `i` the sender sends `qi` along to the recipient.
+As soon as all paths are established, the recipient can compute `q` and claim the payments.
 
 Batched updates
 ---
-In the description of the multi-hop lock flow above we assumed that adding an HTLC output is immediately followed by a signatures from the right hop.
+
+In the description of the multi-hop locks flow above we assumed that adding an HTLC output is immediately followed by a signature from the right hop.
 However, [BOLT #2](https://github.com/lightningnetwork/lightning-rfc/blob/206084c9399abcfacdc95800acc27ebc5ca40b0c/02-peer-protocol.md#normal-operation) specifies that multiple updates (from both sides) can occur before a signature is exchanged.
 MuSig-based multi-hop locks can handle this similarly:
-Each update is accompanied by a public nonce to create a signature of the transaction including the update.
-Either left or right hop can conclude the batching phase by replying to the latest update with their public nonce and a partial signature.
+
+- Each update is accompanied by a public nonce to create a signature of the transaction including the update.
+- Either left or right hop can conclude the batching phase by replying to the latest update with their public nonce and a partial signature.
 
 An adversary may not choose the latest update to reply to but instead selects a different `(public nonce, transaction)`-pair from the victim's updates.
 This is not vulnerable to an attack similar to the [late message Wagner's attack](https://medium.com/blockstream/insecure-shortcuts-in-musig-2ad0d38a97da) because the adversary should not be able to trick the victim into signing a transaction with a different nonce.
 Instead, the victim's nonce is tied to a specific transaction which prevents the attacker from choosing a message for signing after seeing the victim's nonce.
 
+Resources
 ---
 
 * [MuSig](https://eprint.iacr.org/2018/068.pdf)