# Lightning Invoices

*Lightning invoices, we tell you what you owe us*

By [Satoshi Fan Club](https://paragraph.com/@satoshifanclub) · 2023-05-17

lightning network, payment channels, bitcoin lightning network, bitcoin, cryptopayments

---

All payments start with an invoice (unless it’s [keysend](https://docs.lightning.engineering/lightning-network-tools/lnd/send-messages-with-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.

![](https://storage.googleapis.com/papyrus_images/d42094c4700b7c27cbaa0fc765bda0ba.webp)

We’re going to dive into:

[**Anatomy of an Invoice**](#99ff)

*   [Human Readable Part](#6a05)
    
*   [Data Part](#435a)
    

[**Why Do Lightning Payments Need Invoices?**](#a14b)

[**Alternatives to Payments Without Invoices — Keysend**](#6f92)

Anatomy of an Invoice
=====================

The invoice is formatted in [bech32 encoding](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki), 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:

**_lnbc15u_**1p3xnhl2**p**p5jptserfk3zk4qy42tlucycrfwxhydvlemu9pqr93tuzlv9cc7g3s**d**qsvfhkcap3xyhx7un8**c**qzpg**x**qzjc**s**p5f8c52y2stc300gl6s4xswtjpc37hrnnr3c9wvtgjfuvqmpm35evq**9**qyyssqy4lgd8tj637qcjp05rdpxxykjenthxftej7a2zzmwrmrl70fyj9hvj0rewhzj7jfyuwkwcg9g2jpwtk3wkjtwnkdks84hsnu8xps5vsq4gj5hs

**Human Readable Part**
-----------------------

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](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) for the network. Below is a table with network prefixes. For example, an invoice that starts with`lnbc` would be in the lightning mainnet because `bc` is after `ln`.

![](https://storage.googleapis.com/papyrus_images/c7a52213fb20b1c951025ef4b8ef8131.webp)

**_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.

![](https://storage.googleapis.com/papyrus_images/f423d88aff947120a363a232d8e4648f.webp)

**Data Part**
-------------

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`

![](https://storage.googleapis.com/papyrus_images/dc8cf913a65798e41a99df7ba647478a.webp)

**_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.

Why Do Lightning Payments Need Invoices?
========================================

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.

Alternatives to Payments Without Invoices — Keysend
===================================================

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.

Resources
=========

**Interactive Invoice BOLT 11**

[

The Lightning Invoice
---------------------

Learn about Bitcoin Lightning Network invoices. Get in-depth decoding on the inner workings of payment requests in LN.

https://www.bolt11.org

![](https://storage.googleapis.com/papyrus_images/49a296ba7aa4d9e35ba12fc4d63e5b4c.png)

](https://www.bolt11.org/?source=post_page-----bd7210f25012--------------------------------)

[**Suredbits**](https://medium.com/u/e56d3a55c1c9?source=post_page-----bd7210f25012--------------------------------) **on Lightning Invoices**

[https://paragraph.xyz/suredbits/lightning-101-what-is-a-lightning-invoice-d527db1a77e6?source=post\_page-----bd7210f25012--------------------------------](https://paragraph.xyz/suredbits/lightning-101-what-is-a-lightning-invoice-d527db1a77e6?source=post_page-----bd7210f25012--------------------------------)

**BOLT11 Standards on Invoices in Github**

[

bolts/11-payment-encoding.md at master · lightning/bolts
--------------------------------------------------------

BOLT: Basis of Lightning Technology (Lightning Network Specifications) - bolts/11-payment-encoding.md at master · lightning/bolts

https://github.com

![](https://storage.googleapis.com/papyrus_images/c8bc0dde17de876fa85e4ca185f3ab2f.png)

](https://github.com/lightning/bolts/blob/master/11-payment-encoding.md?source=post_page-----bd7210f25012--------------------------------)

**Lightning Engineering — Understanding Lightning Invoices**

[

Understanding Lightning Invoices | Builder's Guide
--------------------------------------------------

Learn how to identify, decode and create Lightning invoices

https://docs.lightning.engineering

![](https://storage.googleapis.com/papyrus_images/c8dcd85484f497990ac6beda7a9c589c.png)

](https://docs.lightning.engineering/the-lightning-network/payment-lifecycle/understanding-lightning-invoices?source=post_page-----bd7210f25012--------------------------------)

**Lightning Keysend — ReadTheDocs**

[https://lightning.readthedocs.io/lightning-keysend.7.html?source=post\_page-----bd7210f25012--------------------------------](https://lightning.readthedocs.io/lightning-keysend.7.html?source=post_page-----bd7210f25012--------------------------------)

**Voltage Keysend Payments**

[

Keysend Payments Explained - Voltage Technical Series | Voltage Blog
--------------------------------------------------------------------

Keysend payments enable Lightning Network transactions without invoices, providing a simpler way to send payments directly between nodes.

https://www.voltage.cloud

![](https://storage.googleapis.com/papyrus_images/f886cd424540b38524141fc96716659e.png)

](https://voltage.cloud/blog/bitcoin-lightning-network/keysend-payments-explained-voltage-technical-series/?source=post_page-----bd7210f25012--------------------------------)

---

*Originally published on [Satoshi Fan Club](https://paragraph.com/@satoshifanclub/lightning-invoices)*