All things blockchain related, we're covering Bitcoin, Ethereum, Solana, Hashgraph, and all those good stuff
All things blockchain related, we're covering Bitcoin, Ethereum, Solana, Hashgraph, and all those good stuff
Share Dialog
Share Dialog
Subscribe to Satoshi Fan Club
Subscribe to Satoshi Fan Club
All payments start with an invoice (unless it’s keysend). The payee must put together an invoice. This tells the payer what network they want the payment in and the amount.
A Lightning invoice is a payment request that includes a payment hash and a preimage, which the payer must provide to settle the invoice.
Lightning invoices are generated by the payee and are used to receive payments through the Lightning Network.
We’re going to dive into:
Why Do Lightning Payments Need Invoices?
Alternatives to Payments Without Invoices — Keysend
The invoice is formatted in bech32 encoding, already used for Bitcoin Segregated Witness. It’s broken up into 2 main parts: human-readable and data portions.
Below is an example of an invoice:
lnbc15u1p3xnhl2pp5jptserfk3zk4qy42tlucycrfwxhydvlemu9pqr93tuzlv9cc7g3sdqsvfhkcap3xyhx7un8cqzpgxqzjcsp5f8c52y2stc300gl6s4xswtjpc37hrnnr3c9wvtgjfuvqmpm35evq9qyyssqy4lgd8tj637qcjp05rdpxxykjenthxftej7a2zzmwrmrl70fyj9hvj0rewhzj7jfyuwkwcg9g2jpwtk3wkjtwnkdks84hsnu8xps5vsq4gj5hs
The human-readable part has the network name and amount. In the example above lnbc15u is the human-readable part.
Network
All Lightning invoices start with the letters ln for Lightning Network. Then they are followed by a 2-letter code defined by BIP173 for the network. Below is a table with network prefixes. For example, an invoice that starts withlnbc would be in the lightning mainnet because bc is after ln.
Amount
The amounts reference bitcoin, not satoshi. To save space for round invoices, an amount can be followed by a multiplier. For example, a single satoshi Lightning invoice would appear as 10n, a hundred satoshi as 1u, and a milli-satoshi as 10p. In the example above, the amount is 15u (15* 100 satoshis). Below is a table of the amount units.
The data part is broken up into a timestamp, payment hash, description, min block height expiry (min final CLTV Expiry), expiry, payment secret (preimage),
An easy to know the different parts is by looking for the tags. P is the tag for payment hash, D is the tag
In the example above, the data part is:
pp5jptserfk3zk4qy42tlucycrfwxhydvlemu9pqr93tuzlv9cc7g3sdqsvfhkcap3xyhx7un8cqzpgxqzjcsp5f8c52y2stc300gl6s4xswtjpc37hrnnr3c9wvtgjfuvqmpm35evq9qyyssqy4lgd8tj637qcjp05rdpxxykjenthxftej7a2zzmwrmrl70fyj9hvj0rewhzj7jfyuwkwcg9g2jpwtk3wkjtwnkdks84hsnu8xps5vsq4gj5hs
Timestamp
In the example above, the timestamp is p3xnhl2, this is equivalent to the timestamp 1651105770, which is equivalent to Monday, May 2, 2022, at 8:29:30 AM UTC.
Payment Hash
In the example above, the payment hash (tagged with p) is pp5jptserfk3zk4qy42tlucycrfwxhydvlemu9pqr93tuzlv9cc7g3s. The payment hash is a 32-byte hash that uniquely identifies a Lightning Network payment. This hash is used to reference the payment throughout the payment’s lifecycle, from invoice creation to the payment's fulfillment.
Description
In the example above, the description (tagged with d) is dqsvfhkcap3xyhx7un8. The description can be any text note on the invoice. The description in the example is decoded to bolt11.org.
Min Final CLTV Expiry
In the example above, the minimum final CLTV (CheckLockTimeVerify) expiry (tagged with c) is cqzpg. The minimum final CLTV is the minimum block height at which the payment can be considered final. In this example, there is a requirement of a block height of 40 to be considered final.
Expiry
In the example above, the expiry (tagged with x) is xqzjc. The expiry is the number of seconds after which the invoice will expire if the payment has not been made. In this example, the invoice will expire in 600 seconds (10 minutes) if a payment hasn’t been made.
Payment Secret
In the example above, the payment secret (tagged with s) is sp5f8c52y2stc300gl6s4xswtjpc37hrnnr3c9wvtgjfuvqmpm35evq. The payment secret is a random 32-byte string that the payer generates, encrypted in the invoice using the shared secret. It is also known as the preimage or the payment hash preimage.
The recipient must decode the invoice to obtain the payment secret, which the payer later uses to prove the payment was successful and claim the funds in the payment channel.
The payment secret is crucial for the network’s security and privacy features because it prevents unwanted parties from intercepting or tampering with the payment.
Feature Bits
In the example above, the feature bits (tagged with 9) is 9qyyssq. Feature bits are optional or required features that can be included in the invoice to indicate to the payer which capabilities the payee’s Lightning node supports. In this example, the featured bits are:
{
"var_onion_optin": "supported",
"payment_secret": "required",
"basic_mpp": "supported"
} “var_onion_optin”: indicates that the payee’s node supports using variable-length onion packets for routing the payment.
“payment_secret”: indicates that the payee requires the payer to include a payment secret in the payment hash.
“basic_mpp”: indicates that the payee’s node supports the use of basic multi-path payments, which allows a payment to be split across multiple routes.
Signature
In the example above, the signature is y4lgd8tj637qcjp05rdpxxykjenthxftej7a2zzmwrmrl70fyj9hvj0rewhzj7jfyuwkwcg9g2jpwtk3wkjtwnkdks84hsnu8xps5vsq. A signature is a cryptographic signature created by the invoice issuer’s private key. It’s used to ensure the authenticity and integrity of the invoice. When the invoice recipient receives it, they can use the issuer’s public key to verify the signature and ensure that the invoice has not been tampered with.
Checksum
In the example above, the checksum is 4gj5hs. A checksum is a value calculated from a specific algorithm that is added to a Lightning invoice to ensure the integrity of the data and help detect errors.
We need invoices in the Lightning Network to route payments from the payer to the payee. Invoices contain important information such as the payment amount, payment hash, and other optional fields like the routing hints that enable intermediaries to discover the path to the payee. Routing nodes use invoices to determine the next hop in the payment path and forward the payment to the next node until it reaches the payee.
In addition, invoices also provide a way for the payee to request a specific payment amount and add additional metadata, such as an order number or customer ID, that can be useful for accounting or tracking purposes.
Without invoices, payers would have to manually construct payments and specify the routing path, which can be error-prone and time-consuming. Overall, invoices are critical in enabling efficient and reliable payment routing in the Lightning Network.
Keysend is a feature introduced in the Lightning Network that allows for small and spontaneous payments without needing a Lightning invoice. With keysend, a payer can simply send a payment directly to the payee’s Lightning node by including the payment information, such as the payment amount and memo, in the onion routing packet.
To make a payment using keysend, the payer’s Lightning node generates a payment hash and constructs an onion routing packet with the payment information in the payload. The onion packet is then sent to the payee’s Lightning node, which decrypts the packet and retrieves the payment information. The payee’s Lightning node then constructs a Lightning invoice using the payment hash, which the payer’s node can use to claim the payment once they have the preimage corresponding to the payment hash.
Keysend allows for more spontaneous and efficient payments. It eliminates the need for the payee to generate a Lightning invoice and for the payer to scan the QR code or manually enter the payment information. However, it does raise some privacy concerns, as the payment information is included in the routing packet in plaintext and can be visible to all the nodes involved in routing the payment.
Interactive Invoice BOLT 11
Learn about Bitcoin Lightning Network invoices. Get in-depth decoding on the inner workings of payment requests in LN.
Suredbits on Lightning Invoices
BOLT11 Standards on Invoices in Github
BOLT: Basis of Lightning Technology (Lightning Network Specifications) - bolts/11-payment-encoding.md at master · lightning/bolts
Lightning Engineering — Understanding Lightning Invoices
Learn how to identify, decode and create Lightning invoices
Lightning Keysend — ReadTheDocs
Voltage Keysend Payments
Keysend payments enable Lightning Network transactions without invoices, providing a simpler way to send payments directly between nodes.
All payments start with an invoice (unless it’s keysend). The payee must put together an invoice. This tells the payer what network they want the payment in and the amount.
A Lightning invoice is a payment request that includes a payment hash and a preimage, which the payer must provide to settle the invoice.
Lightning invoices are generated by the payee and are used to receive payments through the Lightning Network.
We’re going to dive into:
Why Do Lightning Payments Need Invoices?
Alternatives to Payments Without Invoices — Keysend
The invoice is formatted in bech32 encoding, already used for Bitcoin Segregated Witness. It’s broken up into 2 main parts: human-readable and data portions.
Below is an example of an invoice:
lnbc15u1p3xnhl2pp5jptserfk3zk4qy42tlucycrfwxhydvlemu9pqr93tuzlv9cc7g3sdqsvfhkcap3xyhx7un8cqzpgxqzjcsp5f8c52y2stc300gl6s4xswtjpc37hrnnr3c9wvtgjfuvqmpm35evq9qyyssqy4lgd8tj637qcjp05rdpxxykjenthxftej7a2zzmwrmrl70fyj9hvj0rewhzj7jfyuwkwcg9g2jpwtk3wkjtwnkdks84hsnu8xps5vsq4gj5hs
The human-readable part has the network name and amount. In the example above lnbc15u is the human-readable part.
Network
All Lightning invoices start with the letters ln for Lightning Network. Then they are followed by a 2-letter code defined by BIP173 for the network. Below is a table with network prefixes. For example, an invoice that starts withlnbc would be in the lightning mainnet because bc is after ln.
Amount
The amounts reference bitcoin, not satoshi. To save space for round invoices, an amount can be followed by a multiplier. For example, a single satoshi Lightning invoice would appear as 10n, a hundred satoshi as 1u, and a milli-satoshi as 10p. In the example above, the amount is 15u (15* 100 satoshis). Below is a table of the amount units.
The data part is broken up into a timestamp, payment hash, description, min block height expiry (min final CLTV Expiry), expiry, payment secret (preimage),
An easy to know the different parts is by looking for the tags. P is the tag for payment hash, D is the tag
In the example above, the data part is:
pp5jptserfk3zk4qy42tlucycrfwxhydvlemu9pqr93tuzlv9cc7g3sdqsvfhkcap3xyhx7un8cqzpgxqzjcsp5f8c52y2stc300gl6s4xswtjpc37hrnnr3c9wvtgjfuvqmpm35evq9qyyssqy4lgd8tj637qcjp05rdpxxykjenthxftej7a2zzmwrmrl70fyj9hvj0rewhzj7jfyuwkwcg9g2jpwtk3wkjtwnkdks84hsnu8xps5vsq4gj5hs
Timestamp
In the example above, the timestamp is p3xnhl2, this is equivalent to the timestamp 1651105770, which is equivalent to Monday, May 2, 2022, at 8:29:30 AM UTC.
Payment Hash
In the example above, the payment hash (tagged with p) is pp5jptserfk3zk4qy42tlucycrfwxhydvlemu9pqr93tuzlv9cc7g3s. The payment hash is a 32-byte hash that uniquely identifies a Lightning Network payment. This hash is used to reference the payment throughout the payment’s lifecycle, from invoice creation to the payment's fulfillment.
Description
In the example above, the description (tagged with d) is dqsvfhkcap3xyhx7un8. The description can be any text note on the invoice. The description in the example is decoded to bolt11.org.
Min Final CLTV Expiry
In the example above, the minimum final CLTV (CheckLockTimeVerify) expiry (tagged with c) is cqzpg. The minimum final CLTV is the minimum block height at which the payment can be considered final. In this example, there is a requirement of a block height of 40 to be considered final.
Expiry
In the example above, the expiry (tagged with x) is xqzjc. The expiry is the number of seconds after which the invoice will expire if the payment has not been made. In this example, the invoice will expire in 600 seconds (10 minutes) if a payment hasn’t been made.
Payment Secret
In the example above, the payment secret (tagged with s) is sp5f8c52y2stc300gl6s4xswtjpc37hrnnr3c9wvtgjfuvqmpm35evq. The payment secret is a random 32-byte string that the payer generates, encrypted in the invoice using the shared secret. It is also known as the preimage or the payment hash preimage.
The recipient must decode the invoice to obtain the payment secret, which the payer later uses to prove the payment was successful and claim the funds in the payment channel.
The payment secret is crucial for the network’s security and privacy features because it prevents unwanted parties from intercepting or tampering with the payment.
Feature Bits
In the example above, the feature bits (tagged with 9) is 9qyyssq. Feature bits are optional or required features that can be included in the invoice to indicate to the payer which capabilities the payee’s Lightning node supports. In this example, the featured bits are:
{
"var_onion_optin": "supported",
"payment_secret": "required",
"basic_mpp": "supported"
} “var_onion_optin”: indicates that the payee’s node supports using variable-length onion packets for routing the payment.
“payment_secret”: indicates that the payee requires the payer to include a payment secret in the payment hash.
“basic_mpp”: indicates that the payee’s node supports the use of basic multi-path payments, which allows a payment to be split across multiple routes.
Signature
In the example above, the signature is y4lgd8tj637qcjp05rdpxxykjenthxftej7a2zzmwrmrl70fyj9hvj0rewhzj7jfyuwkwcg9g2jpwtk3wkjtwnkdks84hsnu8xps5vsq. A signature is a cryptographic signature created by the invoice issuer’s private key. It’s used to ensure the authenticity and integrity of the invoice. When the invoice recipient receives it, they can use the issuer’s public key to verify the signature and ensure that the invoice has not been tampered with.
Checksum
In the example above, the checksum is 4gj5hs. A checksum is a value calculated from a specific algorithm that is added to a Lightning invoice to ensure the integrity of the data and help detect errors.
We need invoices in the Lightning Network to route payments from the payer to the payee. Invoices contain important information such as the payment amount, payment hash, and other optional fields like the routing hints that enable intermediaries to discover the path to the payee. Routing nodes use invoices to determine the next hop in the payment path and forward the payment to the next node until it reaches the payee.
In addition, invoices also provide a way for the payee to request a specific payment amount and add additional metadata, such as an order number or customer ID, that can be useful for accounting or tracking purposes.
Without invoices, payers would have to manually construct payments and specify the routing path, which can be error-prone and time-consuming. Overall, invoices are critical in enabling efficient and reliable payment routing in the Lightning Network.
Keysend is a feature introduced in the Lightning Network that allows for small and spontaneous payments without needing a Lightning invoice. With keysend, a payer can simply send a payment directly to the payee’s Lightning node by including the payment information, such as the payment amount and memo, in the onion routing packet.
To make a payment using keysend, the payer’s Lightning node generates a payment hash and constructs an onion routing packet with the payment information in the payload. The onion packet is then sent to the payee’s Lightning node, which decrypts the packet and retrieves the payment information. The payee’s Lightning node then constructs a Lightning invoice using the payment hash, which the payer’s node can use to claim the payment once they have the preimage corresponding to the payment hash.
Keysend allows for more spontaneous and efficient payments. It eliminates the need for the payee to generate a Lightning invoice and for the payer to scan the QR code or manually enter the payment information. However, it does raise some privacy concerns, as the payment information is included in the routing packet in plaintext and can be visible to all the nodes involved in routing the payment.
Interactive Invoice BOLT 11
Learn about Bitcoin Lightning Network invoices. Get in-depth decoding on the inner workings of payment requests in LN.
Suredbits on Lightning Invoices
BOLT11 Standards on Invoices in Github
BOLT: Basis of Lightning Technology (Lightning Network Specifications) - bolts/11-payment-encoding.md at master · lightning/bolts
Lightning Engineering — Understanding Lightning Invoices
Learn how to identify, decode and create Lightning invoices
Lightning Keysend — ReadTheDocs
Voltage Keysend Payments
Keysend payments enable Lightning Network transactions without invoices, providing a simpler way to send payments directly between nodes.
<100 subscribers
<100 subscribers
Mabel Oza
Mabel Oza
No activity yet