// step 1 di 5

Esplora la Rete

Questa è una porzione della rete Lightning reale. Ogni cerchio è un nodo, ogni linea è un canale di pagamento. Hover sui nodi per vedere i dettagli.

Nodi nella demo

7

+1 il tuo (step 2)

Canali pre-esistenti

10

capacità: ~18.5M sat

Routing

Dijkstra

minimizza le fees

Come funziona un canale Lightning?

Un canale è un contratto on-chain 2-di-2: i fondi vengono bloccati in un indirizzo Bitcoin che richiede la firma di entrambe le parti per essere speso. All'interno del canale, le due parti si scambiano commitment transaction firmate (ma non pubblicate) che aggiornano i saldi — niente blockchain, niente fee per ogni pagamento. Solo quando il canale si chiude viene pubblicata una transazione on-chain con il saldo finale.

Lo spessore dei canali indica la capacità. Il colore del gradiente mostra la distribuzione della liquidità: oro = liquidità verso il nodo A, verde = liquidità verso il nodo B.

Tre dettagli tecnici chiave:

Il canale è un UTXO: la funding TX crea un output multisig 2-di-2 sulla blockchain. Tutto ciò che avviene dopo è off-chain — la blockchain non vede nulla fino alla chiusura del canale.
Aggiornamento saldo: ogni pagamento aggiorna le commitment TX firmate da entrambi, senza pubblicare nulla on-chain. La firma reciproca garantisce che nessuno possa imbrogliare sull’ultimo saldo.
Atomic: gli HTLC garantiscono che un pagamento avvenga completamente oppure non avvenga affatto — non esistono pagamenti a metà strada lungo un percorso multi-hop.

// step 2 di 5

Avvia il Tuo Nodo

Configura il tuo nodo Lightning. Per aprire canali hai bisogno di bitcoin on-chain da impegnare come garanzia.

Alias del nodo

Fondi on-chain (sats) 1,000,000 sat

≈ 0.01 BTC · questi sat saranno impegnati nei canali

// Anteprima nodo

⚡

—

Lightning Node

Fondi on-chain —

Canali aperti 0

Stato ✓ pronto

La tua chiave pubblica sarà il tuo ID univoco nella rete. Nessuno vede i tuoi saldi — solo la capacità totale dei canali.

// step 3 di 5

Apri i Canali

Scegli con chi aprire un canale. Puoi aprirne fino a 3. Clicca un nodo per vedere la funding transaction e la spiegazione del wallet 2-di-2.

// Apri canale con —

Capacità canale (sats) 300,000 sat

Rimanente on-chain: — sat

🔐 Funding Transaction — Wallet 2-di-2 on-chain

Input (il tuo UTXO)

300,000 sat

firmato con la
tua chiave privata

→

Output — P2WSH

300,000 sat

indirizzo bc1q…
richiede 2 firme

OP_2
<tua_pubkey> // solo tu puoi firmare con questa
<pubkey_peer> // solo il peer può firmare con questa
OP_2
OP_CHECKMULTISIG // richiede entrambe le firme

💡

Non stai inviando sat a peer. Stai bloccando i tuoi bitcoin in un contratto on-chain condiviso che né tu né peer potete aprire unilateralmente. È un vero wallet 2-di-2 — non uno scambio di valuta. Per chiudere il canale servono entrambe le firme (chiusura cooperativa) oppure un timelock (chiusura forzata).

▼ Come si chiude un canale? Commitment Transaction e Penalty

Ogni volta che i due peer si scambiano un pagamento, firmano una nuova Commitment Transaction che rispecchia il saldo aggiornato — ma non la pubblicano on-chain. Quella vecchia è “revocata” tramite una chiave di revoca, ma tecnicamente è ancora valida finché non viene sostituita.

Chiusura cooperativa: entrambi i nodi si accordano, pubblicano l’ultima TX, i fondi tornano on-chain immediatamente senza timelock.
Force close: un nodo pubblica l’ultima commitment TX senza l’accordo dell’altro. I fondi dell’iniziatore sono bloccati per un timelock (es. 144 blocchi ≈ 1 giorno) — l’altro nodo ottiene i suoi subito.
Penalty (breach remedy): se un nodo tenta di pubblicare una commitment TX vecchia per rubare fondi, l’altro dispone di una breach remedy transaction pre-firmata che si “sblocca” grazie alla chiave di revoca — e prende tutti i fondi del canale come penalità.

✓ Cooperativa

