|
|
|
@ -24,7 +24,7 @@ to complete a payment from receiver to sender, is described in https://github.co
|
|
|
|
|
payment hash and destination are communicated in a payment request in order to
|
|
|
|
|
make the encoding more fully feature.
|
|
|
|
|
|
|
|
|
|
=== Lightning Payment Requests Vs Bitcoin Addresses
|
|
|
|
|
=== Lightning Payment Requests vs. Bitcoin Addresses
|
|
|
|
|
|
|
|
|
|
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 in order to allow a
|
|
|
|
|
degree of payment request re-use.
|
|
|
|
|
|
|
|
|
|
=== Bolt 11: Lightning Payment Request Serialization & Interpretation
|
|
|
|
|
=== BOLT 11: Lightning 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
|
|
|
|
|