Fix minor spelling, capitalization and grammar mistakes in channel-construction.asciidoc (#339)

channel-construction.asciidoc

@@ -36,9 +36,9 @@ In this sense upgrading the Lightnign Network is much easier than upgrading Bitc
 ====
 
 Let's quickly summarize what you should already know about payment channels on a technical level and for what you will learn the details in this chapter.
-A payment channel is encoded as an unspent 2 - of - 2 multisignature transaction output.
-The capacity of the channel relates to the amount that is bound to the unspent 2 - of - 2 multisignature transaction output.
-It is opened with the help of a funding transaction that sends bitcoin to a 2 - of - 2 multisignature output together with a communication protocol that helps to initialize and maintain its state.
+A payment channel is encoded as an unspent 2-of-2 multisignature transaction output.
+The capacity of the channel relates to the amount that is bound to the unspent 2-of-2 multisignature transaction output.
+It is opened with the help of a funding transaction that sends bitcoin to a 2-of-2 multisignature output together with a communication protocol that helps to initialize and maintain its state.
 The balance of the channel encodes how the capacity is split between the two peers who maintain the channel.
 Technically the balance is encoded by a the most recent pair of a sequence of pairs of similar (but not equal) presigned commitment transactions.
 
@@ -48,10 +48,10 @@ When someone says they 'own' bitcoin they typically mean that they know the priv
 The private key allows the owner to produce a signature for a transaction that spends the bitcoin by sending it to a different address.
 Thus 'ownership' of bitcoin can be defined as the ability to spend that bitcoin.
 
-If you have an unpublished but signed transaction from a 2-out-of-2 multisignature address, where some outputs are sent to an address you own, and additionally you own one of the private keys of the multisignature address, then you effectively own the bitcoin of that output.
-Without your help no other transaction from the 2-out-of-2 multisignature address can be produced.
+If you have an unpublished but signed transaction from a 2-of-2 multisignature address, where some outputs are sent to an address you own, and additionally you own one of the private keys of the multisignature address, then you effectively own the bitcoin of that output.
+Without your help no other transaction from the 2-of-2 multisignature address can be produced.
 However, without the help of anybody else you can transfer the funds to an address which you control.
-On the Lightning Network ownership of your funds is almost always encoded with you having a pre-signed transaction spending from a 2-out-of-2 multisignature address.
+On the Lightning Network ownership of your funds is almost always encoded with you having a pre-signed transaction spending from a 2-of-2 multisignature address.
 
 ****
 
@@ -61,7 +61,7 @@ Each channel partner has both signatures for one of the commitment transactions
 The split of the capacity is realized by a `to_local` and a `to_remote` output that is part of every commitment transaction.
 The `to_local` output goes to an address that is controlled by the peer that holds this fully signed commitment transaction.
 `to_local` outputs, which also exist in the second stage HTLC transactions - which we discuss in the routing chapter - have two spending conditions.
-The `to_local` output can be spent either at any time with the help of a revocation secrete or after a timelock with the secret key that is controlled by the peer holding this commitment transaction.
+The `to_local` output can be spent either at any time with the help of a revocation secrete or after a timelock with the secret key that is controled by the peer holding this commitment transaction.
 The revocation secrete is necessary to economically disincentivice peers to publish previous commitment transactions.
 Addresses and revokation secretes change with every new pair of commitment transactions that are being negotiated.
 The Lightning Network as a protocol defines the communication protocols that are necessary to achieve this.
@@ -73,28 +73,28 @@ In this chapter we start from an insecure approach of creating a payment channel
 We will then explain how time locks are being used to create revokable sequence maturity contracts that create the penality based revokation system which economically incentivizes people maintain the most recent state.
 After you understood these concepts we will quickly walk you through the technical details of opening and closing a channel.
 
-Any known payment channel constuction uses a 2 - of - 2 multisgnature output as the basis of the payment channel.
+Any known payment channel constuction uses a 2-of-2 multisgnature output as the basis of the payment channel.
 We call the amount that is attached to this output the capacity of the channel.
-In every case Both channel partners hold 1 secret key of the multisignature address which means that they can only collaboratively controll the funds.
+In every case, both channel partners hold 1 secret key of the multisignature address which means that they can only collaboratively control the funds.
 
 #### An example for a highly insecure payment channel construction
-Let us assume Alice does not know the details about the Lightning Network and tries to naivly open a payment channel in a way that leads to her most likely loosing her funds.
-Alice has heard that Payment channel are 2 - of - 2 multisnature outputs.
-As she wants to have a channel with Bob and since she knows a public key from Bob she decides to open a channel by sending money to a 2 - of - 2 multisignature address that comes from Bob's and her key.
-We call the Transaction that Alices used a **funding transaction** as it is supposed to fund the payment channel.
+Let us assume Alice does not know the details about the Lightning Network and naivly tries to open a payment channel in a way that will likely lead to the loss of her funds.
+Alice has heard that payment channel are 2-of-2 multisignature outputs.
+As she wants to have a channel with Bob and since she knows a public key from Bob she decides to open a channel by sending money to a 2-of-2 multisignature address that comes from Bob's and her key.
+We call the transaction that Alices used a **funding transaction** as it is supposed to fund the payment channel.
 However signing and broadcasting this funding transaction would be a huge mistake.
 As we have discussed the Bitcoins from the resulting UTXO can only be spent if Alice and Bob work together and both provide a signature for a transaction spending those coins.
 If Bob would not respond to Alice in future Alice would have lost her Bitcoins forever.
-That is because the coins would be stuck in the 2 - of - 2 multisignature address to which she has just sent them.
+That is because the coins would be stuck in the 2-of-2 multisignature address to which she has just sent them.
 
-Luckily Alice has previously read Mastering Bitcoin and she knows all the properties of Bitcoin script and is aware of the risks that are involved to sending Bitcoins to a 2 - of - 2 multisignature address to which she does not controll both keys.
+Luckily Alice has previously read Mastering Bitcoin and she knows all the properties of Bitcoin script and is aware of the risks that are involved with sending Bitcoins to a 2-of-2 multisignature address to which she does not control both keys.
 She is also aware of the "Don't trust. Verify" principle that Bitcoiners follow and doesn't want to trust Bob to help her moving or accessing her coins.
-She would much more prefere to keep control over her coins even though they shall be stored in this 2 - of - 2 multisnature address.
-While this seems like an impossible problem Alice has an idea:
+She would much more prefere to keep control over her coins even though they shall be stored in this 2-of-2 multisignature address.
+While this seems like an impossible problem, Alice has an idea:
 
-    What if she could already prepare a refund transaction (which we call commitment transaction in future) that sends all the bitcoin back to an address that she controlls?
+    What if she could already prepare a refund transaction (which we call commitment transaction in future) that sends all the bitcoin back to an address that she controls?
 
-Before broadcasting her funding transaction she already prepares and finnishes it so that she knows the transaction id.
+Before broadcasting her funding transaction she already prepared and finishes it so that she knows the transaction id.
 She can now create the commitment transaction that spends the output of the funding transaction and ask Bob to provide a signature.
 At that time Bob has nothing to loose by signing the commitment transaction.
 He did not have Coins at the multisig address anyway.
@@ -105,15 +105,15 @@ On the other side you as a reader might think:
 Why would Alice send money to a multisignature address just to prepare a transaction that sends the money back to her?
 
 We really hope you have wondered about this because this is really the point where the innovation begins.
-Just because in general people are expected to broadcast a transaction to the bitcoin network as soon as they have signed it noone forcses you to do that.
+Just because in general people are expected to broadcast a transaction to the bitcoin network as soon as they have signed it noone forces you to do that.
 
-As Alice would loose access of her Bitcoins once she sends it to a 2 - of - 2 multisignature output for which she only controlls one key she needs to make sure that she will be able to regain access of her coins in case Bob becomes unresponisive.
-Thus before Alice publishes the funding transaction she will create another transaction that sends all the bitcoin from the 2 - of - 2 multisignature output back to an address which she controlls.
+As Alice would loose access of her Bitcoins once she sends it to a 2-of-2 multisignature output for which she only controls one key, she needs to make sure that she will be able to regain access of her coins in case Bob becomes unresponisive.
+Thus before Alice publishes the funding transaction she will create another transaction that sends all the bitcoin from the 2-of-2 multisignature output back to an address which she controls.
 
 .The situation can be seen in the following picture
 image:channel-construction-opening-1.png[]
-Of course for the commitment transaction Alice would need to get a Signature from Bob before she can safely broadcast the funding transaction.
-After publishing the funding transaction instead of braodcasting the commitment transaction she will keep it at a save place.
+Of course for the commitment transaction Alice would need to get a signature from Bob before she can safely broadcast the funding transaction.
+After publishing the funding transaction instead of braodcasting the commitment transaction she will keep it in a safe place.
 For this to work Alice needs to be sure that the funding transaction could not be published with a different transaction id.
 This malleability was possible before the Segwit upgrade of Bitcoin.
 We will discuss the details later but didn't want to leave them out here.
@@ -140,7 +140,7 @@ This could happen because she wants to pay Bob or because she wants Bob to forwa
 Let us assume as an example that Alice wants to send 30k Satoshi to Bob.
 For now we can assume that through some communication protocol Alice and Bob would negotiate a double spent of the funding transaction output of 100k satoshi.
 The new commitment transaction for which Alice and Bob would exchange signatures would send 70k satoshi to Alice and 30k Satoshi to Bob.
-.The situation can be seen in the following picture
+The situation can be seen in the following picture
 image:channel-construction-opening-2.png[]
 Whenever Alice and Bob want to change the balance of the payment channel they will negotiate a new commitment transaction.
 Effectively they double spend the funding transaction output.
@@ -154,12 +154,12 @@ So the main question reads:
 The thing that goes and makes this construction insecure lies within the mechanics of Bitcoin.
 The key innovation of Bitcoin was to prevent the double spending problem of electronic coins.
 After Alice and Bob have exchanged signatures for the second commitment transaction Bob cannot rely on the fact that he really owns 30k satoshi.
-Of course he could close the channel by publishing the second commitment transaction assigning 30k satoshi to an address that he controlls.
-But similarly Alice could broadcast the first commitment transaction and transfer the entire capacity of the channel back to an address that she controlls.
+Of course he could close the channel by publishing the second commitment transaction assigning 30k satoshi to an address that he controls.
+But similarly Alice could broadcast the first commitment transaction and transfer the entire capacity of the channel back to an address that she controls.
 As Bitcoin prevents double spending of the funding transaction miners will include only one of the two commitment transactions.
 Thus we need to adapt the idea with the commitment transactions to create the ability to revoke an old commitment transaction.
-Regarding the fact that Bob and Alice Both have a copy of the transaction and that Bob cannot controll the Data that Alice has stored on her hardware it seems pretty hopeless.
-Luckily the scripting language in Bitcoin allows at least for changing commitment transactions in a way that econimically disencentivices channel partners to publish and outdated balances after they have negotated a new balance.
+Regarding the fact that Bob and Alice both have a copy of the transaction and that Bob cannot control the data that Alice has stored on her hardware, it seems pretty hopeless.
+Luckily, the scripting language in Bitcoin allows at least for changing commitment transactions in a way that economically disincentivises channel partners from publish an outdated balances after they have negotated a new balance.
 
 #### Secure Payment channels via Revokable Commitment transactions
 
@@ -167,8 +167,8 @@ Luckily the scripting language in Bitcoin allows at least for changing commitmen
 [NOTE]
 ====
 In summary we can conclude that commitment transactions fulfill three purposes:
-1. refund channel participants in case the other side becomes irresponsive
-2. Splite the capacity of the channel into the current balance that peers have agreed upon.
+1. Refund channel participants in case the other side becomes irresponsive
+2. Split the capacity of the channel into the current balance that peers have agreed upon.
 3. Allow revocation of old state through the means of a penality via a revocable sequence maturity contract.
 ====
 
@@ -197,7 +197,7 @@ It does however mean that the user who opens the channel also has to provide the
 Let us stick to our example where Alice opens a channel with Bob with a capacity of 100k satoshi.
 This means that Alice provides 100k satoshi.
 Alice will do that by creating a so called funding transaction.
-This transaction sends 100k satoshi from an address that she - or her lightning node software controlls - to a 2 - of - 2 multisig address for which she and Bob know 1 secret key each.
+This transaction sends 100k satoshi from an address that she - or her lightning node software controls - to a 2-of-2 multisig address for which she and Bob know 1 secret key each.
 The amount of Bitcoin that is sent to the multisig output by Alice is called the capacity of the payment channel.
 Thus for the reminder of the chapter in all examples we assume the payment channels that we use as examples already magically exist and the two peers Alice and Bob already have all the necessary data at hand.
 
@@ -207,8 +207,8 @@ Even though Alice and Bob both have a public node key to which they own the priv
 Let us assume for a moment that Alice would send 100k Satoshi to the Multisig address resulting from hers and Bob's public node id.
 In that case Alice will never be able to maintain her funds back without the help of Bob.
 Of course we want our payment channels to work in a way that Alice does not need to trust Bob.
-Bob could however refuse to sign a transaction that sends all those outputs back to an address that is controlled by Alice.
-He would be able to blackmail Alice to assign a significant amount of those Bitcoin to an output address that is controlled by him.
+Bob could however refuse to sign a transaction that sends all those outputs back to an address that is controled by Alice.
+He would be able to blackmail Alice to assign a significant amount of those Bitcoin to an output address that is controled by him.
 Thus Bob can't steel the coins from Alice directly but he can threten Alice to have her coins lost forever.
 This example shows that unfortunatelly opening a channel will be a little bit more complex than just sending Bitcoins to a multisignature address.
 ====
@@ -238,10 +238,10 @@ We will only look at the following ones:
 * [point:revocation_basepoint], [point:payment_basepoint], [point:delayed_payment_basepoint], [point:htlc_basepoint], [point:first_per_commitment_point]
 
 With the `chain_hash` Alice signals that she intends to open the channel on the Bitcoin blockchain.
-While the Lightning Network was certainly invented to scale the amount of payments that can be conducted on the Bitcoin Network it is interesting to note that the Network is designed in a way that allows to build channels over various currencies.
+While the Lightning Network was certainly invented to scale the amount of payments that can be conducted on the Bitcoin Network it is interesting to note that the network is designed in a way that allows to build channels over various currencies.
 If a node has channels with more than one currency it is even possible to route payments through multi asset channels.
-However this turns out to be a little bit tricky in reality as the exchange rate between currencies might change which might lead the forwarding node to wait for a better ex hange rate to settle or to abort the payment process.
-For the opening process the final channel id cannot be determined yet thus Alice needs to select a random channel id which Bob and she can use to identify the messages for this channel during the opening phase.
+However this turns out to be a little bit tricky in reality as the exchange rate between currencies might change which might lead the forwarding node to wait for a better exchange rate to settle or to abort the payment process.
+For the opening process the final channel id cannot be determined yet thus Alice needs to select a random channel id with Bob that she can use to identify the messages for this channel during the opening phase.
 This design descision allows multiple channels to exist between two nodes - though currently only LND supports this feature.
 Alice tells Bob for how many satoshis she wishes to open the channel.
 This information is necessary to construct the commitment transaction ...