Merge pull request #575 from jerzybrzoska/patch-2

Consistency in spelling out the numbers that are < 10 (ch. 3)

03_how_ln_works.asciidoc

@@ -95,7 +95,7 @@ Payment channels have a few very interesting and useful properties:
 * Payments made in a payment channel are only known to you and your partner. In that sense, you gain privacy compared to Bitcoin, where every transaction is public.  Only the final balance, which is the aggregate of all payments in that channel, will become visible on the Bitcoin blockchain.
 
 
-Bitcoin was about 5 years old when talented developers first figured out how payment channels could be constructed and by now there are at least 3 different methods known.
+Bitcoin was about five years old when talented developers first figured out how payment channels could be constructed and by now there are at least three different methods known.
 This chapter will focus on the channel construction method first described in the Lightning Network whitepaper by Joseph Poon and Thaddeus Dryja in 2015. These are known as _Poon-Dryja_ channels, and are the channel construction method currently used in the Lightning Network.
 The other two proposed methods are _Duplex Micropayment_ channels, introduced by Christian Decker around the same time as the "Poon-Dryja" channels and _eltoo_ channels, introduced in 2018 by Christian Decker, Rusty Russel and (author of this book) Olaoluwa Osuntokun.
 
@@ -306,7 +306,7 @@ However, sometimes closing a channel is desirable or necessary. For example:
 * The channel is not being used often because your channel partner is not a well-connected node, so you want to use the funds for another channel with a better-connected node.
 * Your channel partner has breached the protocol either due to a software bug or on purpose forcing you to close the channel to protect your funds.
 
-There are 3 ways to close a payment channel:
+There are three ways to close a payment channel:
 
 * Mutual close (the good way)
 * Force close (the bad way)
@@ -353,7 +353,7 @@ In the case that you broadcasted an earlier commitment transaction, the timelock
 
 When publishing a commitment transaction during a force close, the on-chain fees will be higher than a mutual close for several reasons:
 
-. When the commitment transaction was negotiated, the channel partners didn't know how much the on-chain fees would be at the future time the transaction would be broadcast. Since the fees cannot be changed without changing the outputs of the commitment transaction (needs both signatures) and since the force close happens when a channel partner is not available to sign, the protocol developers decided to be very generous with the fee rate included in the commitment transactions. It can be up to 5 times higher than the fee estimators suggest at the time the commitment transaction is negotiated.
+. When the commitment transaction was negotiated, the channel partners didn't know how much the on-chain fees would be at the future time the transaction would be broadcast. Since the fees cannot be changed without changing the outputs of the commitment transaction (needs both signatures) and since the force close happens when a channel partner is not available to sign, the protocol developers decided to be very generous with the fee rate included in the commitment transactions. It can be up to five times higher than the fee estimators suggest at the time the commitment transaction is negotiated.
 . The commitment transaction includes additional outputs for any pending routing attempts (HTLCs), which makes the commitment transaction larger (in terms of bytes) than a mutual close transaction. Larger transactions incur more fees.
 . Any pending routing attempts will have to be resolved on-chain causing additional on-chain transactions.