Bitcoin Lightning o on-chain: commissioni, conferme e canali

Entrambi trasferiscono valore denominato in bitcoin, ma usano in modo diverso il livello base. Un pagamento on-chain crea una transazione che i nodi Bitcoin possono propagare e i miner includere in un blocco. Un pagamento Lightning passa per un percorso di canali; ogni singolo pagamento non viene scritto come transazione Bitcoin separata nella blockchain.

La differenza incide su commissioni, disponibilità, privacy e stati mostrati dal wallet. Lightning non è un’altra moneta e “off-chain” non significa senza regole o rischi. I partecipanti usano transazioni Bitcoin per aprire il canale e, se necessario, regolarne i saldi.

Il wallet seleziona output spendibili, costruisce e firma una transazione, quindi la trasmette ai nodi Bitcoin. I nodi possono inoltrarla e conservarla nei rispettivi mempool finché un miner non la include in un blocco. La commissione di rete dipende dalla dimensione della transazione e dal tasso scelto, non solo dalla quantità di bitcoin inviata. La guida Bitcoin Developer sull’elaborazione dei pagamenti descrive il percorso.

L’ID della transazione permette di controllare ciò che è stato trasmesso, ma visualizzarla non significa che sia confermata. Una conferma indica che la transazione è contenuta in un blocco; i blocchi successivi aumentano il conteggio. Il destinatario o il suo servizio stabilisce quante conferme attendere in base all’importo e al contesto. Il ritmo dei blocchi e l’obiettivo di conferma non promettono disponibilità entro un minuto preciso.

Il destinatario può fornire una fattura Lightning con una richiesta di pagamento, spesso con importo, destinazione, descrizione e scadenza. Il wallet del mittente la legge e cerca un percorso con capacità e limiti adeguati. La specifica BOLT 11 sulle fatture descrive i campi della richiesta; BOLT 7 tratta gli annunci dei canali e gli aggiornamenti di instradamento.

Un pagamento instradato usa trasferimenti condizionali chiamati HTLC. Ogni nodo intermedio riceve importo e condizioni temporali per il tratto successivo; il destinatario finale rivela il segreto che completa il pagamento. Il percorso può fallire se manca liquidità nella direzione necessaria, un aggiornamento è obsoleto, si raggiunge un limite o un peer non è disponibile. Un pagamento Lightning riuscito può terminare senza attendere un nuovo blocco, ma non è garantito che ogni fattura venga pagata.

Un canale di pagamento nasce con una transazione di finanziamento on-chain e ha una capacità totale. Quando i partecipanti si pagano, il saldo cambia senza pubblicare una transazione Bitcoin separata per ogni aggiornamento. Quanto una parte può inviare in quel momento dipende dal saldo in quella direzione, dalle riserve, dai limiti e dal percorso scelto. Il protocollo peer BOLT 2 descrive i parametri di canale e i limiti HTLC.

Un canale con capacità totale sufficiente può comunque non avere liquidità in uscita per un pagamento specifico. Anche al destinatario può mancare un percorso in entrata utilizzabile per quell’importo. Aprire un canale, spostare liquidità o chiuderlo può richiedere transazioni e commissioni on-chain. BOLT 5 sulla gestione on-chain descrive le chiusure cooperative e unilaterali. L’illustrazione distingue i pagamenti ripetuti nel canale dal finanziamento e dalla chiusura regolati su Bitcoin.

Una commissione on-chain paga spazio nei blocchi. Il totale dipende dalla dimensione della transazione e dal tasso scelto per le condizioni correnti; una transazione più grande può costare di più anche se invia meno bitcoin. La stima del wallet varia e non prenota un posto in un blocco futuro.

Le commissioni di inoltro Lightning sono stabilite dagli operatori dei canali e possono combinare un importo base e una quota proporzionale. Lunghezza del percorso, politiche, liquidità e comportamento del wallet incidono sul totale. Alcuni wallet possono aggiungere costi propri di servizio o di liquidità. Lightning può essere più economico in una situazione specifica, ma non è sempre gratuito o più conveniente dell’on-chain. Prima di approvare controlla importo finale, dettagli delle commissioni e requisiti del percorso.

Un wallet on-chain può mostrare stati come trasmesso, in attesa o confermato. Transazioni e blocchi sono consultabili pubblicamente e il destinatario può applicare una soglia di conferme adatta all’importo e al contesto. Una transazione può restare non confermata più del previsto; la stima della commissione non controlla la scelta dei miner.

Su Lightning la fattura risulta pagata quando il percorso si completa e il wallet riceve un esito positivo. Quel singolo pagamento non viene incluso in un blocco Bitcoin. Un tentativo fallito non è una conferma e una schermata incerta non dimostra che sia sicuro pagare di nuovo. Prima di riprovare verifica lo stato finale del wallet mittente e la fattura o ricevuta del destinatario.

I dati on-chain sono pubblici e analizzabili, anche se un indirizzo non rivela automaticamente il nome di una persona. L’onion routing di Lightning mira a limitare ciò che un nodo intermedio apprende sull’intero percorso, ma non rende anonimo ogni pagamento. La specifica BOLT 4 sull’onion routing e gli aggiornamenti pubblici dei canali descritti da BOLT 7 mostrano parti del modello di privacy.

I wallet differiscono anche per chi controlla le chiavi e per il modo in cui monitorano, salvano e recuperano i canali. Un wallet in autocustodia e un conto Lightning custodial comportano responsabilità e rischi diversi. Connessione internet, disponibilità dei peer, stato del canale, procedure di recupero e condizioni del fornitore possono contare. La sola parola “Lightning” non indica chi custodisce i fondi o come siano protetti i backup.

L’on-chain può essere adatto a chi fornisce un indirizzo Bitcoin e vuole una transazione verificabile sulla blockchain. Lightning può funzionare tra wallet compatibili se sono disponibili una fattura e un percorso con liquidità sufficiente. Pagamenti piccoli e ripetuti possono riutilizzare un canale esistente, ma apertura, gestione e chiusura hanno costi e limiti propri.

Prima di inviare controlla tipo di pagamento, rete, importo, scadenza della fattura, destinatario, commissione mostrata e limiti. Non inserire una fattura Lightning nel campo di un indirizzo on-chain e non usare un percorso non richiesto dal destinatario. Usa un fallback on-chain solo se fattura e wallet lo supportano esplicitamente. Per approfondire: commissioni delle transazioni Bitcoin, conferme dei depositi e lista di controllo per trasferimenti crypto.

Riferimenti tecnici primari: Bitcoin Developer Guide: elaborazione dei pagamenti; BOLT 2: protocollo peer; BOLT 4: onion routing; BOLT 5: transazioni on-chain; BOLT 7: gossip di instradamento; BOLT 11: codifica delle fatture.