Overview
A Lightning invoice is a standardized payment request used on the Lightning Network, defined by the BOLT 11 specification. Unlike on-chain Bitcoin transactions where the sender initiates a payment to an address, Lightning payments are pull-based: the recipient generates an invoice containing all the information needed for the payer to route a payment to them. The invoice is typically presented as a long alphanumeric string or QR code.
Invoice Structure
A BOLT 11 invoice encodes several pieces of information:
lnbc15u1p3xnhl2pp5jptserfk3zk4qy42tlcuszp33fs9nqa9...
Prefix breakdown:
┌──────────┬─────────────────────────────────────────┐
│ ln │ Lightning Network │
│ bc │ Bitcoin mainnet (tb for testnet) │
│ 15u │ Amount: 15 micro-BTC (1,500 sats) │
└──────────┴─────────────────────────────────────────┘
Encoded data fields:
┌──────────────────────────────────────────────────────┐
│ payment_hash → Unique identifier for the payment │
│ timestamp → When the invoice was created │
│ expiry → How long the invoice is valid │
│ (default: 3600 seconds / 1 hour) │
│ description → Human-readable payment description │
│ destination → Recipient's node public key │
│ routing_hints → Suggested routing paths │
│ min_final_cltv → Minimum timelock for final hop │
│ signature → Recipient's signature │
└──────────────────────────────────────────────────────┘
Payment Flow
Recipient Payer
│ │
│ 1. Generate secret R │
│ Compute H = hash(R) │
│ │
│ 2. Create invoice with H ──────► │
│ (via QR code, text, etc.) │
│ │
│ 3. Decode invoice│
│ 4. Find route │
│ 5. Send payment │
│ via HTLCs │
│ ◄──── HTLC chain ──────────── │
│ │
│ 6. Reveal R to claim payment │
│ ──── R propagates back ──────► │
│ │
│ Payment complete! │
Invoice Types
Amount-specified invoices: Include a specific payment amount. The payer must send exactly this amount.
Zero-amount invoices: Allow the payer to choose the amount. Useful for donations or tips.
AMP invoices: Allow payment to be split across multiple paths using Atomic Multi-Path payments.
Invoice Limitations
- Single-use: Each invoice should only be paid once. Reusing an invoice is a security risk because the payment secret (preimage) is revealed upon first payment.
- Expiry: Invoices expire (default 1 hour). Expired invoices cannot be paid.
- Recipient must be online: The recipient's Lightning node must be running to generate invoices and receive payments.
Alternatives and Extensions
- LNURL: A protocol that enables reusable payment links, withdrawals, and more user-friendly Lightning interactions
- BOLT 12 (Offers): A next-generation invoice format that supports reusable payment codes, recurrence, and payer privacy
- Keysend: Allows sending payments without an invoice, by spontaneously generating the payment preimage on the sender's side
- Lightning Address: An email-like format ([email protected]) that resolves to LNURL endpoints for seamless payments
Common Misconceptions
- Invoices are not addresses. Unlike Bitcoin addresses that can receive multiple payments, a standard Lightning invoice is meant for a single payment.
- The invoice amount is not locked in the sender's wallet. The sender can choose not to pay an invoice at any time before initiating the payment.
- Invoice expiry does not mean funds are lost. If an invoice expires before payment, no money moves. The recipient simply generates a new invoice.