Lightning Network: cos'è, come funziona e quando ha senso

Che cos'è davvero la Lightning Network

Lightning è una rete di canali di pagamento bilaterali, descritta per la prima volta nel Lightning Network whitepaper del 2016 e standardizzata attraverso le specifiche BOLT (Basis of Lightning Technology) pubbliche nel repository lightning/bolts su GitHub. Ogni canale è aperto da una transazione Bitcoin on-chain che blocca fondi in un indirizzo multisig 2-su-2. Lo stato del canale può poi essere aggiornato off-chain all'infinito, perché entrambi i partecipanti possiedono una transazione di chiusura valida in ogni momento.

Questo significa tre cose concrete, spesso confuse:

1. I fondi sono sempre bitcoin: nessuna moneta nuova, nessun token separato.
2. La sicurezza del canale dipende dalla catena: se la controparte sparisce o tenta di pubblicare uno stato vecchio, l'altro lato può ripristinere lo stato corretto sulla blockchain entro un timeout.
3. Il routing fra canali è deterministico: la rete usa contratti HTLC (Hash Time-Locked Contracts) per spostare valore fra un nodo e l'altro senza fidarsi di intermediari.

Perché esiste, se Bitcoin funziona già

Bitcoin conferma un blocco in media ogni dieci minuti e gestisce volumi limitati rispetto alle carte di pagamento. La Lightning Network nasce per spostare micropagamenti e pagamenti rapidi fuori dalla catena, lasciando alla catena soltanto le aperture e le chiusure dei canali. La documentazione di Lightning Engineering descrive questa scelta come esplicita: portare sulla catena solo ciò che richiede il consenso globale, spostare sulla rete Lightning ciò che può essere gestito da relazioni fra coppie di nodi.

Questa separazione non è gratis. Lightning richiede che almeno un partecipante resti online per aggiornare i canali o per pubblicare la chiusura in caso di dispute; in cambio offre:

• conferma sub-secondo o pochi secondi, non minuti;
• commissioni di canale indipendenti dalla congestione on-chain;
• capacità di instradare pagamenti attraverso più hop usando HTLC.

Come si apre un canale

Aprire un canale Lightning richiede una transazione Bitcoin on-chain che blocca fondi in un indirizzo multisig 2-su-2. I passaggi, verificabili con un portafoglio Bitcoin e con un nodo Lightning, sono:

1. Generare i parametri del canale: due commitment transaction, una per ciascun lato, con regole di revoca reciproca descritte in BOLT-3.
2. Inviare una transazione di funding alla rete Bitcoin: è una normale transazione con output verso l'indirizzo multisig.
3. Attendere le conferme richieste dal protocollo: in genere tre conferme per canali pubblici.
4. Ricevere e firmare la prima commitment transaction: da questo momento il canale è attivo e il saldo può essere aggiornato con HTLC e update di commitment.

Il vincolo pratico è chiaro: aprire un canale costa come una normale transazione Bitcoin, con tempi e commissioni on-chain. Per questo la decisione di aprire un canale è rilevante: non va aperto per un singolo pagamento, ma quando si prevede un flusso ricorrente con la controparte.

Come funziona il routing con HTLC

Una volta aperti più canali, la rete può instradare un pagamento da A a Z attraverso B, C, D, E. Il trucco sono gli HTLC: il pagamento è condizionato dalla rivelazione di un segreto crittografico (la preimage di un hash) entro un tempo limite. Se A vuole pagare Z:

1. Z genera un segreto e ne comunica solo l'hash.
2. A propaga un HTLC verso B con quel hash e un timeout di, per esempio, 144 blocchi.
3. B propaga un HTLC verso C con un timeout leggermente più corto, e così via.
4. Z, unico possessore del segreto, lo rivela per incassare; il segreto risale la catena e ogni nodo incassa.

Se qualcuno non rivela il segreto in tempo, l'HTLC si annulla e i fondi tornano al mittente. Il routing è descritto in BOLT-4 (Onion Routing) e BOLT-7 (gossip dei canali), entrambe specifiche pubbliche consultabili nel repository BOLT. La conseguenza pratica è che un nodo intermedio non può sottrarre fondi: può solo inoltrare o rilasciare il pagamento.

