Lightning Network: LNbits, il furto e la catena della custodia

Domenica 8 novembre 2026, poco prima delle 14 UTC, il progetto LNbits ha diramato l’avviso che nessun operatore Lightning vuole mai leggere: spegnete i vostri server, subito. Non era un’esercitazione. Mentre il messaggio circolava su Nostr e su X, alcuni aggressori stavano già creando account non autorizzati su istanze self-hosted e portavano via i fondi, satoshi dopo satoshi.

Per tutto il 2026 la Lightning Network aveva vissuto una lunga stagione di allarmi senza vittime: una patch dopo l’altra su Core Lightning, LDK ed Eclair, falle divulgate in modo responsabile, nessuna perdita confermata. L’edizione inglese di questa testata, ancora il 22 ottobre, poteva scrivere che non risultavano furti. Tre settimane dopo quella frase non regge più: il caso LNbits è il primo prelievo illecito documentato dell’intero ciclo, e cambia il registro della conversazione.

La parte scomoda è dove si è rotto il meccanismo. Non nei canali di pagamento, non negli HTLC, non nel routing onion: il protocollo ha tenuto. A cedere è stato lo strato che quasi nessuno guarda, quello delle applicazioni e della custodia costruite sopra Bitcoin. Questo pezzo ricostruisce cosa è successo, perché conta più del solito, e cosa dovrebbe fare adesso chi gestisce un nodo o un’istanza in Italia.

Otto novembre: la notte in cui Lightning ha perso i primi bitcoin

La cronologia è stretta e nervosa. Intorno alle 12:33 UTT dell’8 novembre, i manutentori di LNbits segnalano un problema sull’estensione Paywall; poco dopo, alle 13:56, la comunicazione si allarga a un ordine secco rivolto a tutti: «fermate immediatamente i vostri server LNbits», perché è in corso «un’ondata di attacchi» che richiede patch di sicurezza. Il servizio ospitato ufficiale, my.lnbits.com, viene sospeso. LNbits è uno dei mattoni più diffusi dell’ecosistema: un software open source che trasforma un singolo nodo Lightning in decine di portafogli, con estensioni per punti vendita, paywall, carte Bolt e bot per le mance. Spegnerlo di colpo significa congelare un pezzo non banale dell’infrastruttura applicativa della rete.

Il danno, almeno quello documentato, ha un nome e una cifra. L’operatore olandese Kevin Ravensberg, che gestisce il servizio di mance Bittipbot, ha confermato il prelievo di 2.285.545 satoshi (circa 0,0229 BTC, poco meno di 1.500 euro ai prezzi attuali) dalla propria istanza tra le 09:22 e le 14:00 UTC, in circa cinque ore, come riportato da Bitcoin.com. Un secondo utente ha descritto un attaccante che ha creato un nuovo account attraverso la sua istanza e ha sottratto circa 0,023 BTC. Non è una fortuna in termini assoluti; è però la prova concreta, su catena, che la minaccia è uscita dal piano teorico.

Ben Arc, il creatore di LNbits, ha stimato l’arrivo delle correzioni «entro 24-48 ore» e ha poi riconosciuto pubblicamente che utenti e sviluppatori avevano subito perdite finanziarie durante l’incidente. La patch è arrivata il 10 novembre con la versione 1.7.0, descritta come aggiornamento di sicurezza urgente: tutte le versioni precedenti risultano esposte, e secondo la ricostruzione di TFTC il meccanismo esatto dell’exploit non è stato ancora divulgato per intero. Ravensberg ha promesso di rimborsare di tasca propria gli utenti colpiti, mentre i fondi restavano bloccati in attesa delle correzioni. Alla pubblicazione della 1.7.0 il progetto non aveva ancora diffuso un totale aggregato delle somme sottratte tra tutte le istanze.

Dal bug al furto: come è cambiata l’estate della sicurezza

Per capire perché un furto da poche migliaia di euro merita un’analisi, bisogna guardare la curva dell’intero anno. La primavera e l’estate del 2026 avevano portato un’ondata di divulgazioni responsabili: molte segnalazioni, alcune generate in automatico e di scarsa qualità, altre reali, tutte chiuse con aggiornamenti prima che qualcuno potesse abusarne. Era il mondo del «potrebbe succedere», fatto di timelock, di cap sui 483 HTLC pendenti per direzione e di modelli formali su carta.

