Il mito del Lightning « off-chain quindi privato »: ciò che la ricerca accademica ha rivelato nel 2026

L'idea ricevuta, e il suo problema

« Il Lightning Network è privato perché le transazioni sono off-chain. » Questa frase, ripetuta dal 2018 in praticamente tutti i pitch Bitcoin mainstream, è tecnicamente vera ma semanticamente ingannevole. Vera: sì, i pagamenti tra l'apertura e la chiusura di un canale non toccano la blockchain Bitcoin. Ingannevole: no, l'assenza di scrittura on-chain non basta a costituire privacy nel senso in cui si intende abitualmente.

La ricerca accademica 2024-2026, in particolare il paper ScienceDirect « Timechain-level modeling and analysis of the Bitcoin Lightning Network », lo studio universitario ripreso da gncrypto su « Lightning Network economically irrational and has privacy shortcomings », e diverse pubblicazioni adiacenti, ha pazientemente decomposto perché questa intuizione semplice non regge.

Le sei falle strutturali

1. Il grafo pubblico

BOLT 7, il protocollo di gossip, diffonde ai node della rete i canali annunciati con la loro capacità, i loro peer e le loro politiche di routing. Questa informazione è pubblica per costruzione e indicizzata in tempo reale dai crawler commerciali. Un canale annunciato non ha privacy nel senso topologico.

2. Le invoices BOLT 11

Una invoice Lightning standard (BOLT 11) codifica nel suo testo verbose: node ID del destinatario, importo esatto, payment hash, scadenza, descrizione. Decodificare una invoice pubblicata, su un sito e-commerce, su Twitter, in un'email, significa già ottenere una frazione sostanziale dei metadati del pagamento.

3. I payment hash in transito

Ogni node intermedio che instrada un HTLC vede il payment hash e la prossima destinazione. L'onion routing limita la portata, ogni node vede solo da chi e verso chi instrada, ma non elimina la correlazione. Un attaccante che controlla più node può ricostruire il percorso tramite timing analysis e hash matching.

4. I channel announces e closes

L'apertura e la chiusura di un canale sono transazioni on-chain ordinarie. Sebbene i formati SegWit recenti (Taproot, Schnorr) rendano le channel funding transactions indistinguibili da un pagamento single-sig classico, i pattern di utilizzo restano identificabili: timing, importi simmetrici, co-spending.

5. Le euristiche di pagante / pagato

Il paper ScienceDirect formalizza diverse euristiche che permettono a un osservatore di proporre un'ipotesi sull origine e la destinazione di un pagamento, anche senza controllo diretto dei node intermedi. Per esempio: se un node A ha una capacità in uscita che diminuisce di N satoshi nello stesso secondo in cui un node B ha una capacità in entrata che aumenta di N satoshi (modulo fees), A→B è l'ipotesi razionale. Queste euristiche non sono prove, ma funzionano con una precisione del 60-80 % su pagamenti di dimensione media.

6. I servizi custodial

Wallet of Satoshi, Strike, Cash App e tutti i wallet custodial vedono l'interezza dei pagamenti dei loro utenti e conservano i log. Questa falla è massiva e non può essere tappata dalle miglioramenti protocolari: è l'architettura custodial che espone, non il LN in sé.

Le miglioramenti protocolari in corso

BOLT 12, le offers

Deployato su LND v0.18 e CLN all'inizio del 2026, BOLT 12 introduce un nuovo formato di invoice persistente. Invece di condividere una invoice unica per pagamento (che rivela il node ID del destinatario), il destinatario pubblica un'offer, un riferimento persistente. Il pagante, connettendosi a questa offer, riceve un percorso blindato che termina al destinatario senza rivelarne il node ID. È il miglioramento strutturale più significativo da anni.

Blinded paths

Meccanismo connesso a BOLT 12: un destinatario può pubblicare un blinded path che descrive come raggiungerlo attraverso una sequenza di node intermedi senza che il pagante veda l'identità finale. Il pagante compone il suo routing usando la parte blindata del percorso. Così, né l'origine né la destinazione si rivelano a vicenda il loro node ID completo.

Payment-point endpoint privacy

Un lavoro più recente (IETF / LND v0.19) esplora l'utilizzo di punti crittografici invece di payment hash per i pagamenti LN. L'obiettivo è rompere le euristiche basate sul matching di hash tra node intermedi. È ancora sperimentale a maggio 2026.

La pratica onesta nel 2026

Per un utente che vuole pagare in LN con una privacy ragionevole nel 2026, la somma di ciò che funziona dà:

• Wallet self-hosted obbligatorio, Phoenix, Blixt, Zeus con backend LND/CLN auto-ospitato. Niente custodial.
• Node funzionante interamente dietro Tor, un solo endpoint .onion esposto.
• Canali privati per default, nessun announce a meno che non abbiate bisogno di essere routabili pubblicamente.
• BOLT 12 offers per ricevere pagamenti senza pubblicare il vostro node ID.
• Più percorsi di rebalance tramite swap services e atomic swaps quando possibile.
• Accettazione lucida che contro un attaccante commerciale ben equipaggiato (Chainalysis, Elliptic), la privacy non sarà assoluta; e che non ha mai preteso di esserlo contro un attaccante state-level.

Il giusto framing

Il Lightning Network non è uno strumento di privacy nel senso in cui lo è Monero. È uno strumento di scalabilità con una finestra di privacy procedurale che si chiude appena l'operatore fa scelte di default. Quando questo articolo dice che il mito « off-chain quindi privato » non regge, non è per scoraggiare l'uso di LN, è per calibrare le aspettative. Un node LN ben configurato resta largamente migliore in privacy di una carta di credito, di un checkout Stripe, o di un exchange centralizzato. Non è semplicemente equivalente a Monero, e non lo sarà finché le miglioramenti protocolari in corso non avranno raggiunto una maturità di deploy completa.