https://en.bitcoin.it/w/index.php?action=history&feed=atom&title=BOLT11BOLT11 - Revision history2026-09-12T17:31:25ZRevision history for this page on the wikiMediaWiki 1.43.9https://en.bitcoin.it/w/index.php?title=BOLT11&diff=71278&oldid=prevNotATether: Create BOLT11 stub (Lightning invoice encoding)2026-09-12T04:57:29Z<p>Create BOLT11 stub (Lightning invoice encoding)</p>
<p><b>New page</b></p><div>'''BOLT11''' is the Lightning Network invoice format specified in BOLT 11 of the Basis of Lightning Technology. An invoice encodes a payment hash, amount, expiry, destination node, and optional routing hints in a Bech32-style string that usually starts with <code>lnbc</code> on Bitcoin mainnet. Wallets scan a QR code or paste the string, then send an onion-routed [[Hash Time Locked Contracts|HTLC]] to the destination.<br />
<br />
Lightning payments need a way for a receiver to communicate a payment hash (the SHA256 of a secret preimage), the amount, and how to reach the receiving node if it is not in the public graph. BOLT 11 defined a signed, human-copyable invoice before BOLT12 offers. It remains the most widely scanned Lightning invoice type on the [[Lightning Network]].<br />
<br />
The string is a human-readable prefix plus a Bech32 data part. The prefix is <code>ln</code> concatenated with a currency code (<code>bc</code> for Bitcoin mainnet, <code>tb</code> for testnet) and an optional amount with a multiplier (for example <code>lnbc2500u</code> for 2500 microbitcoin). The data part contains a timestamp and tagged fields, then a 512-bit recoverable signature over the invoice data using the destination node's key.<br />
<br />
Tagged fields include <code>p</code> (required 256-bit payment hash), <code>n</code> (destination public key if not recovered from the signature), <code>d</code> or <code>h</code> (description or description hash), <code>x</code> (expiry in seconds, default 3600), <code>c</code> (min_final_cltv_expiry), <code>f</code> (on-chain fallback address), <code>r</code> (private routing hints for unannounced channels), and <code>9</code> (feature bits the payer must understand). The payer looks up the destination in the network graph, builds an onion (BOLT 4), and sends an HTLC whose payment hash matches the invoice. The receiver reveals the preimage to settle; the preimage is the proof of payment.<br />
<br />
BOLT11 invoices are usually single-use: paying the same hash twice reuses HTLC correlation. Amount is fixed in the invoice, though some nodes allow overpayment. There is no built-in reusable offer, payer-blinded path, or asynchronous request for an invoice (those are BOLT12 features). Invoice length grows with routing hints and metadata, which makes QR codes dense. Feature bits signal multi-path payments, payment secrets, and other BOLT 4/9 capabilities; a payer that does not understand compulsory bits must fail. Related receive UX includes [[Lightning address]] and [[LNURL]].<br />
<br />
== See also ==<br />
* [[Lightning Network]]<br />
* [[Hash Time Locked Contracts]]<br />
* [[Lightning address]]<br />
* [[LNURL]]<br />
* [[Bech32]]<br />
<br />
== External links ==<br />
* [https://github.com/lightning/bolts/blob/master/11-payment-encoding.md BOLT 11: Invoice Protocol for Lightning Payments]<br />
* [https://github.com/lightning/bolts/blob/master/04-onion-routing.md BOLT 4: Onion Routing Protocol]<br />
* [https://github.com/lightning/bolts/blob/master/09-features.md BOLT 9: Assigned Feature Flags]<br />
<br />
[[Category:Technical]]</div>NotATether