<p>Lightning invoices encode multiple pieces of information, some of which are optional, and some of which are variable-length. It is required that invoices use the shortest representation possible for each piece of data, and that each tagged data field must be a multiple of 5-bits in length, where they are zero-padded if the data is smaller than this length. Some data fields may also appear multiple times, and there are no arbitrary upper bounds on the number of times they appear, although each individual tagged data field is limited to 515 characters in length (inclusive of its type and length prefix).</p>
<p>Invoices are specified in <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md" rel="nofollow noreferrer">BOLT #11</a>, and are encoded using bech32 as defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="nofollow noreferrer">BIP-173</a>.</p>
<p>An invoice must <em>minimally</em> encode these requirements:</p>
<ul>
<li>network prefix: 4 characters for mainnet</li>
<li>amount: Variable length (typically 2-5 characters)</li>
<li>'1'. Last instance of this character delimits the remaining information.</li>
<li>timestamp: 7 characters</li>
<li>payment_hash: 55 characters</li>
<li>purpose: variable length (minimum empty description - 3 chars &quot;dqq&quot;)</li>
<li>min_cltv_expiry: variable, minimum 4 characters</li>
<li>signature+recovery: 104 characters</li>
<li>bech32 checksum: 6 characters</li>
</ul>
<p>Thus the minimum possible length of an invoice is around 190 characters if the purpose field is left empty and no optional fields are specified.</p>
<p>As some of the optional fields appear an arbitrary number of times, there is no upper bound on invoice length.</p>
<p>It would be practical however to set some reasonable upper limit in any software implementation. In practice, an invoice is not going to need hundreds of additional routing fields, fallback addresses and optional features. A malicious hacker might craft unnecessarily large invoices in attempt exploit bugs in software which decodes BOLT#11 invoices. Rejecting overly large invoices <em>before attempting parsing</em> can trivially avoid such bugs. A reasonable upper bound would be to use the upper bound of information which can be encoded in a QR-code, since invoices are often transmitted this way.</p>

CC BY-SA 4.0
2021-08-07T11:45:43.400Z
2021-08-07T12:14:20.540Z
2021-08-07T12:14:20.540Z
Mark H
<p>I've noticed Lightning invoices can be 263 characters, 247 characters, and possibly other lengths.  Is there a set range, and how (generally) are these numbers derived ?</p>
<p>related:  <a href="https://bitcoin.stackexchange.com/questions/36944/what-are-the-minimum-and-maximum-lengths-of-a-mainnet-bitcoin-address">What are the minimum and maximum lengths of a Mainnet Bitcoin address?</a></p>

<lightning-network><invoices>
What are the minimum and maximum lengths of a Lightning invoice (address)?
Derrick
# What are the minimum and maximum lengths of a Lightning invoice (address)?

(Asked by: username_0 on 2021-08-04)

I've noticed Lightning invoices can be 263 characters, 247 characters, and possibly other lengths. Is there a set range, and how (generally) are these numbers derived ?

related: [What are the minimum and maximum lengths of a Mainnet Bitcoin address?](https://bitcoin.stackexchange.com/questions/36944/what-are-the-minimum-and-maximum-lengths-of-a-mainnet-bitcoin-address)

**Tags:** lightning-network, invoices


---

## 1 answers

### Answer by username_1 on 2021-08-07. Score: 4

Lightning invoices encode multiple pieces of information, some of which are optional, and some of which are variable-length. It is required that invoices use the shortest representation possible for each piece of data, and that each tagged data field must be a multiple of 5-bits in length, where they are zero-padded if the data is smaller than this length. Some data fields may also appear multiple times, and there are no arbitrary upper bounds on the number of times they appear, although each individual tagged data field is limited to 515 characters in length (inclusive of its type and length prefix).

Invoices are specified in [BOLT #11](https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md), and are encoded using bech32 as defined in [BIP-173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki).

An invoice must *minimally* encode these requirements:

* network prefix: 4 characters for mainnet
* amount: Variable length (typically 2-5 characters)
* '1'. Last instance of this character delimits the remaining information.
* timestamp: 7 characters
* payment\_hash: 55 characters
* purpose: variable length (minimum empty description - 3 chars "dqq")
* min\_cltv\_expiry: variable, minimum 4 characters
* signature+recovery: 104 characters
* bech32 checksum: 6 characters

Thus the minimum possible length of an invoice is around 190 characters if the purpose field is left empty and no optional fields are specified.

As some of the optional fields appear an arbitrary number of times, there is no upper bound on invoice length.

It would be practical however to set some reasonable upper limit in any software implementation. In practice, an invoice is not going to need hundreds of additional routing fields, fallback addresses and optional features. A malicious hacker might craft unnecessarily large invoices in attempt exploit bugs in software which decodes BOLT#11 invoices. Rejecting overly large invoices *before attempting parsing* can trivially avoid such bugs. A reasonable upper bound would be to use the upper bound of information which can be encoded in a QR-code, since invoices are often transmitted this way.


---

