Bitcoin Colosseum
Lightning Network non è irrimediabilmente rotta
5 min read 936 words

Lightning Network non è irrimediabilmente rotta

Lightning Network non è irrimediabilmente rotta solo perché esiste una possibile minaccia futura dai computer quantistici.

Bobby Shell risponde all’allarme sollevato da Udi Wertheimer.

La vulnerabilità di cui si parla non riguarda tutti i fondi in ogni momento: si attiva solo in casi molto specifici (come la chiusura forzata di un canale), richiede un computer quantistico potente che ancora non esiste, e lascia agli attaccanti finestre di tempo limitate per agire.

Nel frattempo, la community di Bitcoin sta già lavorando attivamente a soluzioni che proteggeranno sia Bitcoin che Lightning.

È una sfida reale, ma condivisa da tutto il sistema finanziario digitale – non un problema esclusivo e senza via d’uscita per Lightning.

Questa prospettiva più equilibrata è stata portata avanti da Bobby Shell, sviluppatore e co-fondatore di Chamber of Bitcoin, che lavora in marketing e go-to-market per Voltage.cloud.

Il 18 aprile 2026 Shell ha pubblicato su CoinDesk un articolo intitolato “The Lightning Network isn’t ‘helplessly broken’”, in risposta a un post virale su X.

A lanciare l’allarme era stato Udi Wertheimer, controverso sviluppatore Bitcoin e co-fondatore di Taproot Wizards.

Qualche settimana prima, Wertheimer aveva scritto che Lightning Network è “helplessly broken” (irrimediabilmente rotto) in un mondo post-quantistico, sostenendo che i developer di Lightning non possono fare nulla da soli perché il problema risiede nella struttura stessa del protocollo.

I dettagli del dibattito

Per capire il punto di Wertheimer e la contro-argomentazione di Shell, occorre entrare nei dettagli di come funziona Lightning e di cosa cambia con i computer quantistici.

Il cuore del problema secondo Udi Wertheimer

In Lightning, ogni utente apre un canale con un controparte (channel counterparty). Quando si apre il canale, le due parti devono scambiarsi le rispettive chiavi pubbliche per firmare le transazioni di commitment e HTLC. Queste chiavi pubbliche non sono pubblicate sulla blockchain finché il canale rimane aperto perché il tipo di transazione utilizzato, generalmente P2WSH, non espone le chiavi pubbliche in chiaro.

Tuttavia, la controparte le possiede fisicamente.

Wertheimer sottolinea che:

  • L’utente spesso non sa nemmeno chi sia la controparte.
  • Una singola controparte può gestire centinaia di canali e aggregare una grande quantità di bitcoin.
  • Se quella controparte viene compromessa e un computer quantistico CRQC riesce a usare l’algoritmo di Shor per derivare la chiave privata dalla chiave pubblica, i fondi dell’utente possono essere rubati senza che l’utente debba mai muovere i suoi bitcoin o fare una transazione on-chain.
  • Lightning non può risolvere questo da sola: le chiavi pubbliche devono essere condivise per far funzionare i canali. L’unica vera soluzione è aggiungere crittografia post-quantistica al livello base di Bitcoin (ad esempio con firme hash-based o lattice-based).

In sintesi, secondo Wertheimer:

Lightning è fondamentalmente compromessa in un mondo post-quantistico. Le chiavi pubbliche devono necessariamente essere condivise per far funzionare Lightning. L’unico modo per risolvere questo problema è introdurre crittografia quantum-proof direttamente sul layer base di Bitcoin. Fino ad allora, gli sviluppatori di Lightning sono impotenti

La risposta di Bobby Shell: rischio reale ma molto circoscritto

Shell riconosce che la preoccupazione è legittima, ma contesta il framing allarmistico. Ecco i punti tecnici chiave:

  1. Mentre il canale è aperto
  • Le chiavi pubbliche rimangono nascoste on-chain (P2WSH).
  • I pagamenti Lightning usano HTLC, che si basano su hash preimage (non su chiavi esposte).
  • Un attaccante quantistico che osserva passivamente la blockchain non vede le chiavi di cui ha bisogno.
  1. L’unica finestra di attacco concreta: la force-close Quando un canale viene chiuso forzatamente, la commitment transaction va on-chain e rivela:
  • La local_delayedpubkey (una chiave ECDSA standard).
  • Gli output HTLC. A questo punto entra in gioco un timelock CSV (CheckSequenceVerify):
  • Tipicamente 144 blocchi ≈ 24 ore per l’output principale.
  • Per alcuni HTLC può scendere a 40 blocchi ≈ 6-7 ore. L’attaccante deve:
  • Vedere la transazione nel mempool.
  • Eseguire Shor per derivare la private key.
  • Firmare e trasmettere una transazione che spenda l’output prima che scada il timelock. È una gara contro il tempo su singoli output, non un drenaggio silenzioso di tutti i wallet Lightning.
  1. La realtà dell’hardware quantistico Oggi non esistono CRQC capaci di rompere la curva ellittica secp256k1 di Bitcoin. Il record attuale di Shor su hardware quantistico reale è la fattorizzazione di 21 (2012) o, in modalità ibrida, un numero RSA a 90 bit. Servirebbero milioni di qubit logici stabili e corretti per errori per attaccare chiavi a 256 bit – un obiettivo ancora distante anni (o decenni).
  2. La community non è “senza speranza” Dal dicembre 2025 la Bitcoin dev community ha prodotto diverse proposte post-quantistiche concrete:
  • SHRINCS (firme hash-based stateful da 324 byte)
  • SHRIMPS (firme multi-dispositivo da 2,5 KB)
  • BIP-360
  • Paper di Blockstream sulle firme hash-based
  • Proposte di opcode come OP_SPHINCS, OP_XMSS e STARK-based in Tapscript Queste soluzioni andranno implementate a livello di base layer, e Lightning ne beneficerà automaticamente una volta attivato un soft-fork.

Stessa sfida di tutto il sistema finanziario

Lightning non è “helplessly broken”. Affronta lo stesso problema crittografico a lungo termine di Bitcoin on-chain, delle banche tradizionali, delle carte di credito e di tutto l’internet moderno.

La differenza è che la community Bitcoin storicamente è molto refrattaria ad accettare i cambiamenti, ma sta diventando tra le più attive nella predisposizione di soluzioni per il passaggio a crittografia post-quantistica.

Per le aziende che oggi usano Lightning (iGaming, exchange, neobanche, servizi di pagamento) il messaggio è chiaro: il rischio è teorico e futuro, mentre i benefici attuali (pagamenti istantanei a frazioni di centesimo) sono reali.

Monitorare il progresso delle proposte post-quantum è saggio; abbandonare Lightning sulla base di un titolo allarmistico sarebbe prematuro.

Enjoyed this article?

Support the author with a Lightning tip.

Zap
I database server di Bitcoin della CIA

I database server di Bitcoin della CIA

Venerdì 17 aprile abbiamo fatto per parlare dei rapporti tra Bitcoin e la CIA, partendo dalle affermazioni che Prof Jiang ha fatto su Bitcoin e la CIA in una recente intervista. La

2 min read
Bitcoin Core 31 disponibile

Bitcoin Core 31 disponibile

31.0 pronta per il rilascio finale: è stata taggata su GitHub Oggi, 16 aprile 2026, il noto sviluppatore Bitcoin Murch (handle X: @murchandamus) ha annunciato ufficialmente il tagg

3 min read