Una Lightning Invoice è simile a una fattura o meglio una richiesta di pagamento, che viene emessa per la rete Lightning Network dal destinatario o beneficiario.

Una Lightning invoice contiene tutte le informazioni di cui il pagante ha bisogno per eseguire correttamente il pagamento: l'importo da pagare, la destinazione del pagamento, i metadati e un messaggio.

Le invoice possono essere considerate l'equivalente Lightning di un indirizzo bitcoin in quanto entrambe vengono inviate dal beneficiario al pagatore per facilitare un pagamento, anche se funzionamento e caratteristiche sono molto diverse. Le Lightning invoice sono generalmente rappresentate come una stringa alfanumerica o a causa della sua lunghezza, sotto forma di codice QR.

Le Lightning invoice sono definite dallo standard BOLT 11. BOLT sta per "Basis of Lightning Technology" e copre tutte le specifiche della rete Lightning. Le specifiche BOLT sono necessarie per consentire a implementazioni separate di funzionare e interagire sulla stessa rete. Pertanto, grazie alle specifiche, una Lightning invoice creata da qualsiasi client o strumento sarà compresa da tutte le altre implementazioni.

URI Scheme: le Lightning invoice possono avere il prefisso lightning: per segnalare nei collegamenti 'ipertestuali quale software può essere utilizzato per pagare l'invoice. Idealmente, a lungo termine, con questo schema URI, se si segue un link Lightning sul web, il browser o il sistema operativo indirizzerà l'utente al wallet Lightning di sua scelta dove potrà confermare il pagamento dell'invoice.

La Lightning invoice è costituita da una parte leggibile dall'uomo e da una parte di dati.

Le Lightning invoice, come altre stringhe codificate in Bech32, sono in genere interamente minuscole. Tuttavia, la codifica dei soli caratteri maiuscoli nei codici QR offre notevoli miglioramenti in termini di spazio, motivo per cui le Lightning invoice in maiuscolo sono più frequenti. Questo è anche il motivo per cui un codice QR di una Lightning invoice potrebbe essere decodificato come solo maiuscolo.

Prefisso: una Lightning invoice inizia con le lettere ln che stanno per Lightning Network.

Network: segue il codice di due lettere che indica quale rete, come definito da BIP 173 per gli indirizzi Segwit nativi:

• bc per Bitcoin mainnet
• tb per Testnet Bitcoin
• bs per Bitcoin signet
• bcrt per Bitcoin regtest.

Poiché la invoice è codificata in Bech32, dovrà anche includere il checksum appropriato alla fine.

Importo: il prefisso è seguito dall'importo. Sebbene una tipica Lightning invoice includa un importo, è possibile emettere invoice senza importi. Le invoice Lightning fanno riferimento ai bitcoin, non ai satoshi. Per risparmiare spazio nelle invoice a cifra tonda, l'importo può essere seguito da un moltiplicatore. Una fattura Lightning da un solo satoshi, ad esempio, appare come 10n, cento satoshi come 1u e un milli-satoshi come 10p.

Il prefisso e l'importo insieme sono leggibili dall'uomo, consentendo a un utente esperto di identificarla immediatamente come una Lightning invoice e di dedurne l'importo.

Timestamp: la prima parte dei dati è un timestamp unix.

Esiste una serie di tag che possono essere utilizzati per indicare dati aggiuntivi. Alcuni di questi dati sono obbligatori, mentre altri possono essere forniti facoltativamente dal beneficiario.

Attualmente sono definiti i seguenti campi:

• p (1): il payment_hash SHA256 a 256 bit, l'hash della preimage del pagamento. Questa preimage viene rivelata successivamente durante il processo di pagamento e può fungere da prova di pagamento.
• s (16): Un secret a 256 bit impedisce ai nodi di inoltro di sondare il destinatario del pagamento.
• d (13): Descrizione, è possibile aggiungere qui una breve descrizione dello scopo del pagamento, codificata con UTF-8, ad esempio "1 tazza di caffè". Se questo campo non è impostato, deve essere utilizzato al suo posto il tag h.
• n (19): La chiave pubblica a 33 byte del nodo del beneficiario può essere inserita qui.
• h (23): Se il campo d non offre spazio sufficiente, si può includere un hash della descrizione più lunga. Il modo in cui la descrizione completa viene comunicata non è qui definito.
• x (6): expiry time, il tempo di scadenza in secondi.
• c (24): Il valore min_final_cltv_expiry per l'ultimo HTLC della route. In genere è predefinito a 18.
• f (9): Backup Bitcoin Address, è possibile includere un indirizzo on-chain fallback, di ripiego, nel caso in cui il pagamento Lightning non riesca per qualsiasi motivo.
• r (3): Una o più voci contenenti informazioni di routing aggiuntive per un routing privato. Questi suggerimenti di instradamento includono:
  • pubkey (264 bits)
  • short_channel_id (64 bits)
  • fee_base_msat (32 bits, big-endian)
  • fee_proportional_millionths (32 bits, big-endian)
  • cltv_expiry_delta (16 bits, big-endian)
• 9 (5): Uno o più valori a 5 bit contenenti le caratteristiche supportate o richieste per ricevere questo pagamento.

Signature: Infine, l'invoice include una firma. Questa firma viene verificata utilizzando la chiave pubblica fornita nell'invoice.

È possibile decodificare una Lightning invoice per ispezionarne il contenuto con il comando

lncli decodepayreq

Il formato della Lightning Invoice soffre di alcuni problemi: integrità della firma, mancanza di associazione per utente, mancanza di estrazione dei campi. Inoltre, richiede al destinatario un endpoint statico, come un sito web per comunicare l'invoice. La dipendenza da un sito web introduce una violazione della riservatezza del pagamento, poiché vengono coinvolti i server DNS, e una dipendenza sulla sicurezza della PKI, l'infrastruttura a chiave pubblica del web per la certificazione del sito web.

Attraverso la proposta BOLT 12 vengono aggiunte alle Lightning invoice numerose funzionalità, un nuovo protocollo di richieste di pagamento che introduce le offer.