In autunno il tono è cambiato. Core Lightning ha rilasciato la 26.06.8 il 22 settembre e, il 2 ottobre, un avviso esplicito: nodi non aggiornati erano sotto attacco attivo, aggiornare subito; i test furono trattenuti per rallentare il reverse engineering. È seguita la 26.06.9 il 7 ottobre. Quasi in parallelo, LDK ha corretto il cosiddetto bug della «bugia alla riconnessione»: un peer conferma un aggiornamento di stato del canale, poi si riconnette fingendo di non averlo mai ricevuto, inducendo un nodo non aggiornato a firmare una transazione di commitment in conflitto sullo stesso indice. Eclair, dal canto suo, ha pubblicato la 0.14.5 il 20 ottobre con «rafforzamenti» contro nodi malevoli. In nessuno di questi casi risultarono fondi persi.

Novembre ha chiuso il cerchio. Prima Electrum, con la 4.8.4 del 6 novembre, poi la cascata su LNbits. Nel mezzo, il bollettino settimanale di freedom.tech segnalava la CVE-2026-98432 risolta in Lightning Terminal 0.17.10 (che aggiorna lnd a 0.21.6-beta insieme a loop, pool, faraday e taproot-assets) e la Eclair 0.14.6, con un nuovo parametro che controlla se gli splice possano spendere input non confermati. Dodici mesi di manutenzione intensa, chiusi dal primo furto vero. La differenza non è semantica: un bug divulgato è un rischio; un prelievo illecito è una perdita.

La catena di custodia a tre anelli

Il modo più onesto di leggere l’incidente LNbits è quello proposto da TFTC: una catena di custodia a tre anelli che quasi nessun utente aveva mai mappato. Chi lasciava una mancia tramite Bittipbot si fidava di Bittipbot; Bittipbot girava su un’istanza LNbits gestita da Ravensberg; quell’istanza dipendeva dal software LNbits scritto e mantenuto da altri. Tre livelli di fiducia impilati, presentati all’utente come un’unica esperienza «Bitcoin». Quando l’anello più in alto, il codice applicativo, ha ceduto, l’intera catena è venuta giù, e il bitcoiner che credeva di essere sovrano si è scoperto creditore non garantito di una serie di intermediari.

Questo fenomeno ha un nome tecnico ormai ricorrente: la deriva custodiale. La documentazione stessa di LNbits è chiara: un’istanza ospitata è custodiale, perché è il fornitore a controllare la fonte di finanziamento; una configurazione self-hosted può offrire auto-custodia, ma solo se chi la amministra capisce ogni dipendenza. Il problema è che molti utenti partono dal presupposto dell’auto-custodia e poi, senza accorgersene, spostano valore reale su strati custodiali, prendendo una decisione di fiducia che non sanno di aver preso. La Lightning Network, nata per spingere i pagamenti Bitcoin fuori dagli exchange, finisce così per ricreare al proprio interno piccole banche invisibili.

Non è un dettaglio da puristi. È esattamente il punto in cui un furto da poche migliaia di euro diventa un caso di studio: non misura la fragilità di Bitcoin, ma la distanza tra la promessa dell’auto-custodia e la realtà operativa di chi, per comodità, delega. Lo stesso ragionamento vale per gli exchange centralizzati e per i custodi istituzionali, con la differenza che quelli, almeno in Europa, oggi hanno un quadro regolatorio sopra la testa; una piccola istanza self-hosted, no.

La cronologia della patch wave: da settembre a novembre

Messe in fila, le correzioni degli ultimi due mesi raccontano meglio di qualsiasi commento quanto lavoro di manutenzione ci sia sotto la superficie di una rete apparentemente stabile. La tabella che segue riassume la sequenza, distinguendo tra hardening preventivo e falle con un impatto economico concreto.

Due letture coesistono. La prima, rassicurante: il modello di sviluppo multi-implementazione ha funzionato, ogni falla è stata chiusa in fretta, spesso prima di qualsiasi abuso. La seconda, meno comoda: la frequenza e la varietà delle correzioni mostrano una superficie di attacco ampia, distribuita tra quattro implementazioni di protocollo e una selva di applicazioni che ci girano sopra. Entrambe le letture sono vere, e la tensione tra le due è il vero tema dell’autunno di Lightning.

Perché il protocollo ha tenuto e il resto no

Vale la pena insistere su una distinzione che i titoli tendono a schiacciare. La Lightning Network non è un programma soltanto: è un protocollo con una pila di livelli. Al centro ci sono i canali di pagamento, aperti con una transazione di finanziamento in multisig 2-su-2 e aggiornati fuori catena con transazioni di commitment. A tenere onesti i partecipanti c’è il meccanismo di revoca a penale: se provi a pubblicare uno stato vecchio del canale per rubare, la controparte può incassare l’intero saldo. I pagamenti multi-hop viaggiano dentro HTLC, mentre l’instradamento onion in stile Sphinx fa in modo che nessun nodo intermedio veda insieme mittente e destinatario. C’è persino un limite fisico, 483 HTLC pendenti per direzione, ereditato dalla dimensione massima di una transazione Bitcoin.