Entrambi firmano la TX finale. I fondi tornano on-chain immediatamente, nessun timelock. Caso ideale.

△ Force Close

Un nodo pubblica unilateralmente. I suoi fondi sono bloccati ~144 blocchi. Il peer ottiene i suoi subito.

✗ Fraud Attempt

Nodo pubblica TX vecchia: il peer usa la breach remedy e ottiene tutti i fondi del canale come penalità.

// step 4 di 5

Liquidità e Riequilibrio

Dopo aver aperto i canali, tutta la liquidità è locale (puoi inviare ma non ricevere). Il riequilibrio sposta liquidità tramite un pagamento circolare.

Liquidità locale vs remota

Locale (oro) = sat che puoi inviare attraverso questo canale. Remota (verde) = sat che puoi ricevere. Dopo l'apertura, hai solo liquidità locale perché tutti i sat sono tuoi. Per ricevere pagamenti, qualcuno deve prima inviarti qualcosa — oppure puoi fare un rebalance: un pagamento circolare che sposta liquidità da un canale all'altro.

Locale (invio)

Remota (ricezione)

Liquidità in entrata — il problema reale

Quando apri un canale con 1 M sat, tutti i sat sono tuoi (liquidità locale = capacità di invio). Liquidità remota = 0: non puoi ricevere neanche 1 sat.

Per ricevere devi prima spendere alcuni sat → la liquidità remota cresce man mano che invii.
In alternativa: rebalancing (pagamento circolare) o aprire un canale dove è l’altro nodo a finanziare (inbound channel).
Per questo i merchant Lightning devono acquistare liquidità in entrata da provider come ACINQ (Lightning Pool) o aprire canali con exchange grandi.

Trascina lo slider per simulare i pagamenti inviati e osserva come cambia la liquidità:

Sat spesi (inviati): 0 sat

Locale (invio)

1.000.000 sat

Remota (ricezione)

0 sat

// step 5 di 5

Invia un Pagamento

Scegli la destinazione, imposta l'importo e guarda il routing Dijkstra trovare il percorso ottimale attraverso la rete.

Importo (sats) 50,000 sat

Destinazione

// Percorso ottimale (Dijkstra — min fees)

Fee totale: — sat · Hops: —

// HTLC — Hash Time-Lock Contract

1

Generazione invoice: il destinatario crea un payment hash H(R) da un segreto casuale R (preimage)

2

Lock along the path: ogni nodo blocca i sat condizionalmente — "pagabili solo se conosci R tale che H(R) = hash"

3

Reveal del preimage: il destinatario rivela R al suo vicino. Ogni nodo verifica H(R) e sblocca i sat in catena (backward)

4

Settlement: tutti i canali aggiornano i saldi locali. Nessuna transazione on-chain — solo commitment TX firmate off-chain

⚠️ Problema: devi stare online per difendere il canale

Se il tuo peer tenta un force close fraudolento (pubblicando una commitment TX vecchia) mentre sei offline, non puoi rispondere con la breach remedy in tempo — e potresti perdere i fondi.

La soluzione sono i Watchtower:

Nodi di terze parti che monitorano la blockchain per tuo conto, 24/7, anche quando sei offline.
Se rilevano un tentativo di frode, inviano automaticamente la breach remedy transaction per tuo conto.
Implementati in LND (con Neutrino), CLN e LDK. Alcuni sono gratuiti, altri a pagamento.
Non possono accedere ai tuoi fondi: ricevono solo la breach remedy pre-firmata da te — non le tue chiavi private.

Scenario	On-chain	Lightning
Importi grandi (> 0.1 BTC)	✓ Preferibile	✗ Rischio liquidità
Micropagamenti (< 10.000 sat)	✗ Fee proibitive	✓ Ideale
Merchant — pagamenti frequenti	✗ Lento (10 min)	✓ Istantaneo
Privacy massima	✗ Tutto pubblico	✓ Onion routing
Cold storage / HODLing	✓ Unico modo	✗ Fondi “caldi”
Primi passi / utente base	✓ Più semplice	✗ Canali, liquidità

Lightning Network
Visualizzato

Come funziona un canale Lightning?

Liquidità locale vs remota

Liquidità in entrata — il problema reale

La conoscenza
dovrebbe essere libera

Lightning NetworkVisualizzato

Come funziona un canale Lightning?

Liquidità locale vs remota

Liquidità in entrata — il problema reale

La conoscenzadovrebbe essere libera

Lightning Network
Visualizzato

La conoscenza
dovrebbe essere libera