Nel capitolo precedente abbiamo inviato bitcoin on-chain. Il wallet ha costruito una transazione, l’ha trasmessa alla rete e abbiamo atteso che entrasse in un blocco. Quell’operazione occupa spazio nella blockchain, paga una commissione ai miner e rimane visibile nel registro pubblico. Sono caratteristiche necessarie quando vogliamo regolare un trasferimento direttamente sul livello base di Bitcoin, ma diventano poco pratiche se dobbiamo pagare un caffè, dividere una cena o scambiare piccoli importi molte volte durante la giornata.
Lightning Network nasce per questi pagamenti. Permette di trasferire bitcoin senza pubblicare ogni singola operazione nella blockchain. Un pagamento completato non deve attendere il blocco successivo, non compete ogni volta per lo spazio limitato dei blocchi e non lascia una transazione permanente che chiunque possa cercare nel registro pubblico. Da questa struttura derivano esecuzione in pochi secondi, commissioni generalmente più basse e maggiore privacy rispetto a una transazione on-chain.
Quando un pagamento attraversa nodi intermedi, ciascuno può applicare una commissione di routing composta da una quota base e da una quota proporzionale all’importo inoltrato. Le commissioni ai miner riguardano invece le operazioni che modificano il rapporto fra i canali e il livello base: aprire e chiudere un canale richiede una transazione on-chain; anche uno swap fra bitcoin on-chain e Lightning coinvolge una transazione sulla blockchain e può aggiungere il costo del servizio. I pagamenti eseguiti nei canali ne aggiornano la distribuzione senza generare ogni volta una nuova transazione on-chain, quindi non competono singolarmente per lo spazio in un blocco e non restano registrati pubblicamente come operazioni separate.
Come si muovono i sat su Lightning
Lightning si basa su canali di pagamento aperti fra due partecipanti. Per aprirne uno, una transazione on-chain vincola una quantità di bitcoin; quell’importo definisce la capacità complessiva del canale. La capacità non limita il volume cumulativo degli scambi: finché il canale rimane aperto, gli stessi sat possono spostarsi più volte da una parte all’altra attraverso successivi aggiornamenti dello stato, senza pubblicare ogni pagamento sulla blockchain né attendere l’inclusione in un nuovo blocco.
Ogni aggiornamento modifica la quota che i due partecipanti possono spendere. Il livello base vede l’output che finanzia il canale, non due UTXO distinti corrispondenti ai saldi mostrati alle parti. La loro ripartizione è rappresentata dall’ultimo stato valido firmato da entrambi: se il canale viene chiuso, quello stato permette di assegnare on-chain a ciascuno la quota che gli spetta.
Aprire e mantenere un canale diretto con ogni possibile destinatario sarebbe impraticabile. I nodi Lightning formano una rete e sono collegati tra loro attraverso i canali di pagamento. Quando mittente e destinatario non condividono un canale, il wallet cerca un percorso e i nodi intermedi eseguono il routing, inoltrando il pagamento attraverso i propri canali. La capacità dei canali pubblici è conoscibile, ma la distribuzione corrente dei saldi non viene annunciata: un percorso visibile può quindi non avere liquidità sufficiente nella direzione richiesta, e il wallet può doverne provare un altro.
Il trasferimento lungo il percorso è coordinato dagli HTLC. Ogni nodo impegna i sat a favore del nodo successivo, che può incassarli solo presentando il segreto legato al pagamento entro una scadenza. Quando il destinatario finale incassa, rivela il segreto e permette ai nodi precedenti di riscuotere a ritroso le rispettive tratte. Se il pagamento non si completa in tempo, gli impegni scadono e i fondi tornano disponibili nei canali di partenza. I nodi intermedi possono così inoltrare il pagamento senza che il mittente debba affidare loro i propri sat.
Il software può anche suddividere lo stesso pagamento fra più percorsi compatibili. Gli HTLC mantengono atomico l’esito anche in questo caso: l’intero importo raggiunge il destinatario oppure il tentativo fallisce, senza lasciare una parte dei sat lungo il tragitto.
Scegliere in base alle competenze tecniche
La scelta di un wallet Lightning dipende prima di tutto dalle competenze tecniche dell’utente e dalle responsabilità che è in grado di assumere. Gestire direttamente un nodo richiede di installare e aggiornare il software, scegliere i nodi a cui collegarsi, aprire e chiudere i canali, controllare la liquidità in entrata e in uscita e conoscere le procedure di backup e recupero. Sono operazioni più complesse dell’uso quotidiano di un normale wallet on-chain e richiedono competenze avanzate che un utente medio, soprattutto all’inizio, non possiede.
Un wallet self-custodial può ridurre questa complessità appoggiandosi a un Lightning Service Provider (LSP). Le chiavi restano all’utente, mentre il fornitore mette a disposizione il nodo con cui aprire il canale, procura liquidità e svolge parte delle operazioni necessarie a inviare e ricevere. La delega non riguarda quindi la custodia dei bitcoin, ma una parte consistente della gestione tecnica. Restano una dipendenza operativa dal servizio e conseguenze su disponibilità, commissioni e informazioni conosciute dal fornitore.
A seconda dell’implementazione, il wallet può aprire automaticamente uno o più canali con l’LSP, procurare liquidità in entrata e affidargli la ricerca del percorso per i pagamenti. Può anche modificare la capacità di un canale tramite splicing: l’operazione evita di chiudere il canale e aprirne un altro, ma richiede comunque una transazione on-chain e la relativa commissione ai miner. Questi automatismi permettono di usare Lightning senza amministrare direttamente un nodo, ma non offrono la stessa autonomia operativa e richiedono un compromesso in termini di privacy. Se il fornitore non è disponibile, le chiavi restano all’utente, mentre le funzioni che dipendono dal servizio possono interrompersi; per questo bisogna conoscere le procedure previste per chiudere i canali o recuperare i fondi on-chain.
Un wallet custodial rappresenta il compromesso più alto per quanto riguarda facilità d’uso e sovranità finanziaria, perché oltre a delegare qualsiasi aspetto tecnico all’azienda fornitrice del servizio, delega alla stessa anche il controllo delle chiavi. Sono tre configurazioni diverse, ognuna con vantaggi, limiti e responsabilità specifiche: un nodo proprio offre più controllo e privacy per le proprie transazioni, ma richiede competenze avanzate; un wallet self-custodial con LSP conserva il controllo delle chiavi e delega parte dell’operatività; un wallet custodial delega entrambe. La gestione di un nodo proprio verrà affrontata nel percorso avanzato Lightning in pratica.
Ricevere con Lightning
Per ricevere apri la funzione Ricevi e scegli Lightning. Il wallet genera un invoice, cioè una richiesta firmata valida per uno specifico pagamento, che contiene le informazioni necessarie per raggiungere il destinatario e una scadenza. Quando conosci la cifra da ricevere, inserisci anche l’importo; puoi aggiungere una descrizione per associare l’incasso a un ordine o ricordarne il motivo. L’invoice può quindi essere mostrato al pagatore come codice QR oppure condiviso a distanza come stringa.
Prima di condividerlo, controlla che cifra e unità corrispondano a quanto concordato. Evita di inserire nella descrizione dati personali non necessari, perché saranno visibili a chi paga. Se hai generato un invoice senza importo, sarà il pagatore a doverlo indicare nel proprio wallet.
Dopo aver condiviso l’invoice, osserva il tuo wallet fino a quando mostra il pagamento come completato e verifica l’importo ricevuto. La schermata o lo screenshot del pagatore non dimostrano che l’incasso sia avvenuto. Se l’invoice scade prima del pagamento, non riutilizzarlo e non modificarlo: generane uno nuovo e invialo al pagatore.
Pagare un invoice
Chi paga riceve l’invoice come stringa o codice QR, apre la funzione Invia, scansiona il codice oppure incolla la richiesta. Dopo la conferma, il wallet esegue i tentativi di routing, cercando la strada verso il destinatario, senza chiedere all’utente di scegliere i nodi da attraversare. Il percorso deve avere liquidità sufficiente. L’intero importo raggiunge il destinatario oppure il pagamento fallisce: per questo si dice che il pagamento è atomico.
Prima di confermare bisogna verificare importo, unità e descrizione, confrontandoli con la richiesta ricevuta. Se l’invoice non contiene l’importo, chi paga deve inserirlo e controllarlo con la cifra concordata. Anche un QR può essere sostituito su una pagina, in un messaggio o sopra quello esposto da un commerciante: se la richiesta mostrata dal wallet è diversa da quella attesa, bisogna fermarsi e farsela rigenerare.
La schermata di conferma può mostrare anche la commissione di routing riconosciuta ai nodi che inoltrano il pagamento. Non è una commissione ai miner per lo spazio in un blocco. Un costo ulteriore può invece dipendere dall’apertura di un canale o da uno swap eseguito dal wallet insieme al pagamento. Se la cifra è sproporzionata rispetto all’importo, non bisogna confermare finché l’applicazione non chiarisce l’operazione e il relativo costo.
Dopo l’invio bisogna attendere che lo stato diventi completato o fallito. Se resta in elaborazione, non va creato subito un secondo pagamento: un’interfaccia lenta non dimostra che il primo tentativo sia fallito e due tentativi potrebbero completarsi entrambi.
Perché per ricevere serve liquidità in entrata
La capacità di un canale è la quantità totale di bitcoin bloccata al suo interno. Questa quantità è divisa fra i due partecipanti e un pagamento ne cambia la distribuzione: i sat si spostano da un lato del canale all’altro. Il saldo dalla tua parte può muoversi verso l’esterno e ti permette di pagare; il saldo dalla parte opposta può muoversi verso di te e ti permette di ricevere.
Immagina un canale con una capacità di 100.000 sat, divisi in 80.000 dalla tua parte e 20.000 dall’altra. In questo esempio semplificato puoi inviare 80.000 sat, ma puoi riceverne soltanto 20.000. Se ricevi quei 20.000 sat, tutti i 100.000 si trovano dalla tua parte: il canale è ancora aperto e i fondi sono tuoi, ma attraverso quel canale non puoi ricevere altro. Quei 20.000 sat inizialmente disponibili dalla parte opposta erano la tua liquidità in entrata.
Nella rete reale il pagamento attraversa spesso più canali. Ognuno deve avere liquidità nella direzione in cui si muovono i sat e, nell’ultimo canale, deve esserci un saldo che possa spostarsi verso di te. Un wallet assistito può gestire questo problema e procurare nuova liquidità in entrata, applicando le condizioni e le eventuali commissioni previste dal servizio. Chi riceve più di quanto spende, come un commerciante, consuma progressivamente questa capacità e deve assicurarsi che il wallet possa ripristinarla.
Con Lightning si completa il percorso Usare Bitcoin ogni giorno: dalla ricezione e dall’invio on-chain siamo passati ai pagamenti nei canali, distinguendo i controlli che spettano a chi usa il wallet dalle operazioni gestite dal software o dal fornitore. Il livello avanzato prosegue con Sovranità tecnica, dove si installa il nodo Bitcoin e si porta la verifica nella propria infrastruttura; su questa base prosegue Lightning in pratica, dedicato alla gestione diretta di nodo, backup, canali e liquidità.