Lightning Network Basics — Part 7
I will present the basic technical details of the Lightning Network over the course of several articles.
In this article, I will explain the Lightning invoice protocol.
The protocol for Lightning invoice is described in BOLT #11.
As for the Lightning Network, a transfer can be initiated if the destination node ID and the transfer amount are known. However, it is defined in BOLT because it is inconvenient to handle among humans.
An invoice is encoded in bech32 and represented as a string. It consists of a Human-Readable Part and other Data Parts. Some recent Bitcoin addresses are also bech32 encoded, but Lightning Network invoice is outside the 90-character constraint.
Bech32 does not use 1 as an encoded character. Therefore, 1 is used as the boundary between the Human-Readable Part and the Data Part.
Human-Readable Part
This part contains the type of network (Bitcoin mainnet/testnet, etc.) and the transfer amount. You can use 1 for the transfer amount, so you should look for the 1 at the end of the string for the boundary.
You can also create an invoice without specifying a transfer amount. In that case, the amount will not be known until you receive it. Some wallets require you to specify the amount.
The specifications allow you to receive up to twice the specified transfer amount (as described in BOLT #4).
Data Part
The Data Part has three sections.
- timestamp
- tagged fields (≥0)
- signature
The timestamp is the creation time of the invoice, and if there is no expiration information in the tagged data, the expiration time is one hour.
Signature is performed by the node that created the invoice. Normally, the private key of the node ID is used to sign the invoice, and the public key recovered from the signature is used as the transfer destination.
The tagged fields contains other information. Details are here. The most commonly used is the character information ( d field) that can be assigned to the invoice. For private nodes, the channel information is also private, so the route information for the last channel to be forwarded (r field) is also included.
In conclusion
This article provide the Lightning invoice protocol.