Liquidità in ingresso e in us

Ogni canale ha due direzioni di capacità: la quantità che il nodo può inviare (outbound) e quella che può ricevere (inbound). Aprire un canale crea soltanto capacità outbound verso la controparte; per ricevere è necessario che altri aprano canali verso di noi, oppure che si usino strumenti di ribilanciamento (loop out, submarine swaps, spostamenti di saldo fra canali). Senza capacità inbound, un nodo non può accettare pagamenti anche se ha un canale aperto.

Questa asimmetria è la causa di molti "Lightning non funziona" osservati in pratica: il canale esiste, ma il saldo è tutto dalla nostra parte e quindi non possiamo accettare un pagamento in entrata. La guida operativa di Lightning Labs distingue esplicitamente le due direzioni e spiega perché la liquidità va gestita come una risorsa.

Invoice BOLT-11: come si presenta un pagamento

Una richiesta di pagamento Lightning è un stringa che inizia con lnbc... e contiene importo, descrizione, scadenza, route hints e l'hash del pagamento. È definita dalla specifica BOLT-11 ed è leggibile sia da portafogli custodial che da nodi completi. Gli elementi che la rendono verificabile sono la firma del nodo ricevente e il routing hints, che permette al mittente di calcolare un percorso anche quando il nodo ricevente ha canali privati.

Una buona prassi operativa è verificare il destinatario prima di pagare: l'invoice BOLT-11 non contiene un campo alias, ma può riportare il pubkey del nodo ricevente (campo opzionale n) o consentirne il recupero dalla firma; quando non è presente, il pubkey va ottenuto attraverso un canale affidabile e confrontato con quello del nodo a cui si paga — l'alias da solo non costituisce un'identità verificata. Il pagamento Lightning è non reversibile una volta accettato dal ricevente: sul livello on-chain, invece, una transazione non confermata può essere sostituita con una a commissione più alta finché resta in mempool (RBF secondo BIP-125) o accelerata da una transazione figlia (CPFP); una volta confermata, è definitiva.

Costi e commissioni

Lightning ha due livelli di costo:

• Costi di canale: la transazione on-chain di apertura e, in misura minore, quella di chiusura. Variabili in base alla congestione di Bitcoin al momento.
• Costi di routing: una tariffa base più una quota proporzionale all'importo, decisa dal nodo che inoltra. Sono tipicamente molto più basse rispetto alle commissioni on-chain, dell'ordine di pochi satoshi per canale attraversato.

Il rischio opposto è pagare troppo poco. Se la fee offerta è inferiore a quella minima accettata dai nodi intermedi, il pagamento non viene inoltrato e scade. La stima della fee richiede di conoscere la topologia della rete, la dimensione del pagamento e il canale più stringente. Le implementazioni più diffuse mostrano la fee stimata prima dell'invio; vale la pena confrontarla con il costo di una normale transazione on-chain per importi medio-alti.

I rischi reali di un nodo Lightning

Lightning non è gratis dal punto di vista della custodia. I rischi principali, documentati nelle specifiche BOLT-3 e BOLT-5, sono:

• Forza chiusura da controparte: la controparte pubblica un vecchio stato del canale. Il nodo onesto risponde con una transazione di penalità che recupera l'intero saldo, ma deve essere online e avere accesso alla chain entro il timeout.
• Canale unilaterale chiuso senza penalità: se la controparte pubblica l'ultimo stato onesto durante un periodo in cui il nodo è offline, non c'è penalità ma i fondi restano bloccati fino alla conferma della chiusura.
• Watchtower non configurata: un servizio di sorveglianza terzo, o un proprio nodo di backup, controlla la catena e pubblica la penalità se necessario. Senza watchtower, un nodo resta indifeso durante lunghi periodi offline.
• Esaurimento della liquidità: un canale può prosciugarsi in una direzione e diventare inutilizzabile fino a un ribilanciamento.
• Fee di routing volatili: la topologia della rete cambia e una route ieri economica può diventare costosa oggi.

Cosa Lightning non è

Lightning non sostituisce Bitcoin on-chain per tutti gli usi. Non è adatta a:

