@ -24,7 +24,7 @@ to complete a payment from receiver to sender is described in https://github.com
payment hash and destination are communicated in a payment request to
make the encoding more fully featured.
=== Lightning Payment Requests versus Bitcoin Addresses
=== Lightning Payment Requests Versus Bitcoin Addresses
((("Bitcoin addresses, Lightning invoices versus")))((("Lightning invoices","Bitcoin addresses versus")))A commonly asked question when people first encounter a Lightning Payment
request is: why can't a normal static address format be used instead?
@ -57,7 +57,7 @@ a mechanism that allows a sender to typically request a new payment request
from the receiver, then an interactive protocol can be used to allow a
degree of payment request reuse.
=== BOLT #11: Lightning Payment Request Serialization and Interpretation
((("BOLT (Basis of Lightning Technology) standards documents","Lightning payment request serialization/interpretation")))((("Lightning invoices","payment request serialization/interpretation")))In this section, we'll describe the mechanism used to encode the set of
information required to complete a payment on the Lightning Network. As
@ -183,7 +183,7 @@ A full list of all the currently defined tagged fields is given in <<table1503>>