Edited 07_payment_channels.asciidoc with Atlas code editor

07_payment_channels.asciidoc

@@ -132,7 +132,7 @@ To open a payment channel, two nodes must first be connected as direct peers by
 
 [TIP]
 ====
-We describe two different protocols in this scenario. First, there is a _message protocol_, which establishes how the Lightning nodes communicate over the internet and what messages they exchange with each other. Second, there is the _cryptographic protocol_, which establishes how the two nodes construct and sign Bitcoin transactions.
+We describe two different protocols in this scenario. First, there is a _message protocol_, which establishes how the Lightning nodes communicate over the internet and what messages they exchange with each other. Second, there is the _cryptographic protocol_, which establishes how the two nodes construct and sign Bitcoin pass:[<span class="keep-together">transactions</span>].
 ====
 
 [[peer_protocol_channel_management]]
@@ -320,7 +320,7 @@ Later in this chapter we will see how more commitment transactions can be made t
 
 The refund transaction is not yet a valid transaction. For it to become a valid transaction two things must happen:
 
-* The funding transaction must be broadcast to the Bitcoin network. (To ensure the security of the Lightning Network, we will also require it to be confirmed by the Bitcoin blockchain, though this is not strictly necessary to chain transactions.)
+* The funding transaction must be broadcast to the Bitcoin network. (To ensure the security of the Lightning Network, we will also require it to be confirmed by the Bitcoin blockchain, though this is not strictly necessary to chain pass:[<span class="keep-together">transactions</span>].)
 * The refund transaction's input needs Alice's and Bob's signatures. 
 
 [role="pagebreak-before"]
@@ -418,7 +418,7 @@ Let's assume that Alice wants to send 70,000 satoshis to Bob to pay her bill at
 
 ==== Splitting the Balance
 
-((("payment channel","splitting the payment balance")))In principle, sending a payment from Alice to Bob is simply a matter of redistributing the balance of the channel. Before the payment is sent, Alice has 140,000 satoshis and Bob has none. After the 70,000 satoshi payment is sent, Alice has 70,000 satoshis and Bob has 70,000 satoshis.
+((("payment channel","splitting the payment balance")))In principle, sending a payment from Alice to Bob is simply a matter of redistributing the balance of the channel. Before the payment is sent, Alice has 140,000 satoshis and Bob has none. After the 70,000 satoshi payment is sent, Alice has 70,000 satoshis pass:[<span class="keep-together">and Bob</span>] has 70,000 satoshis.
 
 ((("commitment transactions","splitting balances with")))Therefore, all Alice and Bob have to do is create and sign a transaction that spends the 2-of-2 multisig to two outputs paying Alice and Bob their corresponding balances. We call this updated transaction a _commitment transaction_.
 
@@ -480,7 +480,7 @@ Let's look at these three elements in turn.
 .Commitment transaction #2
 image::images/mtln_0707.png[Commitment transaction #2]
 
-Alice and Bob hold two different variations of this transaction, as shown in <<asymmetric_1>>.
+Alice and Bob hold two different variations of this transaction, as illustrated in <<asymmetric_1>>.
 
 [[asymmetric_1]]
 .Asymmetric commitment transactions