Update ln-06.md formatting

en/ln-06.md

@@ -11,16 +11,16 @@ If you need a reminder, please check out the previous chapters!
 Table of Contents
 - The end goal
 - Opening the channel
-    - The open_channel message
+    - The `open_channel` message
-    - The accept_channel message
+    - The `accept_channel` message
-    - The funding_created message
+    - The `funding_created` message
 - Announcing the channel
 
 ### The end goal
 
 Let's establish what our old friends, Alice and Bob, are trying to achieve. 
 
-Alice and Bob are both Lightning Network nodes. Alice is known on the network by her *node ID*, or the public key used to identify her node, this is alice_node_id. Likewise, Bob's node ID is bob_node_id. 
+Alice and Bob are both Lightning Network nodes. Alice is known on the network by her *node ID*, or the public key used to identify her node, this is `alice_node_id`. Likewise, Bob's node ID is `bob_node_id`. 
 
 Their two main goals are: 
 1. They want to open a channel between themselves in a trustless way. 
@@ -76,28 +76,28 @@ Since Alice has decided on the the type of channel she wants to open (legacy as
 
 Alice can already choose some of her UTXOs to be inputs to the funding transaction since she knows the capacity of the channel she wants to open. However she does not yet know which pubkey Bob would want to use for the channel, so she cannot finalise the channel funding output just yet, and therefore cannot yet produce signatures for the inputs. 
 
-As Alice has decided on the channel type (and thus the commitment transaction structure), she can also start assembling the pieces of the commitment transactions. If we assume Bob is happy with this channel opening proposal from Alice, he can also start putting together the pieces using the information in the open_channel message. Remember that both peers need to construct their own commitment transactions and they will both need to sign their peer's transactions. 
+As Alice has decided on the channel type (and thus the commitment transaction structure), she can also start assembling the pieces of the commitment transactions. If we assume Bob is happy with this channel opening proposal from Alice, he can also start putting together the pieces using the information in the `open_channel` message. Remember that both peers need to construct their own commitment transactions and they will both need to sign their peer's transactions. 
 
 Let's see what pieces they are already able to fill in: 
 
 ![1a_2]()
 
-Alice's commitment transaction has the structure of a default, non-anchor channel transaction. All her public keys have been filled in (alice_local_delayed_pk_1 is derived using her delayed_payment_basepoint and her first_commitment_point). Since she hasn't received any messages from Bob yet, she cannot fill in any of his pubkeys. And since the funding transaction is still incomplete, she also can't know the TXID to point the input of this commitment transaction to. 
+Alice's commitment transaction has the structure of a default, non-anchor channel transaction. All her public keys have been filled in (`alice_local_delayed_pk_1` is derived using her `delayed_payment_basepoint` and her `first_commitment_point`). Since she hasn't received any messages from Bob yet, she cannot fill in any of his pubkeys. And since the funding transaction is still incomplete, she also can't know the TXID to point the input of this commitment transaction to. 
 
 Bob's commitment transaction is looking slightly more complete:
 
 ![1b_2]()
 
 Like Alice, he also cannot yet fill in the funding transaction's TXID, but he can fill in a few other things: 
-- The alice_pubkey_1, alice_to_self_delay, push_amt and local_amt values are taken as is from the open_channel message. 
+- The `alice_pubkey_1`, `alice_to_self_delay`, `push_amt` and `local_amt` values are taken as is from the `open_channel` message. 
-- alice_payment_key_1 is derived using Alice's payment_basepoint and first_commitment_point. 
+- `alice_payment_key_1` is derived using Alice's payment_basepoint and `first_commitment_point`. 
-- revoke_pubkey_1b is derived using Alice's revocation_basepoint and Bob's first_per_commitment point (Alice cannot derive this point yet since she hasn't received Bob's first_per_commitment_point)
+- `revoke_pubkey_1b` is derived using Alice's `revocation_basepoint` and Bob's `first_per_commitment point` (Alice cannot derive this point yet since she hasn't received Bob's `first_per_commitment_point`)
 
-Cool! Time for Bob to indicate to Alice his acceptance of the proposal by sending the next message: accept_channel. 
+Cool! Time for Bob to indicate to Alice his acceptance of the proposal by sending the next message: `accept_channel`. 
 
 #### The accept_channel message
 
-The message shares many of the fields from open_channel. Here's the message that Bob will put together. 
+The message shares many of the fields from `open_channel`. Here's the message that Bob will put together. 
 
 ![accept_channel]()
 
@@ -106,30 +106,30 @@ When Alice gets this message from Bob, she can now complete the funding transact
 ![fntx_3]()
 
 Alice can now fill in some more of her own commitment transaction:
-- she can now use the values sent by Bob to fill in bob_pubkey_1, bob_payment_key_1, bob_to_self_delay and revoke_pubkey_1a
+- she can now use the values sent by Bob to fill in `bob_pubkey_1`, `bob_payment_key_1`, `bob_to_self_delay` and `revoke_pubkey_1a`
 - since the TXID for the funding tx is now known, she can complete the input too
 
 She now knows everything she needs to know in order to sign this transaction herself _but_ remember she is still missing Bob's signature for this transaction. 
 
 ![1a_3]()
 
-Bob's commitment transaction is still the same as before since he learned no new information after sending the accept_channel message.
+Bob's commitment transaction is still the same as before since he learned no new information after sending the `accept_channel` message.
 
-Now that Alice knows the TXID of the funding transacation, she is also able to complete her view of Bob's commitment transaction and so she can produce her signature for his transaction. She will send the next message to Bob: funding_created.
+Now that Alice knows the TXID of the funding transacation, she is also able to complete her view of Bob's commitment transaction and so she can produce her signature for his transaction. She will send the next message to Bob: `funding_created`.
 
 #### The funding_created message
 
-Alice will now use the funding_created message to tell Bob the TXID and the index of the funding transaction along with her signature for Bob's commitment transaction. Note that Bob still won't be able to broadcast his commitment transaction because the funding transaction hasn't been broadcasted yet. 
+Alice will now use the `funding_created` message to tell Bob the TXID and the index of the funding transaction along with her signature for Bob's commitment transaction. Note that Bob still won't be able to broadcast his commitment transaction because the funding transaction hasn't been broadcasted yet. 
 
 ![funding_created]()
 
-Once Bob receives the funding_created message, he can fill in the rest of his commitment transaction: 
+Once Bob receives the `funding_created` message, he can fill in the rest of his commitment transaction: 
 
 ![1b_3]()
 
 #### The funding_signed message
 
-Alice won't broadcast the funding transaction until she has a valid signature from Bob for her commitment transaction, enter funding_signed:
+Alice won't broadcast the funding transaction until she has a valid signature from Bob for her commitment transaction, enter `funding_signed`:
 
 ![funding_signed]()
 
@@ -141,35 +141,35 @@ This was the last piece of the puzzle for Alice. She now has all the info she ne
 
 #### The channel_ready message
 
-Alice can now safely broadcast the funding transaction. Both Alice and Bob will watch the chain for the confirmation of the funding transaction. Once it has reached minimum_depth specified by Bob in his accept_channel message, both sides will exchange the channel_ready message. This message serves two purposes. First, it serves as a signal to the peer to indicate that the channel is ready to use (and they can start the channel announcement process if they opened a public, announced channel). Second, it also tells the peer to send across their second_per_commitment_point that they should use in their second commitment transaction. 
+Alice can now safely broadcast the funding transaction. Both Alice and Bob will watch the chain for the confirmation of the funding transaction. Once it has reached `minimum_depth` specified by Bob in his `accept_channel` message, both sides will exchange the `channel_ready` message. This message serves two purposes. First, it serves as a signal to the peer to indicate that the channel is ready to use (and they can start the channel announcement process if they opened a public, announced channel). Second, it also tells the peer to send across their `second_per_commitment_point` that they should use in their second commitment transaction. 
 
 ![channel_ready]()
 
 ### Announcing the channel
 
-This part is fairly easy. Alice and Bob just need to construct one message, channel_announcement, together and once it is complete, then they can broadcast it to the network. Other nodes will use this message to prove a few things:
+This part is fairly easy. Alice and Bob just need to construct one message, `channel_announcement`, together and once it is complete, then they can broadcast it to the network. Other nodes will use this message to prove a few things:
 - That the channe funding tx is actually an existing, unspent UTXO with an acceptable number of confirmations.
 - That the funding transaction output actually looks like a Lightning channel funding transaction.
-- that the channel is actually owned by the keys that Alice and Bob say they used to construct the channel. 
+- That the channel is actually owned by the keys that Alice and Bob say they used to construct the channel. 
 - That Alice and Bob both agree on the message being broadcast. 
 
-A partial version of the channel_announcement message looks like this:
+A partial version of the `channel_announcement` message looks like this:
 
 ![channel_announcement]()
 
-h is the hash of all the data that will be covered by the signatures. In order to complete this message, both Alice and Bob need to compute a signature over h using the private keys associated with their node IDs and the pubkeys they used in the funding transaction. They then both exchange the announcement_signatures message in order to communicate these signatures to each other. 
+`h` is the hash of all the data that will be covered by the signatures. In order to complete this message, both Alice and Bob need to compute a signature over `h` using the private keys associated with their node IDs and the pubkeys they used in the funding transaction. They then both exchange the `announcement_signatures` message in order to communicate these signatures to each other. 
 
 ![announcement_sig]()
 
-Now both nodes can put together the complete channel_announcement message:
+Now both nodes can put together the complete `channel_announcement` message:
 
 ![channel_announcement_2]()
 
 Let's say Charlie is a node that received this message. Let's go over the steps that he will go through in order to verify the new channel that Alice and Bob have announced:
 
-1. First, Charlie will use the short_channel_id included in the message to make sure that the funding transaction actually exists on-chain, and that it has a sufficient number of confirmations and that it is in fact unspent. 
+1. First, Charlie will use the `short_channel_id` included in the message to make sure that the funding transaction actually exists on-chain, that it has a sufficient number of confirmations and that it is in fact unspent. 
-2. Then, Charlie will check that the unspent output actually looks like a Lightning channel owned by alice_pubkey_1 and bob_pubkey_1. He will do this by using the advertised pubkeys to reconstruct the P2WSH and ensure that it is the same as the one found on-chain. 
+2. Then, Charlie will check that the unspent output actually looks like a Lightning channel owned by `alice_pubkey_1` and `bob_pubkey_1`. He will do this by using the advertised pubkeys to reconstruct the P2WSH and ensure that it is the same as the one found on-chain. 
-3. Now, Charlie will want to verify that the nodes ownning the pubkeys used in the funding output to in fact correspond to the nodes owning the node ID pubkeys. He can do this by verifying the signatures alice_pubkey_1_sig and bob_pubkey_1_sig. If these signatures are valid, then it is clear that the owners of alice_pubkey_1 and bob_pubkey_1 agree to be associated with alice_node_ID and bob_node_ID since the message signed contains these pubkeys. 
+3. Now, Charlie will want to verify that the nodes ownning the pubkeys used in the funding output to in fact correspond to the nodes owning the node ID pubkeys. He can do this by verifying the signatures `alice_pubkey_1_sig` and `bob_pubkey_1_sig`. If these signatures are valid, then it is clear that the owners of `alice_pubkey_1` and `bob_pubkey_1` agree to be associated with `alice_node_ID` and `bob_node_ID` since the message signed contains these pubkeys. 
-4. Finally, Charlie will also want to ensure that the owners of the node ID pubkeys agree to being associated with the new channel. He can do this by verifying the signatures alice_node_ID_sig and bob_node_ID_sig. If these signatures are valid, then it is clear that the owners of alice_node_ID and bob_node_ID agree to be associated with alice_pubkey_1 and bob_pubkey_1 since the message signed contains these pubkeys. 
+4. Finally, Charlie will also want to ensure that the owners of the node ID pubkeys agree to being associated with the new channel. He can do this by verifying the signatures `alice_node_ID_sig` and `bob_node_ID_sig`. If these signatures are valid, then it is clear that the owners of `alice_node_ID` and `bob_node_ID` agree to be associated with `alice_pubkey_1` and `bob_pubkey_1` since the message signed contains these pubkeys. 
 
 Alice and Bob are finished! Their channel is now open and other nodes on the network, like Charlie, will happily use the new channel.