• Pagamenti molto grandi: la capacità è limitata dai canali attraversati, e un pagamento pari all'intero saldo di un hop fallisce per mancanza di liquidità.
• Casi d'uso che richiedono conferma regolamentare forte: un pagamento Lightning è irrevocabile in pochi secondi, non c'è finestra di attesa per la conferma di blocco.
• Hodling a lungo termine: i fondi in un canale sono spendibili ma non escono dalla catena finché il canale non viene chiuso. Per il risparmio a lungo termine restano preferibili UTXO in cold storage, come spiegato nella guida UTXO Bitcoin.

Lightning, full node e verifica on-chain

Un nodo Lightning che non è collegato a un proprio full node Bitcoin delega la verifica della catena a un server remoto, perdendo una delle ragioni per cui si usa Lightning in primo luogo. La prassi operativa raccomandata da Lightning Engineering è eseguire Lightning su un nodo che vede direttamente la catena Bitcoin: significa installare e sincronizzare Bitcoin Core (o un pruned node), e solo dopo collegare l'implementazione Lightning. Per chi vuole capire cosa comporta, la guida al full node Bitcoin descrive requisiti, costi e limiti.

Il nodo Lightning legge gossip dei canali (BOLT-7), verifica le commitment transaction rispetto alla catena, pubblica eventuali penalità e usa il proprio nodo Bitcoin per sapere se una transazione di funding è stata confermata. Senza questa integrazione, l'utente sta scambiando denaro su un'infrastruttura che si fida di un intermediario per la parte più critica.

Dove si colloca rispetto a LNP/BP

Lightning è un protocollo di secondo livello, mentre LNP/BP è un insieme di standard proposti per migliorare l'efficienza dei nodi Bitcoin e rendere più espressive le transazioni on-chain. Le due iniziative non sono concorrenti: Lightning usa Bitcoin on-chain per ancorare i canali, e molte ottimizzazioni LNP/BP mirano a rendere meno costose e più private le transazioni che Lightning genera o consuma. Per una lettura introduttiva, la guida su LNP/BP separa le proposte, lo stato di standardizzazione e gli effetti pratici.

Quando ha senso usare Lightning?

La risposta breve: quando paghi spesso, per importi medio-piccoli, con controparte che accetta Lightning. Per il resto, l'on-chain resta la scelta più difendibile. Una matrice decisionale utile:

Profilo	Consiglio operativo
Pagamenti ricorrenti sotto i 50 euro	canale con la controparte o nodo con liquidità inbound
Acquisto singolo sopra i 200 euro	on-chain con commissione calibrata sul mempool
Ricezione di mance, donazioni, micro-servizi	nodo Lightning con liquidità inbound o servizio con alias
Risparmio a lungo termine	UTXO in cold storage, niente canali aperti
Operatività da mobile, sempre connesso	portafoglio Lightning mobile con canali pre-aperti
Operatività saltuaria da desktop	nodo Lightning opzionale, on-chain di default

La decisione non è morale, è operativa. Aprite un canale solo quando prevedete un flusso ricorrente e avete un piano per la liquidità inbound. Per il resto, Lightning è una scorciatoia utile ma non obbligatoria.

Verifica e limiti

Questa pagina è stata verificata l'8 settembre 2026 sul repository lightning/bolts, che raccoglie le specifiche BOLT-1-11 consultate per definire canali, commitment transaction, onion routing e gossip, e sulla documentazione operativa di Lightning Engineering. Il whitepaper originale resta la base concettuale, anche se i dettagli implementativi sono evoluti con le versioni BOLT più recenti.

Le implementazioni (Core Lightning, LND, Eclair, LDK) differiscono su dettagli come la gestione del canale di default, la gestione delle fee, l'integrazione con watchtower. Prima di mettere in produzione un nodo, vale la pena leggere la documentazione specifica dell implementazione scelta. Questa pagina non offre consulenza finanziaria né una garanzia di funzionamento: spiega il protocollo e ne dichiara i limiti operativi, lascia all'utente la scelta degli strumenti concreti.

• Lightning Network whitepaper (PDF originale)
• Repository lightning/bolts — specifiche BOLT-1-11
• Lightning Engineering — documentazione operativa
• UTXO Bitcoin: cosa sono e a cosa servono
• LNP/BP: una dolce introduzione
• Full node Bitcoin: utilità, requisiti e limiti