Invoices, payment hashes and payment pre-image with diagrams

routing.asciidoc

@@ -300,7 +300,18 @@ Another proposed mechanism for implementing routing is a _Point Time-Locked Cont
 
 Let's revisit our example from the first part of this chapter. Alice wants to "tip" Dina, with a Lightning payment. Let's say Alice wants to send Dina 50,000 satoshis as a tip.
 
-For Alice to pay Dina, Alice will need Dina's node to generate a Lightning invoice. We will discuss this in more detail in <<bolt11_invoices>>. For now, let's assume that Dina has a website that can produce a Lightning invoice for tips. Alice visits Dina's site, enter the amount of 50,000 satoshis in a form and in response, Dina's Lightning node generate a payment request for 50,000 satoshis in the form of a Lightning invoice.
+For Alice to pay Dina, Alice will need Dina's node to generate a Lightning invoice. We will discuss this in more detail in <<bolt11_invoices>>. For now, let's assume that Dina has a website that can produce a Lightning invoice for tips.
+
+[TIP]
+====
+Lightning payments can be sent without an invoice, using a feature called _keysend_, which we will discuss in more detail in <<keysend>>. For now, we will explain the simpler payment flow using an invoice.
+====
+
+Alice visits Dina's site, enter the amount of 50,000 satoshis in a form and in response, Dina's Lightning node generate a payment request for 50,000 satoshis in the form of a Lightning invoice.
+
+[[alice-dina-invoice-1]]
+.Alice requests an invoice from Dina's website
+image:images/alice-dina-invoice-1.png["Alice requests an invoice from Dina's website"]
 
 As we saw in previous examples, we assume that Alice does not have a direct payment channel to Dina. Instead, Alice has a channel to Bob, Bob has a channel to Chan and Chan has a channel to Dina. To pay Dina, Alice must find a path that connects her to Dina. We will discuss that step in more detail in <<path_finding>>. For now, let's assume that Alice is able to gather information about available channels and sees that there is a path from her to Dina, via Bob and Chan.
 
@@ -314,6 +325,10 @@ The first part of a Hash Time-Locked Contract is the "Hash". This refers to the
 
 Alice has a Lightning invoice from Dina. Inside that invoice Dina has encoded a _payment hash_, which is the cryptographic hash of a secret that Dina's node produced. Dina's secret is called the _payment pre-image_. The payment hash acts as an identifier that can be used to route the payment to Dina. The payment pre-image acts as a receipt and proof of payment once the payment is complete.
 
+[[alice-dina-invoice-2]]
+.Alice gets a payment hash from Dina
+image:images/alice-dina-invoice-2.png["Alice gets a payment hash from Dina"]
+
 In the Lightning Network, Dina's payment pre-image won't be a phrase like "Dina's secret", but a random number generated by Dina's node. Let's call that random number +R+.
 
 Dina's node will calculate a cryptographic hash of +R+, such that:
@@ -399,15 +414,9 @@ The Bitcoin Script engine would evaluate this script as follows:
 1. +H+ is pushed to the stack
 1. The OP_EQUAL operator compares +H+ and H~R~. If they are equal, the result is +TRUE+, the script is complete and the payment is verified.
 
-
-.OP_HASH160 instead of OP_SHA256
-****
-In BOLT3 you will see that LN uses the OP_HASH160 operator intead of OP_SHA256. OP_HASH160 calculates a _double hash_ with SHA256 and RIPEMD160, producing a smaller 160-bit hash, to reduce the size of the script and save transaction fees. The use of OP_HASH160 is a common space-saving practice in Bitcoin Script.
-****
-
 ==== Extending HTLCs from Alice to Dina
 
-In the same way as we saw in the gold coin example, Alice will extend the HTLC across the network so that it reaches Dina.
+Alice will now extend the HTLC across the network so that it reaches Dina.
 
 [[alice-dina-htlc-1]]
 .Propagating the HTLC across the network