Sopra questo cuore comune vivono quattro implementazioni indipendenti: LND di Lightning Labs, Core Lightning di Blockstream, LDK di Spiral ed Eclair di ACINQ, che alimenta il portafoglio Phoenix. La diversità è una difesa deliberata: un difetto in una base di codice non abbatte automaticamente le altre, a differenza di una monocultura. È anche il motivo per cui ogni ondata di patch sembra ripetersi quattro volte, con nomi di versione diversi, lo stesso mese.

Dentro questa cornice, il bug LDK della «bugia alla riconnessione» era pericoloso proprio perché toccava la firma delle transazioni di commitment, cioè il confine con la logica di consenso del canale; ed è stato chiuso prima di qualunque abuso noto. LNbits, invece, sta un piano più in alto: non è il protocollo, è un software di gestione dei portafogli. La falla viveva nell’autenticazione e nelle estensioni, non nei canali. Mentre i fondi sparivano, il routing, gli HTLC e la revoca a penale continuavano a funzionare esattamente come previsto. È la prova plastica che la sicurezza di Lightning non è un numero unico, ma la somma di sicurezze a strati; e a novembre l’anello debole era l’applicazione, non la rete.

Electrum e i messaggi onion: il prezzo dell’aggiornamento continuo

Il caso Electrum racconta la stessa tensione da un’altra angolazione. Il 6 novembre il wallet ha rilasciato la versione 4.8.4 per correggere una vulnerabilità legata ai messaggi onion: pacchetti malformati inviati da sorgenti arbitrarie potevano provocare disconnessioni con i peer dei canali. La soluzione adottata è volutamente drastica, come documentato da The Crypto Times: per ora Electrum scarta tutti i messaggi onion in arrivo, in attesa di un’implementazione pratica. Non proprio una dimostrazione di maturità, ma una scelta prudente.

Il punto interessante è il perché. I messaggi onion sono l’infrastruttura su cui poggiano gli offer BOLT12, i codici di pagamento statici e riutilizzabili che dovrebbero rendere Lightning finalmente comoda, senza dover generare una nuova fattura a ogni incasso. Quella stessa novità, appena entrata in circolazione, ha aperto una superficie di attacco nuova. È il paradosso del treadmill degli aggiornamenti: ogni capacità aggiuntiva, dagli offer BOLT12 allo splicing ai canali Taproot, amplia ciò che la rete sa fare e, insieme, ciò che un avversario può provare a colpire. La versione precedente di Electrum, la 4.8.3 di fine ottobre, aveva già chiuso una falla critica sfruttata in rete. Il messaggio per gli operatori è ruvido ma chiaro: su Lightning restare fermi non è un’opzione, e nemmeno aggiornare lo è del tutto, perché ogni salto in avanti porta con sé il proprio carico di rischio da valutare.

La rete si restringe mentre viene attaccata

L’incidente arriva in un momento di contrazione, e questo accentua il nervosismo. Dopo il picco di dicembre 2025, oltre 5.600 BTC, la capacità pubblica è scesa senza sosta. All’inizio di novembre 2026 i cruscotti indicano circa 3.200-3.240 BTC bloccati nei canali pubblici, poco più di 210 milioni di euro ai prezzi correnti, con una perdita di oltre 1.100 BTC dalla fine di luglio. Le cifre divergono da esploratore a esploratore, perché i canali privati sfuggono al conteggio, ma la direzione è univoca.

I numeri arrivano da fonti come ln.fyi, che a inizio novembre segnala circa 3.239 BTC di capacità, 13.879 nodi e 26.906 canali, tutti in calo a doppia cifra su trenta giorni, e dai dati raccolti da CoinLaw, che al 4 novembre contava 28.939 canali e un canale medio da 0,1107 BTC, circa 7.200 euro, contro una mediana di appena 0,02 BTC. In altre parole: tanti canali piccoli e pochi giganti che reggono la rete.

Non tutto il calo è colpa della paura. Una parte è consolidamento fisiologico, con operatori che chiudono canali poco redditizi e concentrano la liquidità; una parte riflette il contesto macro, con Bitcoin sceso sotto i 66.000 euro mentre i mercati guardano alla riunione della Fed del 9 dicembre e alla linea attendista di Warsh. Ma è difficile ignorare il fatto che la rete si stia assottigliando proprio mentre deve assorbire la sua prima ondata di attacchi con danni reali. Una rete più piccola, con meno nodi e più capitale concentrato in poche mani, è anche una rete con meno ridondanza; e la ridondanza, in sicurezza, è quasi sempre un bene.

Custodia, self-hosting e auto-custodia: dove vive il rischio

