fix typos in chapter 3 (#166)

* fix typos Chapter 3

* additional ch3 typo fixes

Co-authored-by: Rene Pickhardt <rene@rene-pickhardt.de>

ch03.asciidoc

@@ -247,7 +247,7 @@ Not all ways could be chosen for each of the above mentioned reasons.
 For example if your channel partner is offline you will not be able to engage in the good way to do a mutual close.
 The good news for you is that your Lightning Network software will most likely automatically select the best closing mechanism that can currently be used if you ask the software to close the channel or if the software discovers an issue with your channel partner and follows the protocol specification which in most of such cases state that the channel shall be closed.
 
-===== Examining the god way - mutual close
+===== Examining the good way - mutual close
 The preferred and good way to close a channel is the mutual close.
 When you decide that you want to close the channel, your Lightning Network node will inform your channel partner about your intention.
 Now the channel will be prepared for shutting down.
@@ -277,7 +277,7 @@ In general you should not do a force close unless it is absolutely necessary.
 Your funds will be locked for a longer time and the person who opened the channel will have to pay higher fees. Also you might have to pay on-chain fees to abort or settle routing attempts - even if you haven't opened the channel.
 
 ===== Examining the ugly way - protocol breach
-In case your channel partner tries to cheat you - weather deliberate or not - by publishing an outdated commitment transaction, you will be able to use the timelock to catch this cheating attempt and collect on the outputs by using the revocation secret you had previously received to negotiate a newer state of the channel.
+In case your channel partner tries to cheat you - whether deliberate or not - by publishing an outdated commitment transaction, you will be able to use the timelock to catch this cheating attempt and collect on the outputs by using the revocation secret you had previously received to negotiate a newer state of the channel.
 This close can actually go in two ways.
 First if you catch your partner in time you will claim their funds. In that case the closing will be rather fast. Also you will have to pay the on-chain fees which could be really high if there is a lot of demand for transactions at that time.
 This should not bother you as you just gained the entire channel capacity.
@@ -362,7 +362,7 @@ If we knew the exact channel balances of every channel we would easily be able t
 This could even be done in a way to optimize the fees that would have to be paid by the payer to the nodes that kindly forward the payment.
 However as discussed the balance information of all channels is and cannot be available to all participants of the network.
 Thus we need to have some path finding strategy.
-This strategy relates closely to the routing algorithm hat is used.
+This strategy relates closely to the routing algorithm that is used.
 As we will see in the next section on the Lightning Network we use a source based onion routing protocol for routing payments.
 This means in particular that the sender of the payment has to find a path through the network.
 As mentioned before with only partial information about the network topology this is a real challenge and active research is still being conducted into optimizing this part of the Lightning Network implementations.
@@ -391,10 +391,10 @@ For now we want to focus on its properties for the transport of payments which w
 
 1. The most important property is that a routing node can only see on which channels it received an onion and on which channel to set up an HTLCs and thus to which peer to forward the onion. This means that no routing node can know who initiated the payment and for whom the payment is supposed to be. The exception of course would be if the node is the recipient. In that case it would know that it was the final destination.
 2. The onions are small enough to fit into a single TCP/IP package and actually even a link layer frame. This will make traffic analysis for intruding the privacy of the payments almost impossible.
-3. The Onions are constructed in a way that they will always have the same length independent of the position of the processing node along the path.
+3. The onions are constructed in a way that they will always have the same length independent of the position of the processing node along the path.
 4. Onions can have up to 20 hops included allowing for sufficiently long paths.
 5. The encryption of the onion for every hop uses different ephemeral encryption keys with every single onion. Should a key (in particular the private key of the public node key) leak at some point in time an attacker who collected onions cannot decrypt the other onions that have been stored.
-6. Errors can be sent back from the erring node in an encrypted way to the original sender. This is particularly useful as we have seen that Lightning nodes who initiate the Onions select a path without knowing whether every node has enough liquidity along their channels to forward the payment.
+6. Errors can be sent back from the erring node in an encrypted way to the original sender. This is particularly useful as we have seen that Lightning nodes who initiate the onions select a path without knowing whether every node has enough liquidity along their channels to forward the payment.
 
 As mentioned we will discuss the details of the Onion Format later but we note already that the `Payment Hash`, while needed to set up the HTLCs for the payment, is not transported within the onions.
 The `Payment Hash` is rather included in the Lightning Message that also transports the onion.
@@ -414,9 +414,9 @@ The Lightning messages are sent in an encrypted way after a peer connection has
 Establishing the peer connection follows a cryptographic handshake following the Noise Protocol Framework.
 The Noise Protocol Framework is a collection of templates for cryptographic handshakes and is also used by WhatsApp and Wireguard.
 Using the Noise Protocol Framework makes sure that every message that is sent via Lightning is encrypted and authenticated.
-This makes development a little bit tricky as one cannot easily monitor one's own traffic on a tool like wireshark for debugging. footnote:[Luckily tools exist to make developers live easier: https://github.com/nayutaco/lightning-dissector]
+This makes development a little bit tricky as one cannot easily monitor one's own traffic on a tool like wireshark for debugging. footnote:[Luckily tools exist to make developer's lives easier: https://github.com/nayutaco/lightning-dissector]
 
-=== some thoughts that where supposed to be at other places but didn't make it to the text yet
+=== some thoughts that were supposed to be at other places but didn't make it to the text yet
 * network of payment channels
 * different scope of the network
 ** global path finding (entire knowledge of the network necessary)
@@ -433,7 +433,7 @@ Since Bob can directly close the channel, which costs fees paid by Alice, she wi
 
 === Comparison with Bitcoin
 
-While the Lightning Network is built on top of Bitcoin, and inherits many of it's features and properties, there are important differences that users of both need to be aware of.
+While the Lightning Network is built on top of Bitcoin, and inherits many of its features and properties, there are important differences that users of both need to be aware of.
 
 ==== Selecting Outputs vs Finding a Path
 
@@ -469,7 +469,7 @@ Higher value payments will thus cost more to route, and a market for capacity wi
 ==== Varying Fees Depending Traffic vs Announced Fees
 
 On the Bitcoin network, miners are profit-seeking, and so will typically include as many transactions in a block as possible, while staying within the block size limit (actually, a modified form called the block weight limit).
-If there are more transactions in the queue (called the mempool) than they can fit in a block, they will begin by mining the transactions that pay the highest fees per byte (highest fee per weight).
+If there are more transactions in the queue (called the mempool) than can fit in a block, they will begin by mining the transactions that pay the highest fees per byte (highest fee per weight).
 Thus, if there are many transactions in the queue, users will have to pay a higher fee to be included in the next block, or they will have to wait until there are fewer transactions in the queue.
 This naturally leads to the concept of 'traffic' and the creation of a fee market where users pay based on how urgently they need their transaction included in the next block.
 

preface.asciidoc

@@ -182,6 +182,7 @@ Following is an alphabetically sorted list of all the GitHub contributors, inclu
 * Emilio Norrmann (@enorrmann)
 * Hatim Boufnichel (@boufni95)
 * Imran Lorgat (@ImranLorgat)
+* Kory Newton (@korynewton)
 * Patrick Lemke (@PatrickLemke)
 * Ricardo Marques (@RicardoM17)
 * Simone Bovi (@SimoneBovi)