minor improvements to chapter "Delivering the payment" (#199)

- peer-to-peer better than "peer 2 peer" , in acronyms p2p is ok
- English language guidelines recommend numbers up to 12 to be spelled out. 4 --> four
- minor additions/clarifications

ch03.asciidoc

@@ -320,25 +320,25 @@ Invoices also have an expiry time so that the payee can delete the preimage afte
 === Delivering the payment
 
 You have already learnt that payments start with the payee creating an invoice which includes a Payment Hash to make sure that payments are atomic and that no one on the path of payment channels can withhold the transferred money to their benefit.
-In this section we will dive into the ideas and methods that are being used to deliver a payment over the Lightning Network and utilize everything that we have used so far.
+In this section we will dive into the ideas and methods that are being used to deliver a payment over the Lightning Network and utilize everything that we have presented so far.
 We need to introduce one missing protocol of the Lightning Network which is the gossip protocol.
 
-==== The peer 2 peer gossip protocol
+==== The peer-to-peer gossip protocol
 
 As mentioned payment channels can be announced to the network after they are established.
-This is happening via a peer to peer gossip protocol.
+This is happening via a peer-to-peer gossip protocol.
 After opening a channel a node will send out an announcement of the channel via the `channel_announcement` message to its peers.
 Every peer can validate the information from the `channel_announcement` message and verify that the funding transaction was indeed confirmed by the Bitcoin network.
 Upon verification the node will forward the gossip message to its peers.
-In order to avoid spam this will of course only be done if the message was not forwarded by that node yet.
+In order to avoid spam this will only be done if the message was not forwarded by that node already.
 Similarly nodes can be announced via the gossip protocol with the `node_announcment` message.
 For this message to be forwarded a node has to have at least one public channel that was announced on the gossip protocol.
-This again is a spam measure of the gossip protocol.
-Payment channels have various meta data that are useful for other participants of the network to know.
+This again is a spam reduction measure of the gossip protocol.
+Payment channels have various meta data that are useful for other participants of the network.
 This meta data is mainly used for making routing decisions.
-As nodes might want to change the meta data of their channel once in a while this information is shared in a `channel_update` message.
-These messages will only be forwarded about 4 times per day for every channel to prevent spam.
-The gossip protocol also comes with a variety of queries and tools to initially synchronize a node with the view of the network or to update the nodes view after being offline for a while.
+As nodes might want to change the meta data of their channel occasionally this information is shared in a `channel_update` message.
+These messages will only be forwarded about four times a day for every channel to prevent spam.
+The gossip protocol also comes with a variety of queries and tools to initially synchronize a node with the view of the network or to update the node's view after being offline for a while.
 We will investigate the details of the gossip protocol in a later chapter.
 For now it is only important to know that it exists and that it is used to share topology information of the Lightning Network with its participants.
 This topology information is crucually needed for delivering payments through the network of payment channels.
@@ -346,12 +346,13 @@ This topology information is crucually needed for delivering payments through th
 [NOTE]
 ====
 A major challenge for the participants of the Lightning Network is that the topology information that is being shared by the gossip protocol is only partial.
-For example the capacity of the payment channels is shared on the gossip protocol via the `channel_announcement` message.
-However this information is not as useful as the actual distribution of the capacity into a local balance between the two channel partners.
-This is obvious as a node can only forward the amount of bitcoin via a particular payment channel that it actually owns within that channel.
-While Lightning could have been designed to share balance information of channels and a precise topology this has not been done for two reasons:
+For example, the capacity of the payment channels is shared on the gossip protocol via the `channel_announcement` message.
+However, this information is not as useful as the actual distribution of the capacity into the local balance between the two channel partners.
+A node can only forward the amount of bitcoin via a particular payment channel that it actually owns within that channel.
+While Lightning could have been designed to share balance information of channels and a precise topology, this has not been done for several reasons:
 1. To protect the privacy of the users and not shout out every financial transaction and payment that is being conducted.
-2. To be able to scale the amount of payments that can be conducted with the Lightning Network. Remember the Lightning Network was created in the first place because notifying every participant about every payment does not scale well. Thus for simple technical reasons the Lightning Network cannot be designed in a way that the current balance updates of channels are being shared among participants.
+2. To be able to scale the amount of payments that can be conducted with the Lightning Network. Remember that the Lightning Network was created in the first place because notifying every participant about every payment does not scale well. Thus for simple technical reasons the Lightning Network cannot be designed in a way that the current balance updates of channels are being shared among participants.
+3. The Lightning Network is a dynamic organism. It changes constantly and frequently. Nodes are being added, other nodes are being turned off, balances change, etc. Even if everything is always communicated, the information will be valid only for a short amount of time. As a matter of fact, information might be already outdated by the time it is received. 
 ====
 
 ==== Finding a path