Se l’anello debole è la custodia, conviene mappare con precisione i modelli possibili, perché tra «ho un wallet Lightning» e «controllo davvero i miei bitcoin» corre una distanza enorme. La tabella seguente mette a confronto le configurazioni più comuni dal punto di vista del rischio e, aspetto spesso trascurato, della tutela giuridica.

La riga che l’incidente di novembre illumina è la terza. Chi ospitava Bittipbot credeva di essere nella fascia sovrana, ma gestiva di fatto una piccola infrastruttura custodiale per conto di terzi, con tutte le responsabilità del caso e nessuna delle tutele di un intermediario regolato. È la trappola della comodità: il software che rende Lightning usabile è anche il software che, se bucato, svuota i portafogli.

Sztorc contro tutti: la Lightning è una grande illusione?

L’incidente LNbits cade nel mezzo di una polemica che divide la comunità Bitcoin da settimane. A ottobre lo sviluppatore Paul Sztorc aveva definito la narrazione sull’esperienza d’uso di Lightning una «cospirazione lunga anni», sostenendo che oltre l’80% dei pagamenti sulla rete passa in realtà da soluzioni custodiali, come riportato da Crypto Briefing. In sostanza: la versione self-custody di Lightning, quella venduta nei convegni, sarebbe molto più rara di quella comoda e centralizzata che la gente usa davvero.

La replica è arrivata dura. Jesse Shrader, amministratore delegato del fornitore di infrastruttura Amboss, ha citato un tasso di successo simulato del 99,66% per pagamenti da 100 dollari e ha aggiunto di «diffidare di chiunque sostenga di poter provare una quota custodiale dell’80% in un senso o nell’altro a partire dai soli dati pubblici». Danny Stagg di Breez ha rincarato: l’esperienza non custodiale sarebbe ormai paragonabile a quella custodiale, e la critica di Sztorc descriverebbe «la Lightning di ieri», non quella attuale. Lo stesso Sztorc ha ammesso che, data la privacy della rete, dimostrare la quota custodiale dai soli dati on-chain è difficile.

Qui sta il punto che rende il dibattito più di una lite tra addetti ai lavori: l’attacco a LNbits è un dato reale caduto esattamente dentro questa discussione. È avvenuto su infrastruttura custodiale e self-hosted-custodiale, cioè proprio il terreno la cui diffusione Sztorc denuncia. Non prova la sua percentuale, che resta contestata; conferma però che la quota di Lightning dove un bug applicativo può svuotare un portafoglio è tutt’altro che marginale. Chi difende la rete ha ragione sul protocollo; chi la critica ha un punto sullo strato in cui la gente, concretamente, tiene i soldi.

Chi risponde quando spariscono i fondi? Consob, MiCA e il vuoto dell’auto-custodia

Immaginate la stessa scena su un exchange europeo: un prelievo non autorizzato, fondi dei clienti sottratti. Scatterebbero obblighi di notifica, un quadro di responsabilità, il regime DORA sulla resilienza operativa, l’attenzione del supervisore. In Italia, sotto MiCA, Consob vigila su condotta di mercato e tutela dell’investitore, mentre Banca d’Italia presidia gli aspetti prudenziali e gli stablecoin, secondo il decreto legislativo 129 del 2024 che ha designato le due autorità; il periodo transitorio italiano, nella versione accorciata, si è chiuso il 1 luglio 2026. Un prestatore di servizi, un CASP, opera dentro questo perimetro.

Un’istanza LNbits self-hosted svuotata di domenica non sta dentro niente di tutto questo. Non è un CASP, non ha un supervisore da chiamare, non attiva alcun obbligo di rimborso. La promessa dell’auto-custodia è anche questo: nessun intermediario tra te e i tuoi satoshi significa nessun intermediario a cui chiedere conto quando qualcosa va storto. È il cuore filosofico di Bitcoin e, insieme, il suo vuoto giuridico. MiCA regola i servizi, non il protocollo e nemmeno l’hobbista che gestisce un nodo in cantina. Il confronto con gli Stati Uniti è istruttivo: lì la postura regolatoria è di arretramento dopo le elezioni di metà mandato, mentre l’Europa ha un impianto fitto che però si ferma, per scelta, al confine del fornitore di servizi.

La posta in gioco cresce via via che sulla rete non viaggiano più solo satoshi. Con USDT riportato su Bitcoin tramite Taproot Assets e RGB, e con il dollaro digitale che diventa il primo stablecoin davvero significativo autorizzato sotto MiCA, le somme custodite negli strati applicativi di Lightning tendono ad aumentare e a diventare più appetibili. Più valore stazionario passa dalle app, più la domanda «chi risponde se sparisce?» smette di essere accademica.