Con i canali aperti e la liquidità distribuita, il nodo può ricevere e inviare pagamenti senza passare da un fornitore. In questo capitolo vediamo come funzionano le invoice, che cosa fa il nodo quando paga, quali altri modi di pagamento esistono, come si fissano le commissioni di inoltro, come si limitano i permessi delle applicazioni collegate e come si spostano i fondi quando il saldo del nodo cresce.
Ricevere: l’invoice
Per ricevere un pagamento, il nodo crea un’invoice, una richiesta di pagamento che si consegna a chi paga come stringa di testo o codice QR. Secondo le specifiche BOLT 11 e il corso di Plan ₿, l’invoice contiene l’importo, l’hash del pagamento, una descrizione, la scadenza, eventuali indicazioni utili a trovare il percorso e la firma del nodo che la emette, da cui chi paga ricava l’identità del destinatario. La scadenza predefinita è di un’ora: dopo la scadenza chi paga non deve tentare il pagamento e il destinatario non deve accettarlo.
L’hash del pagamento è l’impronta di un segreto, la preimmagine, che il destinatario rivela quando il pagamento si completa; la preimmagine è la prova che il pagamento è avvenuto. Per questo un’invoice si usa una sola volta: Mastering Lightning Network spiega che, una volta rivelata la preimmagine, tutti i nodi del percorso la conoscono, e se qualcuno pagasse di nuovo la stessa invoice un nodo intermedio potrebbe incassare il pagamento invece di inoltrarlo. Ogni pagamento richiede quindi un’invoice nuova.
Per ricevere serve liquidità in entrata sufficiente, dal lato delle controparti, come visto nel capitolo precedente.
Pagare: percorso, tentativi e pagamenti in più parti
Chi paga ricava dall’invoice il nodo di destinazione e, secondo BOLT 11, prima di pagare controlla commissioni, scadenza e tempi. Poi il nodo calcola da sé un percorso attraverso la rete, usando la mappa dei canali che conosce, e tenta di consegnare il pagamento. Ogni tentativo può riuscire, fallire con un errore oppure restare bloccato senza risposta. Se fallisce, il nodo prova un altro percorso. Il pagamento bloccato è il caso peggiore: il nodo non può riprovare su un altro percorso, perché il pagamento bloccato e il nuovo tentativo potrebbero andare a buon fine entrambi, e il destinatario verrebbe pagato due volte.
Se l’invoice lo consente, il nodo può dividere il pagamento in più parti, inviate su percorsi diversi. È una scelta del nodo, non dell’utente, e il pagamento resta atomico: o tutte le parti arrivano o il pagamento fallisce per intero, senza pagamenti parziali. Così si possono inviare importi che non passerebbero da un solo canale, e il manuale indica che i pagamenti in più parti aumentano la probabilità di successo.
Keysend, LNURL e offerte
L’invoice non è l’unico modo di pagare. Con Keysend è chi paga a generare la preimmagine e a inserirla, cifrata, nel pagamento: il destinatario la decifra e incassa senza aver emesso un’invoice. È un’estensione del protocollo, che il nodo del destinatario deve supportare.
LNURL è un insieme di specifiche che usa connessioni web e codici QR statici per semplificare lo scambio fra nodi e applicazioni: LNURL-withdraw, per esempio, genera l’invoice in automatico quando si preleva da un servizio, LNURL-auth permette di accedere a un sito con il proprio nodo.
BOLT 12 introduce le offerte: richieste di pagamento riutilizzabili, da cui chi paga ottiene un’invoice nuova attraverso la rete Lightning. Core Lightning le supporta. LND, al settembre 2026, non le supporta ancora da solo: il supporto è in sviluppo e previsto per la versione 0.22, e chi le usa oggi con LND ricorre a programmi esterni come LNDK.
Le commissioni di inoltro
Se il nodo inoltra pagamenti altrui, incassa una commissione per ogni pagamento che attraversa i suoi canali. La commissione ha due parti, stabilite canale per canale: una quota fissa in millisatoshi e una quota proporzionale all’importo, espressa in parti per milione (ppm). Il manuale fa questo esempio: con una quota fissa di 1.000 millisatoshi e una quota proporzionale di 1.000 ppm, un pagamento di 100.000 sat paga 1 sat più 100 sat, cioè 101 sat.
Il nodo di chi paga sceglie il percorso cercando di ridurre le commissioni, il numero di passaggi o entrambi. Una commissione alta fa passare meno pagamenti ma incassa di più su ciascuno; una bassa ne fa passare di più. Il manuale indica che per la maggior parte dei nodi conviene lasciare i valori predefiniti dell’implementazione, e che le commissioni di inoltro non sono in genere un reddito significativo rispetto ai costi di gestione del nodo. Abbassare la commissione di un solo canale è anche un modo per ribilanciarlo, perché attira i pagamenti che lo attraversano nella direzione opposta.
Su Umbrel le commissioni predefinite si impostano nelle impostazioni avanzate dell’app Lightning Node; ThunderHub permette di modificarle canale per canale.
I permessi delle applicazioni
Un wallet sul telefono, un terminale di cassa o un’altra applicazione collegata al nodo usa un macaroon, la credenziale di LND vista nel primo capitolo. LND ne crea tre: admin, che dà accesso a tutte le funzioni; readonly, che permette solo le operazioni che non cambiano lo stato del nodo; invoice, che dà accesso alle funzioni relative alle invoice. Con il comando `lncli bakemacaroon` si possono creare macaroon con permessi scelti uno per uno.
Un’applicazione che deve soltanto creare invoice, come un terminale di cassa, può quindi usare il macaroon invoice, che non permette di inviare pagamenti. La documentazione di LND avverte che cancellare il file di un macaroon non lo revoca: la revoca avviene sulla chiave da cui il macaroon è stato generato, e cancellare il database macaroons.db, che contiene quelle chiavi, invalida i tre macaroon predefiniti.
Quando il saldo del nodo cresce
Il nodo è un hot wallet, e Mastering Lightning Network raccomanda di non tenervi grandi somme. Chi incassa più di quanto spende, come un negozio, si trova con il saldo che cresce e con i canali pieni dal proprio lato. Il manuale descrive due modi per spostare i fondi. Il primo è chiudere i canali con un saldo alto: i fondi tornano nel wallet on-chain del nodo, che è ancora un hot wallet, e un’altra transazione li porta in un cold wallet, per esempio su un hardware wallet. Il secondo è uno swap come Loop Out, che converte un pagamento Lightning in bitcoin on-chain senza chiudere canali: riduce il saldo del nodo e, allo stesso tempo, aumenta la liquidità in entrata.
Chiudere il percorso
In quattro capitoli abbiamo installato un nodo Lightning collegato al nostro nodo Bitcoin, messo al sicuro seed e backup dei canali e configurato una watchtower, aperto i primi canali e ottenuto liquidità in entrata, e infine usato il nodo per ricevere e pagare. Il percorso precedente, Sovranità tecnica, ha preparato il nodo Bitcoin su cui tutto questo si appoggia.